Website Loading Speed: How to Test and Improve It

Website loading speed is how quickly a visitor sees the main content of a page and can interact with it. Google measures it with three Core Web Vitals: the main block of the page should appear within 2.5 seconds, the page should respond to taps within 0.2 seconds, and elements shouldn’t jump around while loading.

Below: how to test your site’s speed with free tools, what the numbers in the reports mean, what slows sites down most often and what to do about it.

Why website speed matters

It affects enquiries and sales. In the Deloitte study for Google, Milliseconds Make Millions, speeding up a mobile site by just 0.1 seconds increased conversions for retail sites by 8.4% and page views for lead generation sites by 7%.

It counts in search, but doesn’t decide everything. Google confirms that Core Web Vitals are used in ranking. But the same page says plainly that search always tries to show the most relevant content, even if the page isn’t the fastest. So speed won’t push a weak page to the top, but among pages of similar quality it can give you an edge.

It decides how much of your ad budget actually reaches the site. You pay for every click, even if the person closed the tab before the page loaded. That’s why speed is one of the first requirements for landing pages that run on ads. That was the case, for example, with Beauty International School: the site was built for advertising, and maximum loading speed was in the brief right next to conversion.

How to test your website speed

All the main tools are free:

How to test properly:

1. Look at the mobile results. PageSpeed Insights opens them first, and that’s what Google judges your site by.
2. Tell the two parts of the report apart. The top one, real-user data, is what your visitors actually experience. The bottom one, with a score from 0 to 100, is a lab test of a single load on a simulated slow phone. The top part matters more for decisions. A score of 100 isn’t the goal: a site with a score of 70 and green real-user data is doing fine.
3. Test several pages. The home page is often the lightest. Test a service page, an article, a catalogue page, the ones ads and search lead to.
4. Repeat the test 2–3 times. Lab results fluctuate, so don’t trust a single run.

Core Web Vitals in plain words

These are the three metrics Google uses to judge whether a page is comfortable to use. A result counts as good if at least 75% of visits meet the threshold (source: web.dev).

INP replaced the earlier FID metric in March 2024, so any advice that still mentions FID is out of date.

What slows websites down most often

• Images. The most common cause. A 5–10 MB photo from a phone, uploaded as is, is slower than the rest of the site put together.
• An off-the-shelf theme or page builder. They carry code for hundreds of features you don’t need, and the browser loads it on every page.
• Plugins. Each one adds its own files. Twenty plugins mean twenty sets of scripts and styles.
• Third-party scripts. Live chat, ad pixels, a map, an embedded video, a review widget. Each pulls code from someone else’s server whose speed you don’t control.
• Fonts. Several weights of several typefaces add up to hundreds of kilobytes before any text appears.
• Hosting and no caching. If the server builds the page from scratch every time, the visitor waits before loading has even started.

How to speed up your website: 10 steps

1. Compress images and convert them to WebP. The file size should match the display size: a 4,000-pixel photo for an 800-pixel block is overkill.
2. Serve smaller images to phones. The browser gets several sizes of one image and picks the right one. More in our article on responsive design.
3. Lazy-load everything below the first screen, but not the hero image: the browser should get that as early as possible.
4. Set dimensions for images and banners so space is reserved for them in advance. This removes layout shifts (CLS).
5. Embed videos through a preview. Instead of the full YouTube player, show an image with a play button and load the player after the click.
6. Remove unnecessary plugins and scripts. Go through the list: what do you actually use, and what’s left over from an old experiment?
7. Defer third-party scripts. Chat and pixels can load after the visitor has seen the page.
8. Turn on caching so finished pages are served without being rebuilt on the server.
9. Use a CDN if your visitors come from different countries: files will be served from the server closest to each visitor.
10. Check your hosting. A current PHP version, enough resources, a server in the same region as your customers.

Steps 1, 5, 6 and 8 can usually be done yourself in the admin panel. The rest need a developer.

Speed is built in during development

You can speed up an existing site, but only so far. If it’s built on a heavy theme or page builder, some of the code can’t be removed: everything rests on it. Then optimisation takes you from red to amber, not to green.

That’s why it’s cheaper to build speed in from the start: write only the code you need, plan images and fonts at the design stage, and keep third-party scripts to a minimum. It’s the reason we build WordPress sites without off-the-shelf themes or page builders. How this approach compares on price with a template build is covered in our article on how much a website costs.

If the site is fast but enquiries are still few, speed is no longer the problem. What to check next is in our article on the website UX audit.