A customer clicks your ad or a Google result, stares at a blank screen and a few seconds later heads back to the results. You paid for the click and got no enquiry. Website speed decides whether anyone sees your offer at all, and Google measures it on real users when assessing your site.
We explain Core Web Vitals, how to read PageSpeed Insights and how to speed up WordPress in 10 steps. Then we show what we did with our own site and when chasing extra test points stops paying off.
Why website speed affects sales
Every second of waiting gives a customer time to change their mind. On a phone, with a weak signal and a thumb hovering over the back button, patience runs out fast. A slow site loses people before they read the headline.
It hurts most where you pay for traffic:
- Ads. You pay for a Meta or Google click even if the page never finishes loading, so a slow site raises your real cost per customer.
- Forms and bookings. A button that responds with a delay looks broken. Some people click twice, others close the tab.
- First impressions. A jumping layout, flickering fonts and slow images make a business look less professional, even with a good offer.
So when we design websites meant to sell, performance is part of the offer. Planning a new site? See how we approach building websites focused on sales.
Core Web Vitals: LCP, INP and CLS in plain English
Core Web Vitals are three metrics Google uses to describe user experience: how fast content appears, how fast the page responds and whether the layout stays stable. In 2024 INP replaced the FID metric (web.dev).
- LCP (Largest Contentful Paint) measures when the largest element on the visible screen appears, usually the header image or a large block of text.
- INP (Interaction to Next Paint) measures how quickly the page responds to a click, tap or key press, throughout the visit, not just the first click.
- CLS (Cumulative Layout Shift) measures how much elements shift while loading. Typical case: you’re about to tap a link and a banner pops up above it.
The thresholds below come from Google’s documentation on web.dev. A page passes when at least 75% of visits (the 75th percentile) fall within the “good” range, separately for mobile and desktop.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5–4 s | > 4 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Note the 75th percentile. The average can look fine while one in four customers, usually on older phones, has a poor experience. That is the group Google looks at.
PageSpeed Insights: lab data vs real-user data
PageSpeed Insights shows two sets of numbers, and confusing them is the most common misunderstanding about performance.
Real-user data (field data)
The top part of the report comes from the Chrome User Experience Report (CrUX). These are measurements from real Chrome users collected over the last 28 days (web.dev). Google uses this data to assess Core Web Vitals. A small, low-traffic site may have none, and then the report shows only the lab test.
Because of the 28-day window, field data changes gradually after fixes. You’ll see the full effect after about four weeks.
Lab data (Lighthouse)
The lower part of the report and the 0–100 score come from a Lighthouse test: a single page load on a simulated phone and connection. The score is a weighted average of several metrics. Total Blocking Time carries the most weight (30%), followed by LCP and CLS (25% each), with FCP and Speed Index at 10% each (Lighthouse documentation).
A lab test can’t measure INP, because it doesn’t know when a real user will click. Instead it shows TBT, the time scripts blocked the browser: a useful warning sign, but not real responsiveness.
What this means for you:
- The lab score is for diagnosis. It shows what to fix and whether a fix worked.
- Real-user data shows how things really are. That’s what Google looks at.
- The score can shift a few points between tests because of network conditions, browser extensions and ads. Test several times and watch the trend.
Fun fact. In a study by Deloitte and the agency 55, commissioned by Google, researchers analysed 37 big-brand websites and more than 30 million sessions. Cutting mobile load time by just 0.1 seconds was linked to an 8.4% rise in conversions for retail sites and 10.1% for travel sites. A tenth of a second is shorter than the blink of an eye (source: web.dev, Milliseconds make millions).
How to speed up a WordPress site in 10 steps
The steps run from most gain for least risk. Before each change, back up and check the site on a phone, because optimisation can break a menu, slider or form.
1. Turn on page caching
A cache stores a ready-made version of each page, so the server doesn’t rebuild it from the database on every visit. It is usually the biggest and cheapest gain. One trusted caching plugin or your host’s server-side cache is enough; two at once will clash.
2. Combine and minify CSS and JavaScript
Minification strips spaces and comments from files. Combining reduces the number of separate files the browser has to fetch. With HTTP/2 combining helps less than it used to, so test: sometimes it’s better to combine only files loaded on every page.
3. Defer JavaScript loading
Scripts in the page header block display. The defer attribute lets the browser show content first and run scripts later, which directly improves FCP and LCP. Then check the mobile menu, sliders and forms still work.
4. Delay third-party widgets
Live chat, Google Maps, embedded YouTube videos, ad pixels and review widgets all load scripts from other servers. Some can start only after the user’s first interaction or a click. Show a thumbnail with a play button instead of a video player, and load the map on click. Delay pixels and analytics carefully so you don’t lose conversion data.
5. Convert images to WebP and size them correctly
At the same quality, WebP is usually much lighter than JPG or PNG. Size matters as much: a 4,000-pixel-wide photo in a 400-pixel box is wasted transfer. WordPress creates smaller versions; make sure your theme uses them.
6. Turn on lazy loading, but not for the first screen
Lazy loading only loads images when the user scrolls to them. WordPress does this by default. The exception is the header image, often the LCP element, which should load at once, ideally with high priority.
7. Tidy up fonts and set font-display
Every font weight and style is a separate file. Keep only the ones you actually use, and host Google Fonts locally on your own server. Set font-display: swap so text appears immediately in a fallback font instead of waiting for the font to download.
8. Remove unnecessary plugins
Many plugins load scripts and styles on every page, even where they do nothing. Remove what you don’t use. For the rest, check whether you can switch off their assets where they aren’t needed, such as form scripts outside the contact page.
9. Set element dimensions so the layout doesn’t jump
Specify the width and height of images and reserve space for banners, ads and embedded content. That way the browser knows the layout before it downloads the files, and CLS stays low.
10. Check your hosting
If the server takes a long time to respond to the first request (the TTFB metric), no plugin will make up for it. Look for a current PHP version, SSD or NVMe drives, server-side caching and a data centre close to your customers. Cheap shared hosting can be the most expensive saving in the whole project.
Case study: how we sped up efektywnymarketing.pl
In October 2026 we looked hard at our own site. The browser had to download 138 files and 2.8 MB of data before the page was complete. On a phone, the first content appeared after 3.8 seconds.
We worked through the list from the previous section:
- we switched off the theme’s loading animation, which was hiding the content, and combined and minified the CSS and JavaScript files (page caching was already on),
- we deferred scripts that aren’t needed to display the first screen,
- we delayed third-party widgets until the user starts interacting with the page,
- we converted images to WebP and set lazy loading below the first screen,
- we removed unused fonts and set font-display: swap,
- we removed plugins and assets that no longer added anything.
| Measurement | Before | After |
|---|---|---|
| Number of requests | 138 | about 45 |
| Page size | 2.8 MB | 0.9 MB |
| PageSpeed mobile | 69 | 79 |
| FCP (mobile) | 3.8 s | 2.2 s |
The site now downloads about a third as many files and a third as much data. The first content appears 1.6 seconds sooner. For someone on a phone, that’s the difference between “something’s loading” and “I can see the offer”.
When extra PageSpeed points aren’t worth it
A score of 79 isn’t green. We could have kept going, but we costed it honestly. More points meant building separate first-screen styles into the page code and maintaining them with every design change, or dropping features that help us sell.
Google itself says a score of 100 is extremely hard to achieve and not expected (Lighthouse documentation). In its search guidelines it adds that good Core Web Vitals don’t guarantee the top spot, and that search always tries to show the most relevant content, even if the page performs worse (Google Search Central).
In our experience, further optimisation stops paying off when:
- real-user data in PageSpeed Insights or Search Console is already in the “good” range and you’re only improving the lab score,
- more points would mean removing the chat, video, calculator or another element that brings in enquiries,
- the cost of rebuilding the theme exceeds what you could gain in conversions at your current traffic,
- your content and offer have bigger gaps than your speed. Then it’s better to invest in copy, photos and site structure.
A fast site with a chat that answers customers beats a score of 100 on a site nobody contacts you through. We make the same calls in booking system projects. In the system we built for DMD Arena Częstochowa, a sports and events venue, customers arrange the room on an interactive floor plan and see the price live. That module needs more scripts than a brochure site, so it loads only where needed. More examples are in our work.
Website speed, ads and automation
If you run campaigns, start by checking the pages you send paid traffic to. That’s where every second costs you money. With Meta and Google campaigns, we test the landing page before increasing the budget.
The same goes for an AI assistant or live chat. Done well, it loads after the user’s first interaction and doesn’t slow the initial load. That’s how we deliver our automation and AI assistants for websites.
Frequently asked questions
Does website speed affect Google rankings?
Yes, but it isn’t the only factor. Core Web Vitals are part of the page experience signals that Google’s ranking systems consider. Content relevance comes first, so a fast site with weak content won’t outrank good content on a slower site.
What is a good PageSpeed Insights score?
Lighthouse rates 90–100 as good, 50–89 as needing improvement and 0–49 as poor. More important are the real-user data at the top of the report and whether LCP, INP and CLS are green.
Why does my score change with every test?
A lab test is a single load under specific conditions. Network traffic, server load, ads and third-party scripts all affect the result. Take several measurements and compare the median values, not a single score.
Is installing an optimisation plugin enough?
A caching and optimisation plugin covers steps 1 to 4, and sometimes images too. It won’t fix a heavy theme, unnecessary plugins or poor hosting. Check each setting by hand too, because aggressive optimisation can break forms and menus.
How much does it cost to speed up a WordPress site?
It depends on the state of the site. Sometimes a few hours of configuration are enough, and sometimes the theme needs rebuilding or the hosting needs changing. So we start with measurements and a list of fixes ranked by value for a reasonable cost.
Find out how much a slow site is costing you
Enter your website address in PageSpeed Insights and compare your LCP, INP and CLS with the table in this article. If the results are red or orange, write to us or call +48 794 505 965 or +48 22 602 25 32. We’ll analyse your site and tell you which fixes will actually bring in enquiries and which will only raise the test score.
