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.

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

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.