Website Speed and Performance | The Web Alchemist

Somebody’s sent you a PageSpeed report covered in red. Or the site just feels sluggish on your phone. Or your developer keeps saying ‘Core Web Vitals’ and you’ve nodded along. This page explains how Google actually measures speed, where slowness usually comes from, which fixes deserve your money first and when a slow site is better rebuilt than patched. Every figure here comes from Google’s own documentation, the HTTP Archive or Can I use, and each one’s dated so you can see how fresh it is.

In brief

Google judges speed with three Core Web Vitals covering loading (LCP), responsiveness (INP) and visual stability (CLS).
It’s measured on real visits, three in four of which need to pass, so a quick test on office broadband proves very little.
Most slowness traces back to a handful of causes, usually hosting, oversized images, fonts, heavy JavaScript and third-party tags.
Speed helps, but Google is clear that relevant content comes first and good scores guarantee nothing by themselves.

Why website speed matters to a business

You’ll find no end of dramatic claims online about how many customers walk off for every extra second of loading. Most are recycled from old case studies nobody can trace. The bit you can rely on comes from Google. Its page experience documentation says “Google’s core ranking systems look to reward content that provides a good page experience”, and the same page says “Core Web Vitals are used by our ranking systems”.

It’s careful not to oversell it, mind. The same documentation says Google “always seeks to show the most relevant content, even if the page experience is sub-par”, and that good Core Web Vitals won’t guarantee you a top spot. Speed is one piece of the puzzle. Our guide to how search visibility works for business websites covers the rest.

The better reason to care is the person on the other end. Picture a plumber’s customer with water pouring through the ceiling, hunting for a phone number on a page that’s still putting itself together. Or someone booking dinner who taps ‘Book a table’ just as a banner loads, so the button jumps and they hit something else. Google’s web.dev documentation on layout shift describes exactly that, moving content that makes people “click the wrong link or button”. Slow, jumpy pages quietly undo the work covered in turning more visitors into enquiries.

Core Web Vitals in plain English

Core Web Vitals are the three measurements Google uses to describe how a page feels to a real visitor. They’re assessed at the 75th percentile of page loads, separately for mobile and desktop. What that means in practice is that at least three out of four visits have to hit ‘good’, so the people on older phones and dodgy signal count just as much as you do on office wifi.

Largest Contentful Paint (LCP)

LCP is about loading. It records how long the biggest image, video or block of text in view takes to appear. web.dev puts ‘good’ at 2.5 seconds or less. It’s very often the big hero photo at the top of the page, which is why images come up so much in speed work.

Interaction to Next Paint (INP)

INP is about responsiveness. It watches every click, tap and key press during a visit and reports one of the slowest. Good is 200 milliseconds or less. INP replaced an older metric, First Input Delay (FID), as a Core Web Vital in March 2024, so if a report or plugin is still going on about FID, it’s out of date.

Cumulative Layout Shift (CLS)

CLS is about stability, meaning how much the page jumps about while someone’s trying to read or tap it. It’s a score rather than a time. Good is 0.1 or less.

Plenty of sites struggle. The HTTP Archive’s 2025 Web Almanac (published January 2026, using July 2025 data) found that 48% of mobile websites and 56% of desktop websites had good Core Web Vitals overall.

Field data, lab data and why your scores disagree

Ever run PageSpeed Insights twice and got two different answers? Or seen a bad score while Search Console says all’s well? That’s usually two different kinds of data talking.

Lab data comes from loading a page once, in a controlled test, on a set device and network. Field data comes from real visitors. Google’s version is the Chrome User Experience Report (CrUX), which reflects how real Chrome users experience the web. PageSpeed Insights shows both, and its field data covers the previous 28 days. The score out of 100 is a lab score from a tool called Lighthouse, where 90 or above counts as good. The Core Web Vitals assessment is field data, and it only passes when every relevant metric is good at the 75th percentile.

web.dev is clear that when you’ve got both kinds of data for a page, field data should set your priorities. A so-so lab score is a reason to dig. It doesn’t prove your customers are struggling.

