“CDN” and “edge cache” often appear together on hosting pages, but they are not interchangeable.
Both can reduce the work required to deliver a website. They operate at different layers, and understanding those layers makes performance problems easier to diagnose.
Start with a normal request
When someone opens a page, the browser needs HTML, stylesheets, JavaScript, fonts, images, and sometimes data from third-party services.
Without caching, many of those requests travel to the origin hosting server. WordPress may run PHP, query the database, assemble the page, and send the result back across the network.
That work is necessary when content is personalized or newly changed. Repeating all of it for every visitor is often wasteful.
Caching stores reusable results so the next request can take a shorter path.
What a CDN does
A content delivery network is a distributed group of servers. Instead of serving every asset from one origin location, the CDN can provide copies from a location closer to the visitor.
CDNs are especially effective for static assets:
- Images
- Stylesheets
- JavaScript
- Fonts
- Downloads
- Video segments
Distance is only one benefit. A CDN also reduces traffic reaching the origin and can absorb a large number of repeated asset requests.
The first visitor in a region may cause the CDN to fetch an asset from the origin. Later visitors can receive the cached copy until it expires or is purged.
What edge caching adds
The “edge” is the part of the network near the visitor. Edge caching stores content at those distributed locations.
For WordPress, the important step is caching HTML pages—not only images and scripts. If a public page can be served from the edge, the request may avoid a trip to WordPress and the database entirely.
This can improve:
- Time to first byte
- Capacity during traffic spikes
- Consistency for distant visitors
- Origin server load
Edge caching is most valuable for content that is the same for many visitors, such as public pages, articles, documentation, and product information.
Browser cache, page cache, and object cache
Website caching has several layers.
Browser cache
The visitor’s browser stores files locally based on cache headers. A returning visitor may not need to download the same logo or stylesheet again.
This helps repeat navigation but does not help a first-time visitor.
Page cache
A page cache stores generated HTML after WordPress builds it. The next compatible request receives the stored page instead of running the full PHP and database process.
The cache can live on the origin server or at the network edge.
Object cache
An object cache stores the results of database operations or expensive application work. WordPress can reuse those results without repeating the same query.
This is useful for dynamic pages that cannot be fully page-cached, but it still involves the application server.
Each layer solves a different part of the request.
What should not be cached publicly
Caching is safe only when the stored response is appropriate for the next visitor.
Public edge caches should normally bypass:
- Shopping carts
- Checkout
- Account dashboards
- WordPress administration
- Personalized membership content
- Pages with private or session-specific data
- Preview URLs
Cookies, query strings, request methods, and application rules help determine when to bypass the cache.
A cache configuration that ignores personalization can show one user’s content to another. That is a security problem, not a performance improvement.
How content changes reach visitors
Cached content needs an expiration or purge mechanism.
A time to live controls how long a response can remain cached. Short values reflect changes quickly but produce more origin requests. Long values improve cache efficiency but can leave old content visible.
Good WordPress integration purges affected pages when content changes. Publishing an article may clear the article, relevant archives, and the home page without emptying every cached asset.
Manual purge controls are still useful during redesigns and troubleshooting.
A CDN does not fix every slow website
A CDN and edge cache can make delivery faster, but they cannot repair all application problems.
They will not fully solve:
- A slow uncached checkout
- An overloaded database
- A plugin that performs expensive work on every request
- Large unoptimized images on their first download
- Too much JavaScript running in the browser
- Slow third-party analytics or advertising scripts
Performance work should examine both the cached public path and the dynamic path.
For WordPress, test at least:
- A public page with an empty browser cache
- The same page on a repeat visit
- A logged-in page
- Search
- Cart and checkout
- WordPress administration
How to confirm caching is working
Open browser developer tools and inspect the network response headers. Hosting platforms use different header names, but you may see a cache status such as hit, miss, bypass, or expired.
A miss is not automatically a problem. The first request may populate the cache. A hit on the next request confirms reuse.
Also compare:
- Time to first byte
- Total transferred bytes
- Origin CPU or request volume
- Performance from different geographic regions
Do not judge a CDN from one synthetic score. Look for consistent improvement in the paths real visitors use.
What to look for in hosting
A useful hosting platform should make the fast path the default:
- Global CDN included
- Edge caching integrated with the platform
- Automatic SSL
- Safe bypass rules for dynamic WordPress pages
- Automatic purge when content changes
- A clear manual purge option
- Support for modern HTTP protocols
When CDN and caching are native to the hosting platform, there are fewer plugins, accounts, and conflicting settings to maintain.
VeyoHost plans include global CDN and edge caching on the same autoscaling platform. Compare the plans or ask us about a performance problem.
Tell us what you are running. We’ll help you choose the practical next step.