Website SpeedFast is a feature

Speed is a business metric#

Slow pages are not a technical inconvenience; they are a tax on every visit. Paid clicks are charged whether or not the page loads. Visitors on mobile connections give up before seeing the offer. Search engines use page experience signals as part of their ranking systems. Speed work is therefore conversion work, media-efficiency work and SEO work at once.

The trap is to treat speed as a score to be maximised. A perfect lab score on a page nobody visits matters less than a modest improvement on the product template that carries most revenue. Prioritise by traffic and commercial value, just as you would any CRO work.

Every kilobyte on a page should be able to explain what it does for the visitor.

Measure the right thing: field data first#

There are two kinds of speed data. Lab data comes from a simulated load in a controlled environment, for example a Lighthouse run. It is repeatable and useful for debugging. Field data comes from real visitors on real devices and networks, for example the Chrome User Experience Report surfaced in PageSpeed Insights and Search Console. Field data is what your visitors actually experience and what Google's page experience assessment uses.

Start with field data to know where you stand, then use lab tools to find out why. If your site lacks enough traffic for public field data, add real-user monitoring through your analytics or a dedicated tool.

Core Web Vitals in plain language#

Google's Core Web Vitals are three user-centred measures. Thresholds are assessed at the 75th percentile of page loads, so most visits, not just the average, need to be good. Check Google's current documentation, because the metrics evolve; INP replaced FID as the responsiveness metric in 2024.

For the SEO implications and diagnostics in more depth, see Core Web Vitals. Here we focus on what to fix and in which order.

Where the time actually goes#

A prioritised fix list#

Images

Images are usually the largest bytes on a marketing page and the easiest to fix. Serve images at the size they are displayed, not the size the camera produced. Use modern formats such as WebP or AVIF where supported, with sensible compression. Give every image explicit width and height so the browser reserves space, which prevents layout shift. Lazy-load images below the first screen, but never the main hero image, which should load as early as possible because it is often the LCP element.

Third-party scripts

Marketing teams add tags over years and rarely remove them. Audit your tag manager: list every tag, its owner and its purpose. Remove anything nobody can justify. Load the rest after the main content where possible. Be especially careful with client-side testing tools, chat widgets and heavy embeds, which can harm responsiveness. Moving some measurement to server-side tracking can also reduce browser load.

JavaScript

JavaScript is costly twice: it must be downloaded and then executed, which ties up the main thread and hurts INP on slower phones. Remove unused libraries, split code so each page loads only what it needs, defer non-critical scripts and break up long tasks. If a marketing page needs a heavy framework to display mostly static content, question the architecture.

Fonts, CSS and delivery

Limit font families and weights, self-host fonts where licensing allows, and use a font-display strategy that shows text immediately. Inline critical CSS for the first screen and load the rest without blocking. On the server side, enable compression and caching, use a content delivery network so assets are served close to visitors, and make sure hosting is sized for your traffic peaks, such as festive sales.

Making the case internally#

Speed work competes for developer time with visible features, and it usually loses unless someone frames it commercially. Translate technical findings into business language: which templates are slow, how much traffic and revenue pass through them, and what the slowness costs in paid clicks that never see the page.

Avoid promising a specific revenue uplift from speed alone; the relationship varies by site and is hard to isolate. Instead, propose a controlled improvement on one high-value template, measure conversion before and after, or as an experiment where possible, and use your own result to justify the next phase.

Speed and the people who add weight#

Most weight is added by well-meaning colleagues: a campaign team uploading an uncompressed banner, a vendor's tag added for a trial and never removed, a new widget requested by sales. Give non-technical teams simple rules, such as image size limits and a request process for new scripts, so speed is protected without a developer reviewing every change.

Keeping it fast#

Most sites that get faster get slower again within months. New campaigns add tags, new sections add images, new features add scripts. The defence is a performance budget: agreed limits on page weight, script size or Core Web Vitals per template, checked automatically on each release and reviewed whenever someone wants to add a third-party tool.

Give the budget an owner with authority to say no. Speed is a shared resource, and shared resources degrade when nobody guards them. Bake checks into the website launch checklist and into the brief for any new feature.

Published by Fabulous.Media, a network of specialist marketing agencies. Updated 9 October 2026. Platform features change often; check current official documentation before acting on platform-specific detail.