There’s a catch for smaller firms. CrUX only includes pages and sites with enough visitors to make a statistically meaningful sample. A small accountancy practice or a specialist B2B manufacturer may well see ‘No data available’ in the Search Console Core Web Vitals report. Then lab testing with PageSpeed Insights on its mobile settings is mostly what you’ve got to go on.

Where speed problems come from

Slow sites tend to be slow for a small number of reasons. Work out which one you’ve got and you won’t waste money fixing the wrong thing.

Hosting and server response time

Before a browser can show anything, the server has to answer. That’s measured as Time to First Byte (TTFB), which web.dev defines as the time between a visitor asking for a page and the first byte of the reply arriving. It takes in redirects, looking up the domain, setting up a secure connection and waiting while the server builds the page. TTFB isn’t a Core Web Vital itself, but everything else sits on top of it, and web.dev suggests most sites should aim for 0.8 seconds or less.

web.dev notes that shared hosting is generally slower, while accepting it can be fine for a small site serving mostly static files. A server short on memory will struggle to serve pages quickly, and chains of redirects add delay before anything useful happens. If TTFB is poor, no amount of image squashing will make up for it, which is why choosing the right website hosting is often the first conversation to have.

Images

Images are the most common LCP element by a distance. The 2025 Web Almanac (July 2025 data) found 76% of mobile pages and 85.3% of desktop pages have an image as their LCP element. Three habits make the biggest difference.

Modern formats. web.dev advises that WebP and AVIF generally compress better than JPEG and PNG and should be used where you can. Support is wide now. Can I use put WebP at around 97% of global browser usage and AVIF at around 95% when checked in September 2026. Logos and icons are usually better as SVG files, which stay sharp at any size.
Responsive images. MDN points out that sending a big desktop image to a phone wastes the visitor’s bandwidth when a smaller file would do. The ‘srcset’ and ‘sizes’ attributes let the browser pick a file that suits the screen.
Sensible lazy loading. Adding ‘loading=”lazy”‘ tells the browser to hold off fetching an image until it’s nearly on screen. Brilliant for product grids and long galleries. Never use it on the main image at the top of the page. web.dev is blunt about that, yet the 2025 Web Almanac found about 16% to 17% of pages still lazy-load their LCP image, a figure it says has held steady since 2024.

An online shop with hundreds of product photos, or an estate agent with huge listing galleries, will feel image problems first. But one uncompressed hero photo can slow a trades site just as badly.

Fonts

Custom fonts aren’t free. web.dev explains that browsers often hold back text until a web font has loaded, and that swapping from a fallback font to the real one can make the layout shift. The usual fixes are fewer font families and weights, the compressed WOFF2 format, trimming characters you don’t use and setting a ‘font-display’ rule so text shows up promptly.

JavaScript and third-party tags

This is where INP problems tend to live. Every script fights for the browser’s main thread, and while that thread’s busy the page can’t respond to a tap. web.dev lists too many network requests and too much JavaScript among the ways third-party code slows things down, and warns that loading scripts asynchronously doesn’t fix everything. Over the years a site picks up analytics, a chat widget, a review carousel and tracking pixels from campaigns that finished ages ago. web.dev puts it bluntly. “If the script doesn’t add clear value to your site, remove it.”

Page builders and plugins

Page builders and plugin-heavy setups deserve a fair hearing. They let businesses edit their own pages without calling a developer, and a carefully built site can use one and still perform well. The trade-off is that flexible tools can load code for features a page isn’t using, and every extra plugin can add weight. The 2025 Web Almanac (July 2025 data) found WordPress runs roughly 64% of CMS-driven sites, and that 45% of mobile WordPress sites passed Core Web Vitals, which it describes as among the lowest-ranked of the platforms it compared. The authors observe how hard it is to spread improvements evenly “in ecosystems that allow more customization and diversity in implementation”. So an awful lot depends on how carefully a site is built and looked after, which runs through our web design best practice advice too.

Caching and content delivery networks

