Page speed is not a minor technical detail. Since 2021, Google has formally included speed metrics — called Core Web Vitals — as direct ranking signals. A slow website is not just a bad user experience; it is an active ranking disadvantage that suppresses your position in search results relative to faster competitors targeting the same keywords.
The good news: most page speed problems are fixable without a complete website rebuild, without advanced technical knowledge, and often without significant cost. This guide explains exactly what Google measures, why it matters for your rankings, and the specific fixes — in priority order — that will have the most meaningful impact on your score and your visibility.
What this guide covers:
- How and when Google made page speed an official ranking factor — and what that actually means
- The three Core Web Vitals metrics in plain English — LCP, INP, and CLS
- How to test your website's speed and read the results correctly
- Why slow pages cause higher bounce rates that compound your ranking problem
- Six specific, prioritised fixes that cover the most common causes of slow small business websites
- Why mobile speed is even more important than desktop for rankings
- A practical action plan to fix your speed in 30 days
When and Why Google Made Speed a Ranking Factor
Page speed has been a loose consideration in Google's algorithm since 2010, when Google first acknowledged that it used loading time as a signal for desktop rankings. But for most of that decade, its weight was relatively minor — content relevance and backlink authority dominated. That changed significantly in 2018 and then decisively in 2021.
The 2018 Speed Update
In July 2018, Google officially rolled out what it called the Speed Update — explicitly extending page speed as a ranking factor to mobile searches. Before this, the speed signal only applied to desktop rankings. Given that mobile searches had already overtaken desktop, this was a significant shift. Critically, Google stated that the update would only affect pages that delivered "the slowest experience to users" — the most severely slow pages were the primary targets.
The 2021 Page Experience Update
The more significant change came with the Page Experience Update in June 2021, which introduced Core Web Vitals as official ranking signals. This was not a vague acknowledgement that speed matters — it was the introduction of three specific, measurable metrics with defined good/poor thresholds that Google uses directly in its ranking algorithm:
- Largest Contentful Paint (LCP) — how quickly the main content loads
- First Input Delay (FID) — how quickly the page responds to interaction (replaced by INP in March 2024)
- Cumulative Layout Shift (CLS) — how visually stable the page is during loading
💡 FID was replaced by INP in March 2024
In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the official Core Web Vitals metric for interactivity. INP is more comprehensive — it measures the full responsiveness of a page throughout the user's entire visit, not just the first interaction. If your testing tools still show FID, check whether they have been updated to show INP instead.
The practical implication: Google now has specific, measurable criteria for what counts as a "fast" or "slow" page. Your website either meets those thresholds or it does not — and that binary determination feeds directly into your ranking position for every search query your pages compete for.
Core Web Vitals: The Three Metrics Google Measures
Understanding what each Core Web Vital measures — in plain terms, not technical jargon — is essential for knowing which fixes to prioritise and why. Here is what each metric actually represents from a user's perspective.
How long it takes for the largest visible element on the page — usually a hero image, a large heading, or a video — to fully load and appear on screen.
How quickly the page visually responds when a user clicks a button, taps a link, or types in a form — measured across all interactions during the visit.
How much the content on your page moves around unexpectedly while it is loading — when images pop in, fonts load late, or ads shift text around under the reader's eyes.
LCP in Depth — Why Your Main Content Takes Too Long to Appear
LCP is the Core Web Vital that most small business websites fail most severely — and it is the one with the biggest ranking impact when improved. The LCP element is whichever visible piece of content takes the longest to load: typically the hero image at the top of the page, a large above-the-fold photo, or a prominent heading with a slow-loading font.
A Good LCP score means the main visible content appears within 2.5 seconds of the page starting to load. Most unoptimised small business websites achieve LCP scores of 4–8 seconds on mobile, putting them firmly in the Poor category.
What causes poor LCP?
- Uncompressed hero images: A full-resolution photograph used as a homepage banner — even if it displays at a few hundred pixels on screen — can be 3–8MB in file size. The browser must download the entire file before it can display it, adding seconds to LCP.
- Images not preloaded: Your browser does not know to load the LCP image until it has already read through significant amounts of HTML and CSS. Adding a preload instruction tells the browser to start downloading the image immediately — before other resources.
- Slow server response times: If your hosting server itself takes more than 600ms to respond to the browser's request, your LCP score starts in a hole before any content has loaded at all.
- Render-blocking resources: CSS stylesheets and JavaScript files that must fully load before anything appears on screen add directly to LCP time.
- No content delivery network (CDN): If your website is hosted on a single server and a visitor is geographically distant from it, every resource takes longer to reach them. A CDN distributes your content to servers worldwide, dramatically reducing load times for distant visitors.
INP in Depth — Why Your Page Feels Unresponsive
INP — Interaction to Next Paint — replaced FID in March 2024 because Google wanted a more complete picture of page responsiveness. Where FID only measured the first time a user clicked something, INP measures the delay between every interaction throughout the entire visit and how long it takes for the page to visually respond.
For most simple small business websites (static pages, basic contact forms), INP is rarely the primary problem. It becomes significant for pages with complex JavaScript interactions — product filters, search functions, interactive maps, chat widgets, or pages with multiple third-party scripts all competing for the browser's processing power.
💡 INP for simple small business sites
If your website is primarily informational — services pages, blog posts, contact pages — and does not have complex interactive elements, your INP score is unlikely to be Poor. Focus your speed optimisation effort on LCP and CLS first. INP becomes a priority for e-commerce sites, sites with interactive calculators or quote tools, or any page with heavy JavaScript dependencies.
CLS in Depth — Why Your Page Jumps Around During Loading
Cumulative Layout Shift measures visual stability — how much the content on screen unexpectedly moves while the page is loading. You have experienced poor CLS when you go to tap a button on a mobile page and just as your finger arrives, an image loads above it and pushes the button down, and you tap something else entirely by mistake.
Poor CLS is not just frustrating for users — it is a direct negative signal to Google about page experience quality. Common causes include:
- Images without defined dimensions: When your HTML does not specify the width and height of an image, the browser does not know how much space to reserve for it. The image loads, pushes all the text below it down, and creates layout shift. Adding
widthandheightattributes to every image tag is the single most impactful CLS fix for most sites. - Late-loading web fonts: When your page first loads, it may use a fallback system font, then swap to the custom font once it has downloaded. If the two fonts are different sizes, all the text on the page shifts when the swap happens. Using
font-display: swapwith correctly sized font fallbacks minimises this shift. - Ads and embeds without reserved space: Banner ads, embedded social media posts, or third-party widgets that load asynchronously and are not given a reserved space in the layout cause dramatic layout shifts when they appear.
How to Test Your Website Speed — The Right Way
Running an Accurate Speed Test — What to Use and How to Read the Results
Time to complete: 10 minutes | Tools: Free
Not all speed tests are equal — and the score from one tool is not the same as what Google uses to rank your pages. Here is how to get the data that actually matters.
Tool 1: Google PageSpeed Insights (pagespeed.web.dev)
This is Google's own tool and the most relevant test for SEO purposes. Enter your URL and it returns both Lab Data (a simulated test) and Field Data (real-world performance from actual Chrome users visiting your site). Field data is what Google uses for ranking. If your site does not have enough real-world traffic for field data to appear, lab data is the next best reference.
HOW TO READ PAGESPEED INSIGHTS RESULTS
- Check mobile first — click the Mobile tab (not Desktop). Mobile performance determines rankings under mobile-first indexing. A high desktop score with a poor mobile score means you have a ranking problem.
- Look at the Core Web Vitals section — the three coloured circles for LCP, INP, and CLS. Red = Poor. Orange = Needs Improvement. Green = Good.
- Scroll to Opportunities — these are the specific issues with the biggest estimated impact on your score. Focus on the top 3, in order of their estimated time saving.
- Scroll to Diagnostics — additional technical issues that affect performance even if they do not have a direct estimated saving shown.
- Note your overall Performance score (0–100). Below 50 on mobile is a significant ranking issue. 50–89 has meaningful room for improvement. 90+ is strong.
Tool 2: Google Search Console — Core Web Vitals Report
If you have Google Search Console set up (covered in our Google visibility guide), the Core Web Vitals report shows real-world performance data from actual visitors to your site — grouped by Good, Needs Improvement, and Poor — with specific page URLs listed. This is the highest-quality data available because it reflects your actual visitors' experiences, not a simulated test.
Tool 3: GTmetrix (gtmetrix.com)
GTmetrix provides more detailed diagnostic information than PageSpeed Insights and generates a waterfall chart showing exactly which resources take longest to load. Particularly useful for identifying specific large files, slow external scripts, and sequential loading problems that are harder to spot in PageSpeed Insights.
⚠️ Always test with mobile, not just desktop
Many website owners test their speed on desktop and feel satisfied when they get a high score — then do not realise their mobile score is 30 points lower. Google uses mobile-first indexing: it is your mobile performance that primarily determines your rankings. Run every speed test on mobile first, and only treat the desktop score as secondary context.
The Compounding Problem: Speed, Bounce Rate, and Rankings
Page speed affects your Google rankings in two ways, not one. The first is direct — Core Web Vitals are ranking signals, and failing them puts you at a ranking disadvantage. The second is indirect — slow pages produce high bounce rates, which are themselves negative engagement signals to Google that further suppress your rankings over time.
When a visitor arrives at your page, waits four seconds for it to load, and then leaves before seeing any content, Google's algorithm records that as a failed visit. It signals that your page did not deliver what the searcher needed — even if the content was perfect and the user only left because of the loading delay. Over hundreds and thousands of such sessions, that pattern of high bounce rates and low dwell time pushes your pages down the rankings relative to faster pages that are keeping users engaged.
| Page Load Time | Bounce Rate Increase | Conversion Rate Impact |
|---|---|---|
| 1 second (baseline) | Baseline | Baseline |
| 3 seconds | +32% higher bounce probability | Meaningful drop begins |
| 5 seconds | +90% higher bounce probability | Significant conversion loss |
| 10 seconds | +123% higher bounce probability | Most visitors lost before load |
Fix 1: Compress and Properly Format Your Images
Image Optimisation — The Single Highest-Impact Speed Fix
Impact: Very High | Difficulty: Easy | Time: 1–2 hours
Images are responsible for the majority of page weight on most small business websites — and uncompressed images are the single most common cause of poor LCP scores and low PageSpeed Insights ratings. The good news: fixing this does not require technical expertise, and the tools are completely free.
Step 1: Identify your problem images
Run your homepage through Google PageSpeed Insights. Under the Opportunities section, look for "Properly size images", "Serve images in next-gen formats", and "Efficiently encode images". These three flags tell you that your images are either too large in file size, displayed at a smaller size than their actual dimensions, or saved in an outdated format (JPEG or PNG instead of WebP).
Step 2: Compress and convert before uploading
IMAGE OPTIMISATION PROCESS
- Go to Squoosh.app — a free, browser-based image compression tool made by Google. No downloads, no account required.
- Upload your image. On the right side, change the format to WebP — WebP images are typically 25–35% smaller than equivalent JPEG files with no visible quality loss.
- Use the quality slider to find the balance between file size and visual quality. For most website images, 75–85% quality in WebP is indistinguishable from the original at normal viewing sizes.
- Resize the image to the maximum size it will be displayed at on your website. If your hero image displays at 1200px wide, there is no reason to upload a 4000px wide file. Resize it to 1200px before exporting.
- Download the compressed WebP and upload it to your website in place of the original.
- Repeat for every significant image on your site — hero images, service section images, team photos, blog post thumbnails.
Step 3: Add dimensions to image tags
For every image on your site, add width and height attributes to the HTML tag that match the image's actual display dimensions. This prevents CLS by telling the browser exactly how much space to reserve for the image before it loads, so no layout shifting occurs when the image appears.
WordPress users — use an optimisation plugin
If your website runs on WordPress, installing an image optimisation plugin automates much of this process. Imagify, ShortPixel, or Smush can bulk-compress all existing images in your media library and automatically compress new uploads as they are added. Most offer a free tier sufficient for small business sites.
✅ Expected results from image optimisation
- LCP improvements of 1–3 seconds are common after hero image compression on poorly optimised sites
- Total page size reductions of 50–80% for image-heavy pages are achievable
- PageSpeed Insights score improvements of 15–40 points on mobile are typical
- CLS improvements when image dimensions are added to HTML tags
Fix 2: Upgrade Your Hosting If It Is the Bottleneck
Hosting Quality — The Foundation That Everything Else Sits On
Impact: High | Difficulty: Medium | Cost: From £5–15/month extra
No amount of image compression or plugin removal will achieve a fast website if your underlying hosting is fundamentally slow. Budget shared hosting plans — where your website shares server resources with hundreds of other sites — can result in server response times (TTFB: Time to First Byte) of 800ms to 2 seconds, before any content has started to load. Google recommends TTFB under 800ms. Under 200ms is optimal.
How to identify a hosting problem
In Google PageSpeed Insights, look for the "Reduce initial server response time" opportunity. If it appears with a significant estimated saving, your hosting speed is a direct bottleneck. GTmetrix's waterfall chart will show the TTFB as the initial dark green bar — if that bar extends beyond 800ms, your server itself is the problem.
Hosting upgrade options
| Hosting Type | Typical TTFB | Best For | Cost Range |
|---|---|---|---|
| Budget shared hosting | 800ms – 2,000ms | Basic static sites with very low traffic | £2–5/mo |
| Managed WordPress hosting | 200ms – 500ms | WordPress sites needing reliable performance | £10–25/mo |
| Cloud hosting (SiteGround, Kinsta, WP Engine) | 100ms – 300ms | Growing businesses, e-commerce, service sites | £15–50/mo |
| VPS hosting | 50ms – 200ms | High-traffic or high-complexity sites | £20–80/mo |
For most small UK business websites, moving from budget shared hosting to a managed WordPress hosting plan or an entry-level cloud hosting plan — typically an additional £10–20 per month — is the most impactful single investment in website speed available.
Consider a Content Delivery Network (CDN)
A CDN distributes your website's static files (images, CSS, JavaScript) to servers around the world, so visitors load them from the server geographically closest to them rather than from your origin server. Cloudflare offers a free CDN tier that is straightforward to set up and can reduce load times for UK visitors on non-UK hosting significantly.
Fix 3: Enable Caching — Stop Rebuilding the Same Pages Repeatedly
Browser and Server Caching — Load Pages Once, Serve Them Instantly
Impact: High | Difficulty: Easy–Medium | Cost: Free
Caching is the process of storing a pre-built version of your web pages so they can be delivered to visitors instantly, without the server needing to regenerate them from scratch on each request. Without caching, every visitor triggers a full server-side rebuild of the page — querying the database, processing PHP (for WordPress), assembling HTML, and sending the result. With caching, the first visitor triggers that build process and the result is saved. Every subsequent visitor receives the pre-built version in a fraction of the time.
Server-side caching (WordPress)
For WordPress sites, install one of the following free caching plugins — each provides server-side caching that can cut page generation time by 80% or more:
- WP Super Cache: Made by Automattic (the company behind WordPress.com). Simple, reliable, and well-supported. Recommended for most WordPress beginners.
- W3 Total Cache: More configuration options, but more complex. Suitable for users comfortable with technical settings.
- WP Rocket: Premium (paid) option at around £40/year that combines caching with other speed optimisations in a highly polished package. Recommended if you want the most effective single-plugin solution.
Browser caching
Browser caching tells visitors' browsers to save local copies of static files — your logo, CSS, JavaScript — so on a return visit, those files load from the visitor's local storage rather than being downloaded again. This dramatically speeds up page loads for returning visitors. Browser caching is typically configured via your .htaccess file (on Apache servers) or via caching plugin settings.
💡 Check if your host includes caching by default
Many managed WordPress hosts (SiteGround, Kinsta, WP Engine, Cloudways) include built-in server-side caching that outperforms plugin-based caching. If you are on managed hosting, check their documentation before installing a separate caching plugin — you may already have it handled at the server level, and adding a plugin could create conflicts.
Fix 4: Audit and Reduce Your Plugins and Third-Party Scripts
Plugin and Script Bloat — The Invisible Performance Killer
Impact: Medium–High | Difficulty: Easy | Cost: Free
Every WordPress plugin you have installed — whether active or inactive — adds code that runs on your website. Active plugins that load scripts and stylesheets on the front end (the pages visitors see) add directly to page weight and processing time. Many small business websites accumulate plugins over time: a cookie banner, a contact form, an SEO plugin, a backup plugin, a social sharing plugin, a live chat widget, a review badge, an analytics script, a heat-mapping tool — each small in isolation, but collectively significant.
The plugin audit process
AUDITING YOUR PLUGINS AND SCRIPTS
- In your WordPress dashboard, go to Plugins → Installed Plugins. Make a list of every active plugin.
- For each plugin, ask: Is this actively being used and adding value right now? If the answer is no, deactivate and delete it.
- Use Query Monitor (free plugin) to see exactly which plugins are loading scripts on your front end and how much processing time each is adding.
- Look for duplicate functionality: do you have two SEO plugins installed? Two form plugins? Two backup plugins? Choose one and remove the other.
- Check your Google Tag Manager or website header for third-party scripts: analytics platforms, advertising pixels, chat widgets, CRM integrations. Each script adds loading time. Remove any that are not actively being used.
- Consider whether any plugin's functionality can be achieved with built-in WordPress or theme features instead — eliminating the plugin entirely.
⚠️ Live chat widgets — the hidden speed cost
Live chat widgets (Intercom, Drift, Tidio, Zendesk) are among the most impactful third-party scripts for page speed. A typical live chat widget loads 200–500KB of JavaScript and makes multiple external API calls on every page load. If you do not have staff actively monitoring chat or if your chat response rate is low, the speed cost almost certainly outweighs the conversion benefit. Test your speed with and without the widget and make an evidence-based decision.
Fix 5: Optimise Your Web Fonts
Web Font Optimisation — Preventing Layout Shift and Render Blocking
Impact: Medium | Difficulty: Medium | Cost: Free
Custom web fonts — fonts loaded from Google Fonts, Adobe Fonts, or your own hosting — add loading overhead and contribute to both LCP and CLS scores when not handled correctly. The font loading process involves external requests, file downloads, and a font-swap that can cause visible layout shift when the custom font replaces the fallback system font.
Preloading critical fonts
Add a preload link tag to your HTML <head> for your primary body font. This instructs the browser to begin downloading the font file as a high priority — before it encounters the font reference in your CSS — reducing the delay before text renders in the correct font.
Using font-display: swap
The CSS property font-display: swap tells the browser to display text immediately using a fallback system font, then swap to the custom font once it has loaded. This prevents invisible text (FOIT — Flash of Invisible Text) which delays LCP. Most Google Fonts URLs can have &display=swap appended to achieve this without touching CSS.
Limiting font variants
Loading a font with ten weight variants (100, 200, 300, 400, 500, 600, 700, 800, 900) when your website only uses three of them doubles or triples your font loading overhead unnecessarily. When importing fonts from Google Fonts, specify only the weights you actually use.
Self-hosting fonts
Loading fonts from Google Fonts requires an external DNS lookup and connection to Google's servers, adding latency. Downloading the font files and hosting them on your own server eliminates this external dependency. Use google-webfonts-helper.herokuapp.com to download self-hosted versions of any Google Font, complete with the optimal CSS to include them.
Fix 6: Eliminate Render-Blocking Resources
Render-Blocking CSS and JavaScript — Unblocking Your Page's Critical Path
Impact: Medium–High | Difficulty: Medium | Cost: Free
Render-blocking resources are CSS files and JavaScript files that the browser must fully download and process before it can display any content on the page. While the browser is waiting for these files, the page appears blank to the user — directly increasing LCP. PageSpeed Insights flags these as "Eliminate render-blocking resources" in the Opportunities section.
Deferring non-critical JavaScript
Adding the defer attribute to JavaScript tags tells the browser to download the script in the background and execute it only after the HTML has finished parsing. Adding async executes the script as soon as it is downloaded, without blocking HTML parsing. Most third-party scripts (analytics, chat widgets, social sharing buttons) should be deferred — they do not need to run before the page content appears.
Minifying CSS and JavaScript
Minification removes whitespace, comments, and unnecessary characters from CSS and JavaScript files, reducing their file size by 20–50% without changing their functionality. Most WordPress caching plugins (WP Rocket, W3 Total Cache) include minification options. For non-WordPress sites, CSS Minifier and JavaScript Minifier are free browser-based tools.
Critical CSS inlining
The above-the-fold content — the first screen of content visible without scrolling — should render as fast as possible regardless of whether the rest of the CSS has loaded. Critical CSS inlining extracts only the styles needed for above-the-fold content and places them directly in the HTML <head> tag, so the visible content can render immediately without waiting for the full stylesheet to download. This is a more advanced optimisation, but WP Rocket handles it automatically.
✅ Summary — Combined impact of all six fixes
- Image compression alone typically improves mobile PageSpeed score by 15–40 points
- Hosting upgrade typically improves TTFB from 1,000ms+ to under 300ms
- Caching reduces page generation time by 70–90% for repeat visitors
- Plugin and script audit typically reduces total page size by 15–30%
- Font and render-blocking fixes typically reduce LCP by 0.3–1 second
- Combined: most small business sites can move from a 30–50 mobile score to 70–90+
Mobile Speed — Why It Matters More Than Desktop for Rankings
Google uses mobile-first indexing for all websites — meaning it primarily uses the mobile version of your pages to determine how they rank. If your website scores 85 on desktop and 42 on mobile in PageSpeed Insights, Google is ranking you on the basis of 42. The desktop score is largely irrelevant for SEO ranking purposes.
Mobile websites face unique performance challenges that do not apply to desktop:
- Mobile network speed: Even in 2026, many mobile users are on 4G connections slower than a typical home broadband connection — and some in rural areas on 3G. Your page needs to load fast on a slow connection, not just on Wi-Fi.
- Mobile CPU limitations: Mobile devices have less processing power than laptops and desktops. JavaScript-heavy pages that run fast on a high-spec laptop can be genuinely slow on a mid-range Android phone.
- Mobile viewport differences: Fonts, images, and layouts that work beautifully at 1440px wide may be broken, tiny, or illegible at 375px. Test your site on an actual mobile device — not just in a browser's desktop device emulator.
💡 Test on a real mobile device
Browser DevTools mobile emulation gives a rough approximation of mobile layout, but it does not accurately simulate mobile CPU speed or network conditions. For a true picture of your mobile performance, open your website on an actual mid-range Android device (not a flagship phone) on a 4G connection, not on Wi-Fi. What you experience is what a significant proportion of your potential customers experience when they find you on Google.
Your 30-Day Website Speed Fix Action Plan
30 Days to a Faster Website — Week by Week
Week 1: Diagnose and Fix Images
- Day 1: Run your homepage (and 2–3 key service pages) through Google PageSpeed Insights on mobile. Screenshot the results and note your current scores.
- Day 2: Download all images currently on your site that are over 200KB. Compress and convert them to WebP using Squoosh.app. Resize to their actual display dimensions.
- Day 3–4: Re-upload optimised images to your website, replacing originals. Add width and height attributes to all image HTML tags.
- Day 5: Re-run PageSpeed Insights. Record the improvement in your LCP score and overall performance score.
- Days 6–7: Install an image optimisation plugin (WordPress) or establish a process to compress all future image uploads before they are added to your site.
Week 2: Caching and Plugins
- Enable caching via your hosting control panel (if supported) or install WP Super Cache / WP Rocket
- Audit all installed plugins — deactivate and delete anything inactive or redundant
- Review third-party scripts in your page source — remove any chat widgets, tracking pixels, or embeds that are not actively providing value
- Check your Google Tag Manager (if used) for any tags that are no longer active and remove them
Week 3: Fonts and Render-Blocking
- Audit your Google Fonts imports — reduce to only the weights you actually use on your site
- Add
&display=swapto your Google Fonts URL or implementfont-display: swapin CSS - Review render-blocking scripts in PageSpeed Insights Opportunities — add defer attributes to non-critical scripts
- Enable CSS and JS minification in your caching plugin settings
Week 4: Hosting Evaluation and Mobile Testing
- Check your TTFB in GTmetrix — if it consistently exceeds 800ms after other optimisations, evaluate hosting upgrade options
- Test your website on an actual mobile device on a 4G connection — note any layout or usability issues
- Check Google Search Console Core Web Vitals report — are any URLs listed as Poor? Prioritise fixing those specific pages.
- Compare your current PageSpeed scores with your Week 1 baseline — document the improvement
- Set a quarterly reminder to re-run the full speed audit — performance can degrade as content and plugins accumulate
By the end of 30 days, most small business websites following this plan will have meaningfully improved Core Web Vitals scores, a reduced page size, and a faster real-world user experience — with corresponding positive signals feeding into Google's ranking algorithm over the following weeks and months.
Speed is one piece of the SEO puzzle. For the complete picture: How to Get Your Business Found on Google in 2026 — A Complete Beginner's Guide — all ten steps from Google Business Profile to backlinks.
Frequently Asked Questions
Does website speed actually affect Google ranking?
Yes — this is confirmed by Google, not just an SEO industry assumption. Since 2021, Google has included Core Web Vitals (LCP, INP, and CLS) as official ranking signals through its Page Experience update. Pages that fail Core Web Vitals thresholds are at a direct ranking disadvantage compared to faster pages targeting the same keywords. Beyond the direct signal, slow pages drive higher bounce rates and lower dwell time, which are further negative signals to Google's algorithm.
What is a good Google PageSpeed Insights score?
A score of 90 or above on mobile is considered Good. Scores between 50 and 89 need improvement and are likely suppressing rankings to some degree. Below 50 on mobile is Poor and is a significant ranking issue. More important than the overall score are the individual Core Web Vitals — LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1 are the specific thresholds Google uses. You can have a score of 75 but still have a Poor LCP that is harming your rankings specifically on that metric.
What causes a slow website?
The most common causes, in rough order of frequency and impact for small business websites: uncompressed or oversized images (by far the most common cause), too many plugins or third-party scripts loading on every page, no server-side caching configured, slow or shared hosting with poor server response times, render-blocking CSS and JavaScript files, poorly optimised web font loading, and large page sizes from unminified code. Google PageSpeed Insights identifies your specific issues directly — run your URL through it and look at the Opportunities section.
How do I check my Core Web Vitals?
The three best places to check Core Web Vitals are: Google Search Console (Experience section — shows real-world field data from actual visitors), Google PageSpeed Insights at pagespeed.web.dev (shows both lab and field data), and Google Analytics 4 (which can report Core Web Vitals as custom dimensions). Google Search Console is the most important source because it shows real visitor data, which is what Google actually uses in its ranking algorithm — not a simulated lab test.
How long does it take to see ranking improvements after speeding up my website?
Google recrawls and reassesses pages over varying timescales — popular, frequently visited pages can be reassessed within days to weeks of a speed improvement; lower-traffic pages may take several weeks to months. Core Web Vitals field data in Search Console is based on a 28-day rolling average of real user experiences, so improvements take time to fully register. A reasonable expectation: meaningful ranking improvements visible in Search Console within 4–12 weeks of significant speed improvements, with the largest gains typically appearing within the first 60 days.
Should I prioritise mobile or desktop speed?
Always prioritise mobile. Google uses mobile-first indexing, meaning it primarily evaluates and ranks your website based on its mobile version. If your mobile PageSpeed score is 42 and your desktop score is 87, Google is ranking you on the basis of 42. Every speed optimisation effort should be tested on mobile first. Desktop improvements are a secondary consideration — nice to have, but not the primary ranking driver.
Not sure where your website's speed problems are hiding?
Workvera's digital advisory service includes a full website performance audit — identifying your specific Core Web Vitals issues, prioritising fixes by impact, and guiding you through the changes that will have the biggest effect on your Google rankings.
Book a Website Performance Audit