Your website’s loading speed affects more than just user experience. It feeds directly into how search engines rank your pages and whether visitors stay long enough to become customers. Google PageSpeed Insights gives you a free, structured way to measure that performance and understand where your site is falling short.
This post covers what the tool measures, why the score matters, and the most effective steps you can take to improve it, including the part your hosting plays.
What Google PageSpeed Insights actually measures
Google PageSpeed Insights is a free tool that analyses how quickly your web pages load and render. It looks at individual components, including images, scripts and text, and scores your site from 0 to 100. Scores are grouped into three bands:
- 0–49 (red): Poor performance. Pages in this range are likely losing visitors before they load.
- 50–89 (amber): Average. There is room for improvement, and some users will notice the delay.
- 90–100 (green): Good. Your page is loading well across most conditions.
The tool tests performance separately for desktop and mobile, so check both scores when reviewing your results. Mobile performance is weighted heavily by Google, so a strong desktop score does not tell the full story.
Beyond the score itself, PageSpeed Insights provides a breakdown of what is slowing your site down and suggests specific fixes. That diagnostic output is where the real value lies.
Lab data vs field data
PageSpeed Insights reports two kinds of result, and understanding the difference matters. The performance score at the top comes from lab data: a single test run in a controlled environment on a simulated mid tier device, which is useful for diagnosing performance issues repeatably. Below it sits field data from the Chrome User Experience Report (CrUX), real user CrUX data gathered from actual users who visited your site over the previous 28 days. This real world data reflects how actual users experience your pages on real connections and devices. Google uses it for your Core Web Vitals assessment, so a strong lab page speed score does not guarantee a pass if real users are getting a poor user experience. The report also surfaces diagnostics such as Speed Index and main thread activity to show where time is being spent.
Why your PageSpeed score affects more than load time
Visitors do not wait. If a page takes too long to appear, most people will leave before it finishes loading, and that behaviour signals to search engines that your content is not worth surfacing. A poor score feeds into higher bounce rates, lower dwell time and reduced search visibility. For website owners, web performance is not a vanity metric: it affects search rankings, conversions and revenue.
Page speed is also tied to Google’s Core Web Vitals, the set of metrics Google uses as a ranking signal. The three current Core Web Vitals metrics are Largest Contentful Paint (LCP), which measures loading, Cumulative Layout Shift (CLS), which measures visual stability, and Interaction to Next Paint (INP), which measures responsiveness to user interactions. A related lab metric, First Contentful Paint (FCP), marks when the first text or image appears. Interaction to Next Paint replaced First Input Delay in March 2024, so older guidance that still references First Input Delay is out of date.
Google assesses your pages using real-world field data from actual visitors alongside the lab data PageSpeed Insights generates. A slow site can cost you positions in search results regardless of how good your content is. The faster your pages load, the more likely visitors are to stick around once they arrive.
How to improve your Google PageSpeed Insights score
The improvements below address the most common causes of poor PageSpeed scores. Work through them methodically rather than making sweeping changes all at once. Changing too much at the same time makes it harder to identify what actually moved the needle. Each fix targets the performance metrics behind your PSI score, and the performance report will confirm which ones helped.
Getting your images to stop dragging load times down
Images are one of the most common culprits behind slow pages. Fixing image-related issues rarely means removing them. A few targeted changes make a significant difference.
Sizing images correctly is the starting point. Oversized images take longer to load than necessary. As a rough guide, landing page images typically work well at around 100 x 100 px, while product images on sales pages rarely need to exceed 400 x 400 px. Check what dimensions your theme or layout actually displays before exporting.
Format matters too. JPEG and PNG are familiar, but newer formats like JPEG 2000, JPEG XR and WebP offer better compression at comparable quality. Many free online converters handle this without degrading the image. If you are running WordPress, our guide to optimising WordPress images with AVIF covers a more modern option worth considering.
For pages with many images, such as a clothing shop with 50 or more product photos, deferring offscreen images is worth doing. This technique, known as lazy loading, means images below the fold only load as the user scrolls to them, rather than all at once when the page first opens. Combined with compressing large image files so they shrink without losing quality, the visitor sees content faster and your score improves as a result.
If you use GIFs, consider converting them to video formats such as MP4 or WebM. The visual result is identical, but browsers handle video files more efficiently than animated GIFs.
Reducing the impact of render-blocking resources
Render blocking resources are files, typically CSS and JavaScript files, that a browser must fully process before it can display anything on screen. Every render blocking file adds to your load time, sometimes by several seconds. Third party code, such as analytics, chat widgets and ad scripts, often makes this worse because each external script is another file the browser has to fetch and run on the main thread.
There are three main approaches to reducing their impact:
- Inlining small CSS or JavaScript files into your HTML can reduce the number of separate requests the browser needs to make. This works best when you have a small number of files. If you have a large amount of inline JavaScript, this approach can backfire by increasing HTTP requests and slowing things down further.
- Deferring JavaScript tells the browser to load your scripts after the main page content, so they do not block rendering. This is one of the more reliable improvements you can make.
- Removing unused files is worth doing periodically. Code that was once needed may no longer serve any purpose after a redesign or plugin change. Unused scripts and stylesheets still get loaded unless you remove them, so eliminate render blocking resources you no longer use.
Minifying your HTML, CSS and JavaScript
Minification is the process of stripping out unnecessary characters from your code, including whitespace, comments and line breaks, without changing how it functions. The result is smaller files that load faster. Most content management systems have plugins or built-in tools that handle this automatically. It also reduces bandwidth usage, which matters on high-traffic pages.
Using browser caching to avoid reloading unchanged content
Browser caching stores a version of your page’s assets, such as images, headers and fonts, on the visitor’s device after their first visit. When they return, the browser loads those saved assets locally rather than fetching them from the server again. For returning visitors, this can dramatically reduce perceived load time. If you are running WordPress, caching plugins handle most of this configuration without requiring manual server changes.
Cutting down on redirect chains
A redirect sends a visitor from one URL to another. One redirect is rarely a problem, but chains of redirects add measurable delay to every page load. Review your site’s redirect structure and remove any that are no longer needed. Where a redirect is necessary, make it a single hop rather than a chain.
How your hosting affects server response time
Many of the fixes above tune what happens in the browser. Before any of that runs, the browser has to wait for the first byte of data to arrive from your server. That delay is measured as Time to First Byte, and PageSpeed Insights flags it directly under “Reduce initial server response time” when it is slow.
Time to First Byte sits underneath your Core Web Vitals. A slow response time pushes back when Largest Contentful Paint can happen, because the page cannot start rendering until the server replies. No amount of image compression or minification fixes a server that takes a second to respond. A slow server response, often a sign of slow hosting, is one of the biggest causes of slow sites, and reducing server response times usually does more for overall site speed than any front-end tweak. The work has to start at the source.
Three things at the hosting level move this figure. Server-side caching stores rendered pages so the server does not rebuild them from the database on every request. A content delivery network serves your assets from a location closer to the visitor, which cuts the round trip. The hosting platform itself sets the ceiling, since shared resources, an older PHP version or an overloaded server all raise response times. Our guide on when to move from shared hosting to a VPS covers the point where a busy site outgrows its plan.
Work through changes steadily
A low PageSpeed score is fixable, but trying to address every issue at once tends to create new problems. Work through the changes above one at a time, re-run the PageSpeed Insights test after each one, and track what actually improves your score. The tool itself will tell you which issues are having the biggest impact, so use that prioritisation rather than guessing. Chasing a perfect score of 100 is rarely necessary; moving into the green band on both mobile and desktop is what counts, and you do not need to be a web developer to make most of these changes.
If you have worked through the front-end fixes and your response time is still holding your score back, the hosting underneath is the next place to look. Our WordPress hosting and cPanel hosting plans run on infrastructure tuned to keep server response times low, which gives the rest of your optimisation work a faster starting point.
