Your website’s speed affects everything that matters: where you rank, whether visitors stick around, and how many of them convert. A one-second delay in page load time can reduce conversions by up to 20% on mobile. Google has used page speed in its ranking algorithm since 2010 for desktop and 2018 for mobile, and it’s only become more important since Core Web Vitals rolled in during 2021.
This guide isn’t a developer tutorial. It’s for the person who needs to understand what’s slowing their site down, which fixes deliver the biggest returns, and how to brief whoever’s responsible for making it faster. You don’t need to write a single line of code. You do need to know what to ask for.
What Is Site Speed (and Why Does It Keep Coming Up)?
Site speed is the general term for how quickly your web pages load and become usable. It’s not a single metric. It’s a collection of measurements that cover different parts of the loading process: how fast the server responds, how quickly content appears on screen, and how soon someone can actually interact with the page.
You’ll hear “site speed” and “page speed” used interchangeably. Technically, page speed refers to individual pages while site speed describes the overall performance across your whole domain. In practice, the distinction rarely matters. What matters is whether your pages load fast enough to keep visitors engaged and satisfy Google’s performance expectations.
Three numbers keep coming up in speed conversations:
Page load time – how long until the page is fully loaded and functional
Time to First Byte (TTFB) – how quickly the server sends back its first response after someone requests a page
Core Web Vitals – Google’s three specific metrics for loading, interactivity and visual stability
TTFB is worth understanding because it’s the starting line. If your server is slow to respond, everything else gets delayed. Think of it as the gap between clicking a link and the browser even beginning to build the page. Google considers anything over 800 milliseconds as needing improvement.
We’ve written a detailed guide to Core Web Vitals that breaks down LCP, INP and CLS individually. For the purposes of site speed, the key thing to know is that Google measures your speed using real visitor data, not lab tests. Your site needs to be fast for the people actually using it, not just when tested on your developer’s laptop.
Why Site Speed Matters More Than You Think
Rankings
Google first made page speed a desktop ranking factor in 2010, then extended it to mobile in 2018. Since 2021, Core Web Vitals have been part of the ranking algorithm. Speed alone won’t get you to position one, but when two pages offer similar content and authority, the faster one gets the edge.
That matters most in competitive niches where multiple sites are fighting for the same keywords. If you’re already investing in content and link building, a slow site could be quietly undermining those efforts.
Bounce Rate
The data on this is consistent and stark. Google’s own research found that as page load time goes from one second to three seconds, the probability of a visitor bouncing increases by 32%. Push that to five seconds and it jumps to 90%.
On mobile, where most browsing happens now, the threshold is even tighter. Over half of mobile visitors will leave a page that takes longer than three seconds to load. They’re not reading your content, filling in your forms, or adding anything to their cart. They’re gone.
Conversions
Speed has a direct, measurable effect on your bottom line. Portent’s research found that conversion rates drop by roughly 4.42% for each additional second of load time in the first five seconds. Vodafone improved their Largest Contentful Paint by 31% and saw an 8% increase in sales.
Whether you’re generating leads, selling products, or driving phone calls, faster pages mean more of your existing traffic actually does what you want them to do. That’s often a bigger commercial win than ranking one position higher.
Crawl Efficiency
This one’s less obvious but still worth knowing. Google allocates a crawl budget to each site, which determines how many pages Googlebot will crawl in a given period. Slow pages eat into that budget because each request takes longer to complete. If you’ve got a large site with thousands of pages, poor speed can mean Google simply doesn’t get around to crawling and indexing all your content. Poor crawlability compounds over time, particularly for e-commerce sites or publishers adding content regularly.
How to Check Your Site Speed (Without Being a Developer)
You don’t need developer tools to get a clear picture of your site’s performance. Three free tools will tell you most of what you need to know.
Google PageSpeed Insights
The most accessible starting point. Enter any URL at pagespeed.web.dev and you’ll get two sets of results:
Field data (from real Chrome users) – this is what Google actually uses for ranking decisions
Lab data (simulated test) – useful for diagnosing specific issues but not what determines your rankings
Focus on the field data section first. If it says “This URL does not have sufficient real-world speed data,” your page doesn’t get enough Chrome traffic for Google to have a dataset. That’s common for smaller sites.
The lab section gives you a performance score out of 100 and a list of specific opportunities to improve. Don’t obsess over the number. Look at the individual recommendations and their estimated time savings.
Google Lighthouse
Built into Chrome’s developer tools (right-click any page, select “Inspect,” then the “Lighthouse” tab). It runs a more detailed lab test than PageSpeed Insights and gives you actionable diagnostics. Particularly useful for before-and-after testing when you’re making changes.
GTmetrix
A third-party tool that lets you test from different server locations and connection speeds. Its standout feature is the waterfall chart, a visual timeline of every resource your page loads and how long each one takes. For a non-developer, it’s the single most useful diagnostic. You can see exactly what’s slowing things down and point your developer at the specific item causing the problem.
The Fixes That Make the Biggest Difference
Here’s where most speed guides lose non-developers. They list 20 optimisation techniques in no particular order and leave you to figure out which ones matter. This section is organised by impact, starting with the changes that typically move the needle most.
Image Optimisation (High Impact, Easy)
Images are the single most common reason for slow pages. They’re also the easiest problem to fix.
Most websites serve images that are far larger than they need to be. A 3MB hero image designed for print resolution will load painfully slowly on a mobile phone. The fix is straightforward:
Compress your images. Tools like TinyPNG, ShortPixel and Squoosh reduce file sizes by 50-80% with no visible quality loss. On WordPress, plugins like Imagify or ShortPixel handle this automatically.
Use modern formats. WebP images are typically 25-35% smaller than equivalent JPEGs at the same visual quality. Most browsers have supported WebP for years. If your site is still serving everything in JPEG or PNG, switching to WebP is one of the simplest wins available.
Serve the right size. A 2000px-wide image displayed in a 600px container means the browser downloads three times more data than it needs. Responsive images solve this by delivering different sizes depending on the device.
Lazy load below-the-fold images. Lazy loading tells the browser to only download images as the visitor scrolls toward them. One important caveat: never lazy load the main image at the top of the page (the LCP element), which will hurt your largest contentful paint score.
Browser Caching (High Impact, Set-Once)
When someone visits your site for the first time, their browser downloads everything: HTML, CSS, JavaScript, images, fonts. Browser caching tells the browser to store those files locally so repeat visits load almost instantly.
A first visit might require 50-100 HTTP requests. A cached return visit might need five or six. That’s a massive difference for sites with repeat visitors.
On WordPress, caching plugins like WP Rocket or W3 Total Cache handle the configuration. On other platforms, it’s typically a server or hosting panel setting. Either way, it’s a one-time setup that keeps working.
Content Delivery Network (Medium-High Impact)
A CDN stores copies of your site’s files on servers around the world. When someone in London requests your page, they get served from a nearby server rather than one in Dallas. The physical distance data travels matters, and a CDN shrinks it.
Cloudflare is the most widely used CDN and has a free tier that’s genuinely useful, including automatic minification and image optimisation. For most small to medium business sites, it delivers noticeable speed improvements with minimal setup.
Image CDNs like Cloudinary and imgix go further by automatically optimising, resizing and serving images in the best format for each visitor’s device.
Minification of CSS, JavaScript and HTML (Medium Impact)
Minification strips unnecessary characters from your code (whitespace, comments, line breaks). The code works identically but the files are smaller, meaning faster downloads.
Most WordPress caching plugins include minification built in. WP Rocket will minify and combine your CSS and JavaScript files with a checkbox.
One caution: combining multiple files into one (concatenation) used to be best practice but can cause problems on sites using HTTP/2, which handles multiple small files more efficiently. If your site is on HTTP/2 (most modern hosts support it), minify but don’t concatenate.
Render-Blocking Resources (Medium Impact, Developer Task)
When a browser starts building your page, it encounters CSS and JavaScript files that it needs to download and process before it can display anything. These are render-blocking resources, and they’re a major contributor to slow perceived load times.
Critical CSS means identifying the CSS needed to render above-the-fold content and loading it inline. Everything else gets loaded after the main content is visible.
Deferring non-critical JavaScript (analytics, chat widgets, social sharing buttons) means the browser doesn’t wait for them before showing content.
Both are developer tasks but well-understood ones. If PageSpeed Insights flags “eliminate render-blocking resources,” this is what it’s asking for.
Server Response Time (Variable Impact)
Your server response time, measured as TTFB, sets the floor for everything else. If the server takes 1.5 seconds just to start sending data back, you’ve already burned through more than half of Google’s 2.5-second LCP threshold before a single pixel appears.
Common causes of slow server response:
Cheap shared hosting where your site shares resources with hundreds of others
No server-side caching so the server rebuilds every page from scratch on each request
Unoptimised databases that are bloated with post revisions, transient data and overhead
Geographic distance between your server and your audience (solved by a CDN)
If your TTFB is consistently over 600ms, talk to your hosting provider. Sometimes it’s a configuration fix. Sometimes your site has outgrown its hosting plan. Upgrading from shared hosting to a managed WordPress host or VPS can cut server response times dramatically.
Third-Party Scripts (Often Overlooked)
Every third-party script on your site (chat widgets, analytics trackers, social media embeds, ad scripts, cookie consent tools) takes time to load and competes for the browser’s attention. Each one makes HTTP requests to external servers you don’t control. Some block the main thread, directly affecting interactivity and INP scores.
An audit often reveals things nobody remembers adding. An A/B testing tool from a campaign that ended two years ago. A heatmap tracker nobody checks. List every third-party script, question whether each one is necessary, and defer or remove the ones that aren’t earning their keep.
Font Optimisation (Low-Medium Impact)
Custom web fonts add personality but come at a performance cost. Each font file is typically 20-100KB, and most sites load multiple weights. That adds up quickly.
Limit font weights. Do you really need light, regular, medium, semibold, bold and extrabold? Most sites can get by with two or three weights.
Use font-display: swap. This tells the browser to show text immediately using a system font, then swap in the custom font when it’s ready. It prevents invisible text while fonts load.
Preload critical fonts. The `preload` hint tells the browser to start downloading font files early rather than waiting until it encounters them in the CSS.
DNS Prefetching and Preloading (Low Impact, Quick Win)
Performance hints that tell the browser to start fetching resources before it needs them. DNS prefetching resolves domain names for third-party resources in advance. Preloading downloads critical resources (main font, hero image) early. Small individual impact, but they add up and cost almost nothing to implement.
Mobile Speed Deserves Its Own Attention
Mobile isn’t just a smaller screen. It’s a fundamentally different performance environment. Lower processing power, less memory, variable connection quality, and the fact that Google uses mobile-first indexing means your mobile performance is what matters most for search.
Most sites perform worse on mobile than desktop, sometimes dramatically so. A page that scores 90 on desktop Lighthouse might score 55 on mobile. Weaker processing power, variable connections, and touch-based interactions all widen the gap.
Check your mobile and desktop scores separately in PageSpeed Insights. If there’s a big gap, prioritise mobile fixes. That’s where the SEO impact lives.
Platform-Specific Considerations
WordPress Speed
WordPress powers over 43% of the web, and the performance variation across WordPress sites is enormous. A well-configured site can be fast. One with 30 plugins and an unoptimised theme will be painfully slow.
Key areas to address:
Caching plugin. WP Rocket is the premium standard. W3 Total Cache is a solid free alternative. Either will handle page caching, browser caching, minification and basic CDN integration.
Image optimisation plugin. ShortPixel or Imagify will compress and convert images automatically.
Plugin audit. Deactivate anything you’re not actively using. Each plugin adds code, database queries, and often external HTTP requests.
Theme quality. Lightweight themes (like GeneratePress, Astra, or Kadence) load significantly faster than feature-heavy multipurpose themes. If your theme came with a page builder, five slider plugins and a dozen demo imports, it’s probably part of the problem.
Shopify Speed
Shopify handles hosting and infrastructure, which eliminates server-level problems. But Shopify sites still suffer from unoptimised product images, too many apps (each adding code, just like WordPress plugins), heavy themes, and third-party scripts. The approach is the same: audit what’s installed, remove what’s not needed, optimise your images. Shopify’s built-in speed report (Online Store > Speed) gives you a starting benchmark.
How to Prioritise Speed Fixes (The Non-Developer Framework)
Step 1: Run the Tests
Test your five most important pages (homepage, top landing pages, key product or service pages) through PageSpeed Insights. Note the mobile scores and the specific opportunities flagged. Start with the pages that drive the most traffic and revenue.
Step 2: Identify the Pattern
Look at what’s coming up consistently. If “serve images in next-gen formats” appears on every page, that’s a site-wide image problem. If “reduce unused JavaScript” keeps flagging, you’ve got a script bloat issue. The recurring recommendations point to systemic problems that will improve your entire site when fixed.
Step 3: Prioritise by Effort vs Return
| Fix | Typical impact | Who does it | How long |
|---|---|---|---|
| Image compression and WebP conversion | High | Anyone with a plugin or tool | Hours |
| Install/configure a caching plugin | High | Marketing team or agency | A day |
| Set up Cloudflare CDN | Medium-high | Developer or agency | A day |
| Remove unused third-party scripts | Medium | Marketing team | Hours |
| Minification (CSS/JS) | Medium | Caching plugin or developer | Hours |
| Fix render-blocking resources | Medium | Developer | Days |
| Font optimisation | Low-medium | Developer | Hours |
| Server upgrade or migration | Variable | Hosting provider | Days to weeks |
Step 4: Brief Your Dev Team Clearly
The brief to your developer should be specific. Not “make the site faster” but “PageSpeed Insights flags render-blocking CSS on all mobile pages. Can we implement critical CSS for above-the-fold content and defer the rest?” Clear problem, specific solution, measurable outcome.
If you don’t have an in-house developer, this is exactly the kind of work a technical SEO agency handles. The value isn’t just doing the work but knowing which fixes to prioritise for the biggest commercial impact.
Measuring Progress
Speed optimisation isn’t a one-off project. Every time someone adds a new plugin, uploads an uncompressed image, or installs a new tracking script, performance can regress.
Set a baseline by recording your current PageSpeed Insights scores (mobile and desktop) and Core Web Vitals status in Google Search Console. Then check monthly. You’re looking for confirmation that fixes have taken effect (field data takes 28 days to update) and early warning of regressions.
It’s also worth verifying HTTP/2 support with your host. It handles multiple simultaneous file requests more efficiently than its predecessor, meaning your CSS, JavaScript, fonts and images load in parallel rather than queuing. Most modern hosts support it by default, but older configurations might still be on HTTP/1.1.
Build speed checks into your change management process. Before adding a new tool or script, check the impact on page speed. After a redesign or major update, retest. The sites that stay fast treat speed like any other standard to maintain, not something to fix once and forget.
Making Speed Part of Your SEO Strategy
Site speed isn’t the most glamorous part of SEO. It doesn’t have the visible impact of a new content piece ranking on page one or a link-building campaign earning coverage. But it’s foundational work that makes everything else perform better. Faster pages mean more of your traffic converts, more of your content gets crawled, and your site meets the technical standards Google expects.
If your site is slow and you’re not sure where to start, a technical audit will give you a prioritised roadmap. At Gorilla Marketing, speed diagnostics are part of every technical SEO audit we run. Senior strategists, not juniors, translate the data into specific, prioritised recommendations your team can act on. If you want a clear picture of what’s holding your site back, get in touch.
