Site Speed Wins Customers: How to Get a PageSpeed 90+
A customer searches Google for a service you offer. They tap your site on their phone, the screen stays white, something is spinning. After three seconds they go back to the results and tap a competitor. No report ever recorded it — as far as you’re concerned, that person never existed.
That’s what a slow site costs you. You can’t see it in your stats, because you only measure the people who waited for the page to load. The ones who bailed earlier simply vanish. And website speed isn’t a matter of taste or “vibe” — it’s a measurable technical property that Google checks on every page and factors into its rankings.
In this article I explain exactly what Google measures, why the typical business website fails those measurements, and what has to change in the architecture so that a 90+ PageSpeed score is the norm rather than an achievement.
What Google measures: Core Web Vitals in plain English
For years Google has been collecting data on how pages behave for real Chrome users. From that data came a set of three metrics called Core Web Vitals. Each answers one specific question that every visitor asks themselves without realising it.
LCP — how fast you see content
LCP (Largest Contentful Paint) measures the time from clicking a link to the moment the largest element on the page appears on screen — usually the header image or the main block of text. It answers the question: “does this site even work?”
Google counts the result as good when LCP is 2.5 seconds at most. Above 4 seconds — bad. On a phone with average mobile internet, most business websites in Poland land somewhere in between, in the “needs improvement” zone.
INP — does the site respond to touch
INP (Interaction to Next Paint) measures how much time passes from your click or tap to a visible reaction from the page. You open a menu — does it appear instantly, or after a noticeable pause? In 2024 this metric replaced the older FID, because it better captures user frustration.
A good result is 200 milliseconds at most. It sounds trivial, but a delay of half a second is something a person clearly feels — the page seems to stutter. The main culprit here is almost always JavaScript: the browser is busy processing scripts and has no spare moment to respond to touch.
CLS — does the content jump around
CLS (Cumulative Layout Shift) measures layout stability. You know the feeling: you’re reading a paragraph, a banner suddenly loads and the text slides down. Or you go to tap a button, and at the last moment an image jumps above it and you tap an ad instead. Every shift like that raises the CLS score.
A good site has a CLS below 0.1 — meaning practically nothing moves after the first render. The cause of the jumping is banal: images and embedded elements with no declared dimensions. The browser doesn’t know how much space to reserve, so it shifts the content once the file finally arrives.
These three metrics Google collects from real traffic (the CrUX report) and scores each URL separately. This isn’t a theoretical lab test — it’s a record of what your visitors actually experienced over the last 28 days.
What speed changes for the business
Two things: your Google rankings and the behaviour of the people who have already arrived.
Rankings. Google has officially confirmed that page experience — with Core Web Vitals at the forefront — is a ranking signal. Not the most important one: good content will beat a fast void. But with comparable content, and that’s what most local service markets look like, the faster site has the edge. In a competitive keyword like “accountant Toruń” every signal counts, because the differences between the sites in the top ten are small.
User behaviour. Here the data is unambiguous about the direction: the longer a site takes to load, the larger the share of people who give up before seeing anything at all. Google’s research on mobile traffic shows that the probability of abandonment rises sharply with each additional second of loading — and most traffic to business websites today is exactly that, phones, often on a weak connection out in the field. Industry conversion analyses confirm the same direction: faster sites sell better, because fewer people drop off on the way to the form or the phone number.
There’s also a third effect, harder to measure: credibility. A site that loads instantly and doesn’t jump around comes across as well kept. A site that chokes subtly suggests the business treats the rest of its duties the same way.
Why the typical business website is slow
Most business websites in Poland run on WordPress with a page builder (Elementor, Divi) or on a builder like Wix. These are convenient tools for assembling pages, but their architecture works against speed — and not because of bugs, but by design.
A universal theme has to serve thousands of different uses, so it loads styles and scripts for everything your site will never touch. Every plugin you add throws in its own CSS and JavaScript — usually on every subpage, whether it’s needed there or not. The page builder generates deeply nested HTML and ships its own rendering engine written in JavaScript. On top of that comes the server: on every visit WordPress assembles the page anew from the database, and shared hosting does it slowly.
The sum is always similar: a few hundred kilobytes of JavaScript to download and process, render-blocking styles, photos straight from the camera weighing two megabytes each, and fonts pulled from external servers. On a fast laptop in the office you can’t see it. On a mid-range phone over LTE — you see all of it.
Typical symptoms and their real causes:
| Symptom | Cause | Fix |
|---|---|---|
| A long white screen before anything appears | Theme CSS and JS block rendering; the server responds slowly | Extract critical CSS, defer scripts, serve static HTML |
| The main image loads with a delay | A 2 MB JPG file, scaled only in the browser | Convert to WebP, size to fit the screen, preload the hero image |
| Content jumps while loading (high CLS) | Images with no width and height attributes, fonts swapped on the fly | Declared dimensions for every image, font-display: swap, and reserved space |
| The page doesn’t respond to clicks for the first few seconds (poor INP) | The browser is grinding through hundreds of kilobytes of JavaScript from plugins and the builder | Remove unnecessary scripts; ultimately, an architecture that barely ships any JS |
| Slow even on repeat visits | No CDN, every request goes to a single, often overloaded server | Caching on CDN nodes close to the user |
Some of these things can be patched on an existing WordPress: a cache plugin, image compression, cutting out surplus add-ons. That genuinely helps and is worth doing. But there’s a ceiling you can’t patch your way through — because the problem isn’t the configuration, it’s the architecture itself. We compare the two approaches in more depth in the article WordPress vs. a static website.
Architecture that’s fast by nature
A 90+ PageSpeed score doesn’t come from heroic optimisation. It comes from the site not doing the slow things in the first place. Four elements make up the whole.
A static site instead of one generated live
In the static approach (in our case: the Astro generator) all the subpages are created once, at the moment of publishing — as ready-made HTML files. The server assembles nothing on the user’s visit, doesn’t query a database, doesn’t run PHP code. It simply sends a file. Response time drops from hundreds of milliseconds to a few dozen, and the page starts to render almost instantly.
The second consequence is just as important: a static site ships JavaScript only where it’s genuinely needed — for handling a form, for example. The menu, the content, the footer are pure HTML and CSS. The phone’s browser has nothing to grind through, so INP drops to values you can’t feel.
CDN — files served from Poland, not the other side of the world
The static files go to a CDN (in our case Amazon CloudFront), which keeps copies of them on servers scattered around the world, including Warsaw. A user in Poland gets the site from a node a few dozen kilometres away, not from a single hosting box that happens to be serving five hundred other sites. Add to that caching: a file fetched once is served to the next visitors without touching the source.
Images in WebP, at the size they’ll actually be shown
The WebP format gives files tens of percent smaller than JPG at the same visible quality. But the format itself is only half the job. The other half: an image displayed at 800 pixels wide shouldn’t be sent at 4000 pixels. When the site is built, every photo is converted and scaled to its actual usage size, with variants for different screens, and gets declared dimensions — so nothing jumps and CLS stays at zero.
Fonts from your own server, trimmed to what you need
Wiring up Google Fonts the standard way means an extra connection to a foreign server and downloading the full files with characters for dozens of languages. Instead, fonts are served from your own domain, subset down to Polish characters and Latin, only in the weights the site actually uses. The difference can be more than tenfold: tens of kilobytes instead of hundreds. The text appears at once, with no swaps that wreck the layout.
None of these elements is exotic. The catch is that on WordPress with a page builder each one takes a fight with the tool, whereas in a static architecture they’re all the natural state of things.
How to check your own site
Go to pagespeed.web.dev and enter your site’s address. It’s Google’s official, free tool — PageSpeed Insights. You’ll get a result in a dozen or so seconds, and it’s worth knowing how to read it.
Two kinds of data. At the top of the report is field data: measurements from real Chrome users over the last 28 days, provided the site has enough traffic. These are the values Google actually takes into account. Below is the lab test (Lighthouse): a simulated visit on a mid-range phone with a throttled connection, summed up as a score from 0 to 100.
What the numbers mean. A score of 90–100 is green — a fast site. 50–89 is orange — it works, but it’s losing users and points in Google’s eyes. Below 50 — red, a serious problem. Look above all at the mobile score: the mobile test is far stricter than the desktop one, and it’s the one that matches the conditions in which most customers will see your site. A site with a desktop 95 can have a mobile 40.
How to read the recommendations. Under the score, PageSpeed lists specific opportunities to improve: “Eliminate render-blocking resources”, “Serve images in next-gen formats”, “Reduce unused JavaScript”. If you were searching for “how to improve pagespeed” — this is your to-do list, sorted by estimated gain. Notice how many items are about JavaScript and images: on a typical builder site that’s usually 80% of the list.
Three practical notes. First, check not only the homepage — a services or contact subpage is often slower. Second, results wobble by a few points between runs; that’s normal, what matters is the order of magnitude. Third, if there’s no field data (low traffic), go by the lab test — it’s more cautious, so a good lab result all but guarantees good Core Web Vitals in the field.
If your site gets 40–60 points on mobile and the list of recommendations reads like this article’s table of contents — the problem almost certainly lies in the architecture, not in individual settings.
Speed as a standard, not an optimisation project
You can go the patching route: an audit, plugins, compression, a few weeks of tweaks and a score raised from 45 to 70. Or you can build the site on an architecture where 90+ is the starting point.
Sites built with Sitario have that second model baked into the standard: static Astro, hosting on AWS infrastructure with CloudFront, images automatically converted to WebP with declared dimensions, self-hosted fonts with a Polish subset. A PageSpeed 90+ on mobile is our acceptance criterion for every site — checked before handover, not promised in the pitch.
Because the customer who clicked and didn’t wait — doesn’t come back. And the one whose page opened instantly has just started reading about your business.