Hosting, Caching and CDNs: Speed Upgrades That Move LCP

In a web.dev case study of Vodafone, an A/B test of a Web Vitals optimised landing page showed 31 per cent better field LCP and 8 per cent more sales, which shows why LCP work can pay off.

Hosting, caching and a CDN improve Largest Contentful Paint only when the delay sits in getting the HTML and the main image to the browser. If your Time to First Byte is slow, these upgrades are often the biggest single win; if TTFB is already quick, money spent on a bigger server will barely move LCP. This post shows you how to tell which situation you are in and which upgrade to make first.

Where server speed fits inside LCP

Largest Contentful Paint measures when the biggest visible element, usually a hero image, a large heading or a featured product photo, finishes rendering. Google rates LCP as good at 2.5 seconds or less. That time is not one block. It breaks down into four parts that happen in order:

1. Time to First Byte (TTFB): how long until the browser receives the first byte of the HTML. This covers DNS lookup, connection setup, any redirects and the time your server spends building the page.
2. Resource load delay: the gap between TTFB and the browser starting to download the LCP resource, such as the hero image.
3. Resource load duration: how long that image or font file takes to download.
4. Element render delay: the time between the resource arriving and the element actually appearing on screen.

Hosting, caching and CDNs mostly affect the first and third parts. Nothing else on the page can start until the HTML arrives, so a slow TTFB delays everything, and no amount of image compression or lazy-loading tweaks will make up for it. On the other hand, if your HTML arrives quickly and LCP is still slow, the problem is further down the chain, and your host is probably not the bottleneck. For the non-technical version of this idea, my plain-English guide to website speed explains it without the jargon.

Is hosting your bottleneck? A quick diagnosis

Before you upgrade anything, work out where your LCP time is going. PageSpeed Insights shows field data for TTFB and LCP when enough Chrome users have visited, and its Lighthouse section includes a breakdown of the LCP element’s timing phases. Chrome DevTools also shows the timing of the HTML request in the Network panel. Then use this decision table.

What you see	Likely bottleneck	Where to start
TTFB is a large share of LCP on every page, including simple ones	Server, hosting plan or missing page cache	Turn on full page caching, then review hosting
TTFB is fast for cached pages but slow for logged-in users, basket or search	Uncached dynamic requests, slow database queries	Object caching, query optimisation, plugin audit
TTFB is fast nearby but slow for visitors in other countries	Distance between server and users	CDN, ideally one that can cache HTML
TTFB is fast, but the hero image starts downloading late	Resource load delay: the image is discovered late	Fix how the image is loaded, not the server
TTFB is fast, the image starts early, but downloads slowly	Image too heavy	Modern formats, correct sizing, CDN delivery
Everything arrives quickly but the element appears late	Render-blocking CSS or JavaScript	Front-end work, not hosting

Test from more than one location and on mobile. A server in Europe may feel fast from a London office while visitors in Karachi or Dubai wait noticeably longer for the same HTML.

Page caching: the upgrade that usually matters most

Without page caching, a CMS such as WordPress builds each page from scratch on every visit: it runs PHP, loads plugins, queries the database and assembles the HTML. With page caching, the finished HTML is saved and served directly to later visitors, skipping almost all of that work. For most content sites, brochure sites and blogs, this is where TTFB improves the most.

The right caching tool depends on your server software:

• LiteSpeed servers: if your host runs LiteSpeed Web Server or OpenLiteSpeed, the LiteSpeed Cache plugin for WordPress uses the server’s built-in cache, which is generally more efficient than a plugin writing cache files through PHP. Check with your host or your control panel to confirm which web server you are on, because the plugin’s server-level caching only works on LiteSpeed.
• Managed WordPress hosts: many have their own server-level caching and ask you not to install a separate caching plugin. Follow their guidance, as two caching layers can conflict.
• Apache or Nginx without built-in caching: a well-maintained WordPress caching plugin can write static HTML files, and Nginx can be configured with its own cache.

Things to check once caching is on:

• Pages that must stay dynamic, such as basket, checkout and account pages, are excluded.
• The cache is cleared or rebuilt when you publish or update content.
• Cache preloading is enabled where available, so the first visitor after a purge does not get the slow, uncached version.
• Query strings added by ad and email campaigns are not creating a separate cache entry for every visit.

Object caching and the database

Page caching cannot help requests that are different for every user: logged-in dashboards, WooCommerce baskets, membership areas, search results and admin screens. For these, the server still has to build the page, and slow database work shows up as slow TTFB.

