Website Speed: How to Test and Improve It

Google measures website speed with three Core Web Vitals metrics: LCP (under 2.5 s), INP (under 200 ms) and CLS (under 0.1). The data comes from real users, not from a test. A slow site loses both rankings and the people who leave before the page loads. Below: how to run a website speed test the right way, the most common problems, and 8 steps that make the biggest difference without rebuilding the site.

Why website speed is not just about SEO

Speed usually comes up in the context of rankings: "Google loves fast sites." That is true, but it is not the main reason to work on it. Speed is a ranking factor, but one of hundreds. A slow site with strong content will still outrank a fast but empty one.

The real reason is different. In Ukraine, where most of my projects are, more than two thirds of traffic is mobile, often on an unstable connection - and the picture is similar in most markets. Someone who waits five seconds for a page to open usually goes back to the search results and clicks the next site. You will not see this in your rankings - you will see it as a high bounce rate and low conversion despite normal traffic.

That is why in every SEO audit I treat speed not as a "technical box to tick" but as something with a direct impact on revenue: how many people you bring in and how many of them you lose on the first screen.

Core Web Vitals in plain English

Google has boiled speed down to three metrics. They do not measure an abstract "load time" - they measure what a person actually experiences.

An important detail that people often miss: Google calculates these metrics from data from real Chrome visitors over the last 28 days, not from a test result. So if your audience browses on budget phones over mobile data, your metrics will be worse than what a test on a fast office laptop shows. That is why "PageSpeed gives me 90" and "Search Console shows my pages in red" are not a contradiction - they are two different things.

How to run a website speed test correctly

1. The Core Web Vitals report in Search Console

The most important source. It shows how Google sees your site based on real-user data: which pages are "good", which "need improvement" and which are "poor", separately for mobile and desktop. If you have never opened this report - start there.

2. PageSpeed Insights

Google's free tool for testing a single page. Look at the top block - that is the field data from real users. Below it is a lab test with a 0-100 score and a list of recommendations. The score is useful as a reference point, but it is not a ranking factor - Google looks at the field metrics.

3. The eyeball test

The simplest and most honest test: open the site on your own phone over mobile data, not Wi-Fi. Not from cache - in incognito mode. If you had to wait, your customers are waiting too.

A typical mistake is testing only the homepage. The homepage usually gets polished, while category pages, product pages and articles are where the problems live. Test the pages that actually get traffic.

What slows websites down most often

Over years of audits, I have ended up with a fairly stable list. Nine times out of ten, the problem is one or more of the items below.

• Heavy images. 3-5 MB photos uploaded straight from the camera, as JPEG, with no compression. The most common and easiest problem to fix;
• Third-party scripts. Chats, review widgets, ad pixels, maps - each loads its own code. Five or six of these widgets can easily add 2-3 seconds;
• No caching. The browser downloads everything from scratch every time, even though it could take styles and images from memory;
• Slow hosting. The server takes a long time before sending the first byte. Often it is the cheapest plan, shared with a hundred other sites;
• A bloated theme. An "all-in-one" WordPress theme that loads a dozen libraries, of which two are actually used;
• Fonts. Several font families in multiple weights from an external service. Until they load, text is either invisible or jumps around.

How to improve website speed: 8 steps with the biggest effect

Ordered from simplest to most complex. The first four can usually be done in a day and deliver the biggest gains.

1. Compress images and convert them to WebP

WebP gives the same visual result at 25-35% smaller file size than JPEG. Add proper scaling on top: a full-width banner does not need to be 4000 pixels wide if it is displayed at 400. On this site, for example, the header photo weighs 97 KB in WebP instead of 176 KB in JPEG, with a fallback kept for older browsers.

2. Enable caching and compression on the server

A few lines in the .htaccess file, and the browser stops re-downloading styles, scripts and images every time, while the server sends files compressed. Here is a working snippet that is also used on this site:

If your site runs on WordPress, any decent caching plugin does the same. The key is that it is enabled and configured, not just installed.

3. Lazy-load images below the fold

Add the loading="lazy" attribute to images that are not visible on the first screen. The browser will load them only when the user scrolls down. One change - and a page with thirty product photos loads six first.

4. Remove or defer unnecessary scripts

Go through the list: chat, social media widget, analytics counter, an old ad pixel for a campaign switched off long ago. Delete what you do not need. Load what you do need after the main content with defer, or add it through Google Tag Manager so you can manage everything in one place.

5. Set dimensions for all images and blocks

This is about CLS. When an image has no width and height specified, the browser does not know how much space to reserve for it, and the text jumps when it loads. Someone goes to tap a button - and an ad is already in its place. Specifying dimensions solves the problem completely.

6. Use fewer fonts

Two font families in two or three weights are enough for any website. And add the display=swap parameter when loading them, so text is shown in a system font while the main one loads instead of staying invisible.

7. Use a CDN

If you have visitors from other countries or a large site, a content delivery network serves files from the server closest to each visitor. For a site with a purely local audience on good local hosting it is not critical; for an international site it is a must.

8. Switch hosting if the server is slow

A TTFB (time to first byte) above 600-800 ms means the problem is the server, and no amount of image optimization will fix it. This is the most expensive step on the list, which is why it comes last - but sometimes it is the only one that really helps.

Three myths about website speed

"You need a score of 100 in PageSpeed." You do not. The score is a lab benchmark; Google ranks based on field Core Web Vitals. A site scoring 65 with "green" metrics in Search Console is in a better position than a site scoring 95 with "red" ones. Chasing 100 often breaks functionality for the sake of a number.

"A caching plugin is enough." A plugin covers one item out of eight. If a page loads 4 MB of images and six widgets, caching only helps returning visitors - and visitors from search are new.

"Speed up the site and rankings will grow." Speeding up takes your foot off the brake, but it does not press the gas. If the content is weak and there are no backlinks, a fast site will remain a fast site on page two. Speed is one part of ongoing SEO work, not a replacement for it.

Where speed matters most

Online stores. They have thousands of pages and tens of thousands of images, and every delay while a shopper is choosing a product is a person who has gone to a competitor. In e-commerce SEO, technical optimization always comes first, before content and links - otherwise those will not work to their full potential.

The second category is sites with a mobile audience outside big cities: services, delivery, local businesses. Connections are worse and phones are simpler, so the same 3 MB per page feels twice as painful as it does in a capital city like Kyiv.

Where to start today

1. Open the Core Web Vitals report in Search Console and see how many pages are "poor" on mobile;
2. Run the three pages with the most traffic through PageSpeed Insights - not the homepage;
3. Check the image weight on those pages: any files over 300-500 KB are your first task;
4. Count the third-party scripts on the page and turn off the ones you do not use;
5. Check whether caching is enabled - in your hosting settings or plugin.

That is enough to move most pages from "red" to "yellow" or "green" within a week. After that - targeted work on whatever is left.