Page Speed: How to Test and Speed Up Your Site, Step by Step

Page speed is how fast a page loads and becomes usable for a visitor. It is not one number: it covers when the first content appears, when the main content is visible, and how quickly the page reacts to a tap. Google folds the user-facing part into Core Web Vitals, and you can fix most of it with the same short list of changes on almost any site.

Does page speed affect Google rankings?

Yes, in a limited way. Google’s page experience documentation says its ranking systems use Core Web Vitals, that there is “no single signal”, and that site owners should not focus on only one or two aspects. It adds that trying to get a perfect score just for SEO reasons may not be the best use of your time, and that Google still shows the most relevant content even when the page experience is sub-par.

So treat speed as a tiebreaker for search and a conversion lever for your business. Slow pages lose visitors before they read a word, and that loss shows up in your sign-ups whatever Google does.

What is a good page speed?

Use the Core Web Vitals pass marks, measured on real visitors at the 75th percentile:

• LCP (main content visible): 2.5 seconds or less.
• INP (reaction to taps and clicks): 200 milliseconds or less.
• CLS (layout stability): 0.1 or less.

A Lighthouse performance score of 90 to 100 is rated good, 50 to 89 needs improvement, and below 50 is poor. Treat that score as a debugging aid. PageSpeed Insights states that lab data helps you debug, while field data shows what real users experience, and the two can differ.

How do you speed up your site, step by step?

1. Measure real users first. Paste your homepage and your two busiest page templates into PageSpeed Insights. The top block shows field data from the Chrome UX Report (a trailing 28-day window at the 75th percentile). If a small site has too little traffic, PageSpeed Insights falls back to whole-site data or shows only lab data.
2. Cut server response time. Slow hosting, uncached pages and long redirect chains delay everything after them. Turn on page caching (most CMS caching plugins do this), put a CDN in front of the site, and remove needless redirects. web.dev lists a CDN, avoiding cache-busting URL parameters and faster server processing as the fixes for a slow first byte.
3. Compress text files. Serve HTML, CSS and JavaScript with Brotli or gzip, and minify the code. Your host or CDN can switch this on in a few clicks.
4. Shrink and size images. Look at images first, because one unresized photo can outweigh the rest of the page. Resize them to the size they display at, use a modern format such as WebP or AVIF, and lazy-load the images below the fold. Do not lazy-load the main image at the top, because that delays LCP (see image file size).
5. Remove scripts you do not need. Delete unused plugins, trackers and chat widgets. Load the rest with defer or async, and split large JavaScript bundles so each page loads only its own code. Audit third-party scripts first, since you do not control their code. Sites built on client-side rendering need extra care (see JavaScript SEO).
6. Tell the browser what matters. Preload the main image or font with <link rel="preload">, open early connections to third-party hosts with preconnect, and give the LCP image fetchpriority="high".
7. Reserve space for late content. Set width and height on images and embeds, and fix a slot for ads and banners, so the page does not jump while it loads.
8. Serve everything over HTTPS with HTTP/2 or HTTP/3. Modern protocols load many files in parallel. Check that your host or CDN has this on (see HTTPS).
9. Retest and repeat. Run PageSpeed Insights again after each change, one change at a time, so you know what helped. Field data in Search Console takes weeks to catch up.

How do you measure the result?

• Search Console, Core Web Vitals report: the number of Good, Needs improvement and Poor URLs, grouped by shared problem (see Google Search Console).
• PageSpeed Insights: field data for the page and the whole origin, plus the Lighthouse diagnostics.
• WebPageTest or the DevTools Network panel: a waterfall chart shows which file holds up the page. Look for the biggest file and the longest gap before the first request.
• Your analytics: compare bounce rate and conversion rate on fixed pages before and after.

Lab scores vary from run to run, so run each test three times and compare the middle result.

What mistakes should you avoid?

• Testing only on a fast office connection. Real visitors use mid-range phones on mobile networks. PageSpeed Insights simulates a mid-tier phone for its mobile test, so trust that run over your own laptop.
• Chasing a score of 100. Google itself says a perfect score for SEO reasons may not be the best use of your time. Fix the pages with real traffic and failing field data.
• Stacking speed plugins. Three caching or minify plugins fight each other and break layouts. Use one, and test the site after switching it on.
• Lazy-loading everything. web.dev warns against overusing lazy loading, and never lazy-load the LCP image.
• Ignoring third-party scripts. One tag manager container full of old tags can undo every image fix you made.
• Testing mobile last. Google indexes the mobile version of your site (see mobile-first indexing), so test mobile first.

Where can you learn more?

The free digital marketing module of the Fe/male Switch startup school covers how a founder checks the technical checks of a new site. Next steps on SEO100: read how Core Web Vitals are scored, then run a site audit to catch speed problems across all your pages.