A persistent object cache, typically Redis or Memcached, stores the results of repeated database queries in memory so they do not have to be run again. It is most useful on WooCommerce stores, membership sites and sites with many logged-in users. On a small brochure site where nearly every page is served from the page cache, it makes little visible difference.

Object caching treats the symptom. It is also worth looking for the cause: a plugin running heavy queries on every page, a bloated options table full of data left by uninstalled plugins, or an outdated PHP version. Moving to a currently supported PHP version is often one of the cheapest server-side improvements available, as long as you test your theme and plugins first.

CDNs: what they do and what they do not

A content delivery network stores copies of your files on servers in many locations and serves each visitor from a nearby one. The benefit grows with the distance between your origin server and your audience. If your business serves Pakistan, the UK and the Gulf from a single server, a CDN can make a clear difference for whichever group is furthest from it.

Know what your CDN is actually caching:

• Static files only. Most CDNs cache images, CSS, JavaScript and fonts by default. This helps resource load duration but not TTFB, because the HTML still comes from your origin server.
• HTML as well. Some CDNs can also cache full HTML pages at the edge, either through configuration rules or through an integration with your CMS. This is what improves TTFB for distant visitors. It needs the same exclusions as page caching, so personalised pages are never served to the wrong person.

A CDN will not rescue a slow origin for uncached requests, and it adds another layer to troubleshoot when content does not update. Set clear purge rules from day one.

Images: format, size and discovery

Hosting decisions and image decisions meet at the LCP image. Three changes tend to matter most:

• Use modern formats. WebP and AVIF usually produce smaller files than JPEG and PNG at similar visual quality. Many CDNs, image optimisation plugins and some hosts can convert and serve these automatically, with a fallback for browsers that need it.
• Serve the right size. A 2,400 pixel wide hero image sent to a phone wastes bandwidth. Use responsive images with srcset so the browser can choose an appropriate file.
• Let the browser find it early. Do not lazy-load the LCP image. If it is set as a CSS background or inserted by JavaScript, the browser discovers it late; use a normal img element where possible, and consider fetchpriority="high" on it.

There is more on image and front-end tactics in my guide on how to improve website loading speed for SEO.

An upgrade order that avoids wasted spend

Work through these steps in order, re-measuring after each one:

1. Measure TTFB and the LCP breakdown on your key templates, on mobile, from your main visitor regions.
2. Enable and correctly configure full page caching for your server type.
3. Fix the LCP image: format, size, no lazy loading, early discovery.
4. Add a CDN if your audience is spread across regions, and cache HTML at the edge if your setup supports it safely.
5. Add object caching if you have significant logged-in or ecommerce traffic.
6. Only then consider moving to a faster hosting plan, if uncached TTFB is still slow after the steps above.

Moving hosts is the most disruptive step, so it comes last. Signs that it is genuinely needed include slow TTFB even on simple uncached pages, performance that drops at busy times, shared hosting where other sites affect yours, or no way to run a supported PHP version or server-level caching.

Keep in mind that hosting mainly affects LCP. Layout jumps and slow taps have different causes, covered in my guides on how to fix Cumulative Layout Shift and improving INP, the metric that replaced FID.

Questions people ask about hosting and speed

Will moving to a more expensive host fix my Core Web Vitals?

Only if your bottleneck is the server. A better host can improve TTFB and therefore LCP, but it does little for layout shift or interaction responsiveness. Diagnose first: if TTFB is already fast, spend the effort on images, CSS and JavaScript instead.

Should I use LiteSpeed Cache if my host is not on LiteSpeed?

Its server-level page caching depends on a LiteSpeed web server, so on Apache or Nginx you would only get some of its other optimisation features. In that case a caching plugin designed for your server, or your host’s own caching, is usually the better choice.

Do I need a CDN if all my customers are in one city?

The distance benefit is smaller when your server is already close to your audience. A CDN can still help with image optimisation, compression and absorbing traffic spikes, but it is less of a priority than page caching and image fixes in that situation.

Can caching cause problems?

Yes, if it is misconfigured. Common issues include visitors seeing outdated content, logged-in users seeing someone else’s basket because a dynamic page was cached, and forms failing because a security token was cached. Exclude dynamic pages and test checkout and forms after every caching change.

Choosing between hosting, caching and CDN changes is much easier once you know where the time actually goes. If you want that diagnosis done properly, my speed optimisation service starts with measuring TTFB and LCP on your real templates before recommending any spend. Get in touch for a free audit and I will show you where your load time is going.