Caching just means keeping a ready-made copy so it doesn’t have to be built or downloaded again. Browser caching lets a returning visitor reuse files they’ve already downloaded, like stylesheets and logos, controlled by a ‘Cache-Control’ header from the server. web.dev describes HTTP caching as effective, supported in every browser and not much work to set up. On WordPress, page caching also stops the server rebuilding every page from the database on every visit. Otherwise, web.dev notes, servers may have to “generate content from costly database lookups when cached content cannot be reused”, and that shows up in TTFB.

A content delivery network (CDN) goes a step further, storing copies of your files on servers spread around the world, physically nearer your visitors. web.dev notes CDNs also tend to serve content over newer protocols like HTTP/2 and HTTP/3. If your customers are mostly local, a CDN matters less than good hosting in the right country. For an online retailer shipping abroad, or a training provider with students overseas, it can make a real difference. web.dev also warns that unique tracking parameters stuck on links can stop cached copies being used, so check your caching rather than assuming it works.

How to measure and prioritise speed fixes

Start with the field data. Open the Core Web Vitals report in Search Console. It groups similar URLs together and labels them Good, Need improvement or Poor, separately for mobile and desktop, so you can see which types of page are struggling and on which metric. Then run a few typical pages through PageSpeed Insights to see the lab diagnostics that explain why.

A sensible running order usually looks something like this.

Fix whatever’s failing on the pages that bring in enquiries or sales first, like service, product and contact pages. The blog archive can wait.
LCP failing? Check TTFB first, then the size, format and loading priority of the main image.
INP failing? Go through third-party scripts and plugins and get rid of anything that isn’t earning its keep.
CLS failing? Look for images without a width and height set, ads or embeds with no space reserved, and banners that load late. Our piece on user experience priorities for 2026 covers the design side.
Re-test after each change, and give the field data its 28 days to catch up.

Chasing a perfect 100 in the lab is rarely worth the money. Passing Core Web Vitals for real visitors on the pages that pay the bills is what counts, and a lot of the checks overlap with our list of common website problems worth fixing first.

Technical debt, and when to rebuild instead of refactor

‘Technical debt’ is the pile of shortcuts, abandoned features and old code that builds up on any site that’s been added to for years. A theme swapped twice, plugins bolted on to fix one-off problems, three sliders on the home page. It all leaves traces, and together it makes every speed fix harder because improving one thing breaks another.

Refactoring means keeping the site and cleaning it up. Remove unused plugins, swap out heavy components, compress images, tidy the code. It’s usually the cheaper first step. A rebuild makes more sense when the foundations are the problem. Maybe the theme can’t be updated without breaking. Maybe security updates are being skipped because someone’s worried they’ll break something. Maybe the site still can’t pass Core Web Vitals after the obvious fixes. If that sounds familiar, our signs your website needs a redesign article is a handy checklist, and our website security and maintenance guide covers the upkeep that stops the debt piling up again.

If you do rebuild, put performance in the brief from day one alongside design and content. Setting limits on page weight and third-party scripts at the planning stage is far easier than clawing them back later. We offer website design and development if that’s where you’re heading.

Platform choice and headless, briefly

You don’t need an exotic platform for a fast website. A well-built WordPress site on decent hosting, with a lean theme and a short plugin list, gives a small business familiar editing and plenty of developers to choose from. Hosted builders offer a more tightly managed setup, and the 2025 Web Almanac found platforms like that saw “the largest gains” in Core Web Vitals, though you give up some flexibility for it.

‘Headless’ is a word you might hear from developers. It means separating the content management system from the front end visitors see, often with that visitor side built in a JavaScript framework. It can suit big ecommerce operations or organisations publishing to lots of channels at once. For most small and medium-sized businesses it adds cost and a reliance on specialist developers that the speed gain rarely justifies. Treat it as an option for the right project rather than a default.

Getting help with a slow website

If your field data’s failing and TTFB is part of the story, the fix often starts on the server. We offer hosting for business websites, and moving a site onto better hosting is often where speed work begins. If the problems are in the build, or in the pages that are meant to win enquiries, we also offer conversion rate optimisation. Rather talk it through first? Get in touch with Scott and send over the address of the site that’s bothering you.

Website Speed and Performance Explained for Business Owners