Page Speed Fixes: Faster Servers, Lighter Pages, Fewer Blockers
A slow page is almost always slow for a small number of reasons: the server takes too long to answer, the browser is told to wait for files before it can draw anything, or the page simply asks for too many bytes.
Our Page Speed Analyzer measures the page with real-user and lab data, then names the specific requests, files and scripts that are holding it back. This page follows a page load from the first request to the finished screen, shows where time usually goes, and links the guide that fixes each finding.
Where the time goes in a page load
Every page load is a chain of steps, and a delay at any step pushes back everything after it. Thinking in these stages makes the analyzer's findings much easier to act on, because each finding belongs to one link in the chain.
| Stage | What the browser is doing | Usual causes of delay | Guide |
|---|---|---|---|
| 1. Server response | Connecting, then waiting for the first byte of HTML | Uncached page generation, slow database queries, distant hosting, redirect chains | TTFB |
| 2. Discovery | Reading the HTML and finding the CSS, scripts, fonts and images it needs | Important files only referenced from inside other files or injected by JavaScript | LCP |
| 3. Blocking | Waiting for stylesheets and synchronous scripts before painting | Large
CSS files, scripts in the head without defer or async | Render-blocking, CSS size |
| 4. Downloading | Fetching images, fonts and remaining scripts | Oversized images, old formats, big JavaScript bundles | Images, JS bundles |
| 5. Running | Executing JavaScript and building the final layout | Framework hydration, tag managers, chat widgets, A/B testing tools | Third-party, JS bundles |
Open the network waterfall in the analyzer, or in the Network panel of your browser's developer tools, and you can see these stages as bars. A long first bar points at the server. A gap before images start downloading points at discovery or blocking. A wide spread of script bars late in the load points at JavaScript weight.
Fixing the server end first
Time to First Byte is the wait between the browser asking for the page and the first byte of HTML arriving. Nothing else can start until then, so a slow server makes every later figure worse, however well the front end is built. Google's web.dev guidance suggests aiming for about 0.8 seconds or less as a rough guide, and faster is better.
The biggest wins at this stage are usually not code changes:
- Cache whole pages. If a page is the same for every anonymous visitor, generate it once and serve the saved copy. Page caching plugins, server-level caches and CDN edge caching all do this.
- Serve from near your visitors. A UK business with UK customers gains from UK or nearby European hosting, or a CDN with local points of presence.
- Remove redirect hops. Each redirect is another round trip. Link straight to the final URL, including the correct protocol, host and trailing slash.
- Compress text. HTML, CSS and JavaScript should be sent with Brotli or gzip compression. Most hosts support this, but it is not always switched on.
- Set caching headers on static files. Versioned CSS, JS, fonts and images can be cached by the browser for a long time, so repeat visits and later pages download almost nothing.
If the page cannot be cached because it is personalised, look at what the server does while building it. Slow database queries, calls to external APIs and plugins that run on every request are the usual suspects. Server timing headers and your host's slow query log help find them.
Page weight: images, scripts, styles and tags
Once the HTML has arrived, speed is mostly about how much the browser has to download and run. The analyzer lists the heaviest requests, and they tend to fall into four groups.
Images
On many content and shop pages, images make up the largest share of bytes. The common faults are photos uploaded straight from a camera or phone, images far larger than the space they are shown in, and old formats where WebP or AVIF would be much smaller. Images below the fold should load lazily; the main hero image should not.
JavaScript
JavaScript costs more than its download size suggests, because the browser has to parse, compile and run it, and phones do that slowly. A single bundle containing every feature for every page is the usual problem. Splitting code by route and dropping unused libraries pays off in both load time and responsiveness.
CSS
Stylesheets block the first paint, so a large stylesheet delays everything visible. Frameworks and themes often ship rules for components the page never uses.
Third-party tags
Analytics, advertising pixels, chat widgets, reviews carousels, heatmaps and A/B tools each bring their own scripts, and they often load further scripts of their own. They are easy to add and rarely removed.
The fix guides
Each guide covers one analyzer finding: what causes it, how to confirm it on your own page and how to fix it safely.
Server and first paint
Fixing slow Time to First Byte covers edge
caching, CDN choice, database tuning and moving from building pages on every request to serving pre-rendered
HTML. Fixing render-blocking resources
walks through the waterfall, inlining the small amount of CSS needed for the first screen, loading the
rest without blocking, and adding defer or async to scripts. Fixing
slow Largest Contentful Paint brings those together for the main content element, including preloading
and fetchpriority="high".
Heavy files
Fixing unoptimised images covers
modern formats, responsive sizes with srcset, compression and lazy loading. Fixing
heavy JavaScript bundles covers code splitting, tree shaking and swapping large libraries for smaller
ones. Fixing heavy CSS covers removing unused
rules with tools such as PurgeCSS, and loading non-critical styles later. Fixing
third-party script bloat covers auditing each tag, consolidating through a tag manager, server-side
tagging and removing tags that no longer earn their place.
Stability
Fixing layout shift covers the speed work that can make pages jump, such as lazy-loaded images without dimensions and fonts swapping in late.
By platform
WordPress covers hosting quality, caching and optimisation plugins, image plugins and moving to a lighter theme. Shopify covers auditing theme weight, removing leftover app code and setting a script budget per app. Next.js covers choosing static, server or incremental rendering per page, the image and font components, and server components to reduce client JavaScript.
Which findings to fix first
Most sites have two or three root causes that account for the bulk of their slowness. The aim is to find those, not to clear every line of the report. Work in this order:
- Slow server response. If TTFB is poor, fix it before anything else, because it delays every other stage and the fixes (caching, hosting, CDN) often help every page at once.
- The main image or heading. Make sure the element visitors wait for is discovered early, not lazy-loaded, correctly sized and in a modern format.
- Render-blocking files. Deferring scripts and trimming the CSS needed for first paint are usually small template changes with a visible result.
- Third-party tags. Removing a tag nobody uses any more costs nothing and can save a surprising amount of time. Ask whoever added each tag whether it is still needed.
- Bundle and stylesheet size. These take more engineering effort, so tackle them once the quick wins are done and you can measure the remaining gap.
Where two findings seem equally important, pick the one that affects more pages or more visitors. And keep an eye on anything that is slow only on mobile: phones are where heavy pages hurt most.
Order of work
- Measure a baseline. Run the Page Speed Analyzer on each key template and save the results: TTFB, total page weight, number of requests and the list of heaviest files.
- Test uncached and cached. Load each page twice. A big difference between the first and second visit tells you caching headers are working; no difference on repeat visits suggests they are not.
- Fix the server. Turn on page caching and compression, check the CDN, and remove redirects.
- Fix the critical path. Deal with render-blocking files and the main content element.
- Cut the weight. Compress and resize images, split and trim JavaScript, remove unused CSS, and review every third-party tag.
- Re-test and compare. Run the analyzer again with the same settings and compare against your baseline.
- Protect the gains. Add a page weight budget to your release checks, and review tags and plugins every few months.
For the full background, read the Page Speed Guide and the Image Optimisation Guide. If the analyzer reports layout shift, the CLS Guide explains how to track down the elements responsible.
1. What is a good page load time?
There is no single official figure for total load time, because pages keep loading scripts and images long after they look ready. It is more useful to measure specific moments. Google's guidance is that the main content should appear within 2.5 seconds for at least three quarters of visits, and that the server should start responding in roughly 0.8 seconds or less. Beyond that, faster is better, and the right target depends on what your competitors achieve.
2. What is Time to First Byte and why does it matter?
Time to First Byte is how long the browser waits between requesting a page and receiving the first byte of the response. It includes connecting to the server, any redirects and the time the server spends building the page. Because the browser cannot do anything useful before the HTML arrives, a slow TTFB delays every later step. It is usually fixed with page caching, a CDN, better hosting or faster database queries rather than front-end changes.
3. What does render-blocking mean?
A render-blocking resource is a file the browser must download and process before it draws anything on screen. Stylesheets linked in the head block rendering so that the page does not appear unstyled, and scripts in the head without defer or async attributes stop the browser reading the rest of the HTML. The fix is to keep only what the first screen needs on the critical path and load everything else in a way that does not hold up the first paint.
4. Does page speed affect Google rankings?
Yes, to a degree. Google uses Core Web Vitals, which are largely speed and stability measurements, as part of its page experience signals. It has also said that great content can still rank well on a page with average speed, so speed is not a substitute for relevance. The larger effect is usually on visitors: slow pages lose people before they read anything, which affects enquiries and sales regardless of where the page ranks.
5. Why is my site fast on my computer but slow for customers?
Your own computer is probably much faster than the typical customer's phone, your connection is likely better, and you may be seeing cached copies of files from earlier visits. Many customers visit on mid-range phones over mobile data, where large images and JavaScript take far longer to download and run. Test with the analyzer, or with throttling switched on in your browser's developer tools, to see the page the way most visitors experience it.
6. Will a CDN make my website faster?
Often, yes, but it depends on what is slow. A content delivery network stores copies of your files on servers closer to visitors, which cuts the time to download images, scripts and stylesheets, and many can also cache whole HTML pages. If your pages are slow because they are very heavy, or because the server takes a long time to build each uncached page, a CDN helps less. Fix page weight and caching alongside it.
7. How many third-party scripts is too many?
There is no fixed number. What matters is what each script costs in download size and main-thread time, and whether it still does something useful. A single chat widget or testing tool can cost more than several small analytics tags. Use the analyzer's list of third-party requests to see what each one weighs, ask who owns it and what it is for, and remove anything nobody can justify. Load the rest after the main content where possible.
8. Should I aim for a Lighthouse score of 100?
It is not necessary. The Lighthouse performance score is a weighted summary of lab measurements on one simulated device, and chasing the last few points often means effort with little benefit to real visitors. A better aim is to pass Core Web Vitals in real-user data on your important templates and to keep page weight under a budget you set. If the score is low, use its diagnostics to find the biggest problems, then move on.
The Page Speed Analyzer measures your page with real-user and lab data and names the specific server responses, files and scripts causing each slow metric, so you can start with the fix that saves the most time.
Run the Page Speed Analyzer →