Improve website speed: understanding and optimising Core Web Vitals

To improve the speed of your website, first measure with PageSpeed Insights where the problems are, then tackle the biggest brakes: oversized images, missing caching, blocking fonts and scripts, and a slow server response. Google assesses the user experience with three metrics, the Core Web Vitals. This article explains what they mean, how to measure them correctly and which measures help most, with tips specifically for WordPress.

The three Core Web Vitals and their thresholds

The thresholds come from Google (web.dev, as of October 2026). A page meets them when at least 75 percent of page views are in the green range, measured separately for mobile and desktop. In March 2024, INP replaced the earlier metric FID (First Input Delay).

It is also worth looking at Time to First Byte (TTFB), the time until the server’s first response. Google considers 0.8 seconds or less good. TTFB is not a Core Web Vital, but it directly affects LCP: what the server delivers late, the browser cannot display early.

Measuring correctly: lab and field data

• PageSpeed Insights (pagespeed.web.dev) shows field data from real Chrome users over the last 28 days at the top, if there is enough data, and below that a lab test with Lighthouse including specific recommendations.
• The «Core Web Vitals» report in Google Search Console summarises field data for groups of similar pages and shows which URLs perform poorly. After a fix, you can start a validation there.
• Chrome DevTools with Lighthouse and the Performance tab are useful for tests while you are working on the website.

For Google’s assessment, the field data counts, not the lab score. Smaller websites often have too few visits for field data; then the lab test is your best guide. Always test the mobile view too, as it is usually slower than desktop.

Tip: Measure several typical pages, not just the home page: for example a product or service page, a blog post and the contact form. Then change only one thing at a time and measure again.

Images: the most common cause of a poor LCP

On many pages, the LCP element is a large image such as a hero image or a slider. These measures have the greatest effect here:

• Deliver images at the size actually displayed and use srcset to offer different sizes for smartphones and desktops.
• Use modern formats: WebP or AVIF are usually much smaller than JPEG or PNG at comparable quality.
• Do not delay loading the main image in the visible area (no lazy loading) and prioritise it with fetchpriority="high"; images further down, on the other hand, should use lazy loading.
• Specify width and height for every image so the browser reserves the space. This prevents shifts and improves CLS.
• Avoid sliders in the header if a single image is enough.

Caching and server response

Every page the server does not have to build first reaches visitors faster. Three levels matter:

• Page cache: stores finished HTML pages. On LiteSpeed servers, LSCache does this directly in the web server.
• Browser cache: with suitable cache headers, the browser does not download images, CSS and JavaScript again on the next visit.
• Object cache, for example Redis: speeds up dynamic pages such as the cart or a members’ area that cannot be cached as a whole page.

If TTFB stays high despite caching, the server is often the cause: an outdated PHP version, too few resources or an overloaded account. A current PHP version or hosting with allocated resources helps in that case.

Fonts and scripts

Web fonts

• Host fonts yourself instead of loading them from external servers. This saves connections and is also better for data protection.
• Load only the weights you need, such as regular and bold, in WOFF2 format.
• With font-display: swap, the browser shows text immediately in a fallback font.
• Preload the most important font with rel="preload".

JavaScript and third parties

INP suffers above all from large amounts of JavaScript that block the browser. Typical culprits are chat widgets, tracking and advertising scripts, cookie banners with many embedded services, social media embeds and heavy page builders.

• Remove scripts you do not need instead of just optimising them.
• Load scripts with defer or async so they do not block page rendering.
• Load videos and maps only after a click: first a preview image, then the embed.
• Minify and combine CSS and JavaScript, but test the website after every change.

Avoiding layout shifts (CLS)

Few things are more annoying than a button that moves down just as you tap it because something higher up is still loading. CLS measures exactly these shifts. The most common causes and what helps:

• Images, videos and iframes without dimensions: specify width and height or a fixed aspect ratio (aspect-ratio).
• Elements that load later, such as cookie banners, notice bars or ad slots: show them as an overlay above the content or reserve the space in advance.
• Web fonts that change the width of the text when replacing the fallback font: choose a fallback font with similar proportions.
• Content inserted by JavaScript above the visible area: only insert it after an action by the visitor.

CDN: when it is worth it

A content delivery network (CDN) stores static files on servers in many countries and delivers them from the nearest location. This helps most when your visitors are spread across several continents. If your website is aimed mainly at customers in Switzerland and Liechtenstein, caching, optimised images and a fast server response usually bring more. A CDN can still make sense, for example with many large images or downloads.

WordPress: the key adjustments

• Use a cache plugin that matches the web server. On LiteSpeed this is LiteSpeed Cache; it can also optimise CSS and JavaScript, control lazy loading and convert images to WebP or AVIF via the QUIC.cloud service.
• WordPress supports WebP since version 5.8 and AVIF since version 6.5. Since version 6.3, WordPress automatically adds fetchpriority="high" to the image that is probably the LCP element.
• Use a lightweight block theme instead of a heavy page builder.
• Review plugins regularly and remove anything you do not need.
• Clean up the database: old revisions, spam comments and expired transients, with a backup first.
• Use a current PHP version; WordPress currently recommends PHP 8.3 or newer.

Tip: You will find more practical tips in our article «Speed up WordPress: 8 changes that make a real difference».

Work in this order

1. Record the current state for mobile and desktop with PageSpeed Insights and Search Console.
2. Identify the LCP element (PageSpeed Insights shows it) and optimise it specifically, usually the main image.
3. Activate the page cache and check TTFB.
4. Convert images to WebP or AVIF and add width and height.
5. Host fonts yourself and reduce third-party scripts.
6. Measure again after each change and check the field data after a few weeks.

On HostOn’s WordPress plans, LiteSpeed Cache is pre-configured and websites run on LiteSpeed servers with NVMe storage. Page cache and server response are covered; images, fonts and scripts remain the job of the website itself.