Is it really slow? Here's how to measure it in 10 minutes
PageSpeed Insights: two types of data on one page
Enter the page's address into Google's free PageSpeed Insights tool. Check the mobile and desktop results separately. At the top of the page is real-user data (field data, from the Chrome User Experience Report, based on the last 28 days), and below it a one-off lab measurement. The two aren't the same: field data shows what your visitors actually experience, while the lab measurement shows you where you can improve. A low-traffic page has no field data, so in that case you'll only see the lab measurement.
Don't take the score between 0 and 100 too seriously. It fluctuates from one measurement to the next. A page scoring 70 can still feel fast to visitors. The few metrics below it tell you more.
Core Web Vitals explained
Google measures the experience of using a page with three metrics. The thresholds need to be met for 75% of visits:
| Metric | What it measures | Good | Poor |
|---|
| LCP (Largest Contentful Paint) | When the largest content element appears, typically the main image or the heading | 2.5 s or less | over 4 s |
| INP (Interaction to Next Paint) | How long it takes between a click and the visible response | 200 ms or less | over 500 ms |
| CLS (Cumulative Layout Shift) | How much the content jumps around while loading | 0.1 or less | over 0.25 |
INP replaced the FID metric in March 2024, so older articles may still mention FID. The thresholds come from Google's web.dev site.
Server response time (TTFB)
The "Time to First Byte" measures how long it takes the server to send the first byte. If this is high, it doesn't matter how fast the browser is, everything has to wait. According to Google's guidance, a good value is 0.8 seconds or less. If PageSpeed Insights gives the "Reduce server response time" suggestion, the problem is on the server or in the application, not in the images.
The Search Console report
Google Search Console's "Core Web Vitals" report shows, group by group, which URLs are good and which need fixing. This is useful because you see more than just the homepage, for example, all your product pages at once.
The eight most common causes of a slow website, by impact
1. Overloaded hosting, slow database
On shared hosting, another customer's traffic spike slows your page down too, and the package limits your CPU and memory. The symptoms are a high TTFB (especially at peak times) and a slow admin interface. The fix is better hosting or your own dedicated resources on aVPS server.
2. No page cache
Without caching, the server rebuilds the page from the database for every single visitor. On WordPress, a caching plugin handles this; in front of a bigger system (for example, a Magento webshop), Varnish serves the finished page from memory instead. This is often the single biggest win.
3. Unoptimised images
A 5 MB photo straight off a camera stays 5 MB even on a phone screen. You need to resize the image to its display size, convert it to a modern format (WebP or AVIF), and only load below-the-fold images when the visitor scrolls to them.
4. Too many plugins, page builder code
Every plugin can bring its own CSS and JavaScript files, which often load even on pages that don't need them. Page builders (Elementor, Divi and the like) are convenient, but they generate far more code than a hand-written template.
5. Third-party scripts
Chat widgets, maps, video, social embeds, advertising and tracking codes: each one loads from a different external server and each one eats into the browser's time budget. It's worth reviewing which ones you actually need, and loading the rest only on interaction.
6. Outdated PHP version
Newer PHP versions are noticeably faster and more secure. If a page is running on a version that's no longer supported, updating it will also speed things up, but you need to check first that the theme and plugins are compatible.
7. A bloated database
Over the years, post revisions, temporary data and settings left behind by deleted plugins pile up. On WordPress, the size of the autoloaded options matters in particular, because these are read on every single page load.
8. Layout shift (CLS)
If an image or a banner is placed on the page without a set size, the browser only knows how much space it needs once it has loaded. Until then, the text jumps out of the way. The fix: give every image and embed a width and height, and reserve space in advance for banners that appear later.
What can you do yourself and what needs developer work?
| Task | You can do it yourself | Needs a specialist |
|---|
| Images | Uploading smaller images, deleting unnecessary ones | Automatic WebP and AVIF conversion, responsive image sizes |
| Plugins | Disabling plugins you don't use | Loading the necessary plugins' code only where it's needed |
| Third-party scripts | Deciding which chat widget, map or tracking code you actually need | Deferred loading, server-side tracking |
| Caching | Turning on a caching plugin with default settings | Varnish, Redis, correctly configuring exclusions (cart, account) |
| Server | Upgrading the hosting package | PHP upgrades, database tuning, moving to your own server |
In what order should you fix it?
- Server first:if the TTFB is high, every other fix is only partial. Caching, the PHP version, and better hosting if needed.
- Then the images:this is the most common cause of a poor LCP and it's quick to fix.
- Then the JavaScript:plugins, page builder, third-party scripts. This improves your INP.
- Finally, the CLS:sizes and reserved space, usually just a few template changes.
- Measure after every step:so you can see what each fix actually achieved.
In our own system, we use multiple caching layers (APCu, Redis, Varnish), automatic AVIF and WebP conversion, and minimal JavaScript. For WordPress sites, we take over your existing site and handle its speed and maintenance; you can read more about this on theWordPress website developmentpage.