--- title: "Website speed is not a one-off job" description: "Making a site fast once takes an afternoon. Keeping it fast while things keep getting added is the work that really counts." url: "https://fwrd.digital/blog/website-speed-is-not-a-one-off-job/" published: "2026-09-19T20:13:26.168Z" modified: "2026-09-19T20:13:26.168Z" --- # Website speed is not a one-off job _Guide · 19 Sep 2026 · 6 min read_ Making a site fast once takes an afternoon. Keeping it fast while things keep getting added is the work that really counts. Written by: FWRD Almost any website can be made fast once. You compress the images, throw out a script nobody uses any more, and the score jumps. That is an afternoon of work and it feels good. Six months later that same score is back where it was, without anyone having done anything wrong. This piece is about why that happens, how you spot it early enough, and which routine holds it off without turning into a project. ## Slowdown comes from normal use A chat widget gets added, because visitors ask questions outside office hours. A tracking pixel goes in, because someone wants to know where the enquiries come from. A photo straight from the camera lands on a service page, because it looks good and nobody thinks about the file format. An external service extends its own embed and announces that nowhere. None of those decisions is wrong in itself. One by one they are even sensible. Added together your page loads noticeably slower, and precisely because it happened step by step nobody can point at where it went wrong. The responsibility sits a little bit everywhere, and therefore nowhere. That is also why a one-off optimisation round is so tempting. The result is visible straight away, it fits in an afternoon and you can tick it off. Only, that measures the moment, not the direction. The question that matters is not whether your site is fast at one moment, but whether it still is three months from now while the normal work simply carries on. ## What slowness costs you and why you never see it Visitors do not wait. Someone who arrives on a phone, looks at an empty page for a few seconds and then taps back to the search results does not show up in your statistics as a missed job. That visitor does not show up at all. That is what makes slowdown so unpleasant: it costs you exactly the thing you never get a notification about. On the other side the gain is invisible too. Nobody calls to say your site loaded nice and fast. That makes speed feel like work without a return, while in practice it is the foundation the rest of your page needs to do its job. A good story on a slow page does not get read. ## What exactly gets measured Speed is not a single number. Google has laid down three metrics for it that together describe how a page feels: how quickly the largest piece of content at the top appears, how quickly the page responds to the first tap or click, and how still the layout stays while it loads. In [the explanation from Google](https://web.dev/articles/vitals) the bar sits at 2.5 seconds for the largest content, 200 milliseconds for the response and 0.1 for the shift, measured at the three quarter point of all visits (consulted on 15 September 2026). That three quarter point matters more than it sounds. It means you are not judged on your average visitor, but on the slowest quarter. A site that scores fine on a fast laptop with fibre and stutters on a four year old phone on a train does not pass. Google describes in [the documentation on search results](https://developers.google.com/search/docs/appearance/core-web-vitals) how those metrics weigh in (consulted on 15 September 2026). ## What we measure on our own sites Measuring in a testing tool is one thing. Measuring with real visitors is another, and only the second says something about reality. On the sites FWRD hosts we collect the three metrics in the browser of the visitor, aggregated across all sites together. Between 31 July 2026 and 15 September 2026 that produced 288 measurements of the largest content, spread across 20 sites. The three quarter point of those came out at 1,244 milliseconds, well inside the bar Google names for [the largest content](https://web.dev/articles/lcp). That is good news, and it is also the easiest part: you mostly improve that metric with hosting close to the visitor and with images that are not larger than the space they are shown in. The metric that describes how quickly a page responds to a tap is in worse shape. Over the same period, between 31 July 2026 and 15 September 2026, there were 123 measurements from 15 sites, with a three quarter point of 276 milliseconds. That sits above the limit of 200 milliseconds Google holds for [response speed](https://web.dev/articles/inp). It is a small set of measurements and it is no disaster, but it is exactly the kind of figure you only run into if you keep measuring instead of running a single test report. Writing down a result like that is more uncomfortable than leaving it out. Still, it is the only form that is usable: a figure that always comes with a tick next to it tells you nothing about what to work on next. > A site rarely gets slow because of a mistake. It gets slow because of twenty reasonable decisions in a row. ## Want to know where your site stands? Take the free check. You'll see right away what your site needs to get found more often. ## A routine that makes slowdown visible early This is not a full time job. What you need is a routine you carry out the same way every time, because only then does a difference actually mean something. - Pick three fixed pages and stick to them: your homepage, your most important service page and the page most visitors land on. - Measure each page several times and write down the middle result, not the prettiest one. Measurements fluctuate, and the prettiest result is the least honest. - Measure again after every publication in which something on the front end changed, even if the change looked like text only. - Write down each time what you changed and what the measurement did. Without that log you will not know a few months on why the site got faster or slower. That last step is skipped most often and is exactly the step that makes the difference. With a log you see patterns over time: which kind of change really helps, and which one mostly gives a feeling of progress. Keep lab and field apart while you do it. A lab measurement runs the page under fixed conditions and is therefore repeatable: you use it to prove that a change has an effect. A field measurement comes from real visitors and reacts slowly, but it is the only one that tells you whether anyone notices. The practical order is lab first, then field. A broader analysis of where pages get stuck in practice is in [the performance chapter of the HTTP Archive](https://almanac.httparchive.org/en/2024/performance). ## What you can clear out straight away Start with what others have added to your page. Take stock of all third party scripts and for each one look for the person who once wanted it. If nobody uses it any more, that is the cheapest second you will ever win back. Third party scripts are also the part of your page you have the least say over. Then look at the heaviest image above the fold. If it is delivered larger than the space it is shown in, every visitor pays for pixels they never see. And check whether anything on your page jumps into place only after loading: a banner, a cookie notice or a font that swaps late. That costs no loading time, but it makes the page unusable at exactly the moment someone wants to tap something. If you want to know where your site stands and what can concretely be done about it, [the approach to improving an existing website](/improve-your-website/) will get you going. If you would rather hand it over completely, you can [outsource the maintenance of the site](/website-maintenance/), so that measuring and adjusting are part of the work instead of something you have to remember yourself. Speed is not a project with a delivery date. It is a property you maintain, just like the content of your pages. The sites that stay fast are not the sites that were once optimised hardest, but the sites where someone takes a look every single time. ## Side notes - **Context**: A testing tool measures under ideal conditions. Your visitor does not, and that gap is exactly where slowdown hides. - **In the product**: FWRD measures the three metrics in the browser of real visitors and puts every measurement next to the one before it. ## Topics - [Speed](https://fwrd.digital/blog/tag/speed/) - [SEO](https://fwrd.digital/blog/tag/seo/) _Written with AI by FWRD. Sources and figures are linked in the text._