Website speed optimization for Canadian small businesses: what actually works

Why page speed matters for your business

Speed is not a technical vanity metric — it directly affects whether visitors stay long enough to become customers. Google's own research found that 53 percent of mobile visits are abandoned if a page takes longer than three seconds to load. For a local business whose potential customers are on their phones searching while they need something, those seconds are the difference between a customer and a bounce.

Google has incorporated page experience signals — including speed metrics — into its ranking algorithm via the Core Web Vitals framework. A site that is measurably faster than its local competitors has a real SEO advantage, all else equal. This matters especially for small businesses competing in local search, where the margins between ranking in the Local Pack and not ranking at all can be narrow.

How to measure your site's speed

Before optimising anything, measure what you have. The main tools: Google PageSpeed Insights (pagespeed.web.dev) tests your page and gives scores with specific recommendations. GTmetrix provides a timeline of what loads and when, which is useful for diagnosing specific bottlenecks. Google Search Console's Core Web Vitals report shows real-world performance data from actual visitors to your site, not just lab measurements.

Measure both desktop and mobile scores — they will often differ significantly, and mobile is what matters most for local search. A desktop score of 95 and a mobile score of 40 is a problem, not a success. Measure your key pages — home page, services, contact — not just the home page.

Test from a Canadian server location when possible. A visitor in Victoria loading a site whose server is in Sydney, Australia will experience higher latency than one whose server is in Vancouver. GTmetrix lets you choose your test location.

Core Web Vitals explained

Google's Core Web Vitals are three specific metrics that measure user experience aspects of page speed. Understanding what they measure helps you understand what to fix.

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on the page — usually a hero image or headline — to load. Google's threshold: good is under 2.5 seconds, needs improvement up to 4 seconds, poor is over 4 seconds. LCP is most often improved by optimising images and improving server response time.

Cumulative Layout Shift (CLS) measures visual instability — elements jumping around as the page loads. A page where the text moves because an image above it loaded late, or where a cookie banner pushes content down, has a high CLS. Google's threshold: good is under 0.1. CLS is fixed by reserving space for images with explicit width and height attributes, and loading ads and embeds in fixed containers.

Interaction to Next Paint (INP) replaced First Input Delay in 2024 and measures how responsive the page is to all user interactions throughout the page lifecycle — not just the first one. A page that responds slowly to clicks and taps has a high INP. This is most affected by heavy JavaScript execution.

Images: the biggest win for most sites

On most small business websites, images are the largest performance problem and the highest-return optimisation. Uncompressed photos uploaded directly from a phone camera can be 4–8 MB each. A page with six of these loads 30+ MB of images before anything else renders. No amount of caching or CDN fixes a fundamentally oversized image.

For every image: resize it to the actual dimensions it will display at on screen (a photo displayed at 800px wide does not need to be 4000px wide), compress it (tools like Squoosh.app or Shortpixel in WordPress can reduce file size by 70–80% with no visible quality loss), and convert it to a modern format. WebP is now widely supported and significantly smaller than JPEG or PNG for equivalent quality. AVIF is even more efficient but has slightly lower browser support.

Add width and height attributes to all image tags — this allows the browser to reserve space before the image loads, preventing layout shift (CLS). Use loading="lazy" on images below the fold so they only load when a visitor scrolls to them. Use loading="eager" or fetchpriority="high" on the largest image in your above-the-fold hero section so it loads as fast as possible (it is almost certainly your LCP element).

Hosting: your speed ceiling

Your hosting sets the ceiling for how fast your site can be. A well-optimised site on a slow shared hosting server will still be slow, because the server response time — the time it takes for the server to start sending data after a browser requests a page — is slow. No client-side optimisation can compensate for a slow server.

Shared hosting puts many websites on the same server, sharing resources. When another site on the same server has a traffic spike or a runaway process, your site slows down too. VPS (Virtual Private Server) hosting allocates dedicated resources to your site, eliminating neighbour effects. Managed hosting typically runs on infrastructure tuned for performance and includes server-level caching.

A Time to First Byte (TTFB) — the time from a browser request to the first byte of response from the server — under 200ms is good. Over 600ms means your server is the bottleneck. PageSpeed Insights will flag a slow TTFB directly in its recommendations. If your server is slow, no amount of image optimisation will give you a fast site.

Caching

Caching stores the result of work so it does not have to be done again. There are several types relevant to website speed.

Server-side page caching (for WordPress: WP Rocket, W3 Total Cache, or LiteSpeed Cache if on a LiteSpeed server) stores the fully rendered HTML of a page so subsequent requests can be served without running PHP and querying the database. The difference between a cached and uncached WordPress page response can be enormous — from 800ms uncached to under 100ms cached.

Browser caching tells a visitor's browser to store static files — CSS, JavaScript, fonts, images — locally for a specified period. On return visits, these files load from the local cache rather than the server, making repeat visits dramatically faster. This is configured via HTTP headers, which can be set in your .htaccess file or hosting control panel.

Web fonts

Web fonts — custom typefaces loaded from a CDN — add requests and load time. Google Fonts is the most common culprit: a page loading several font families across multiple weights can add several hundred milliseconds to load time, and the fonts block rendering until they load.

Self-hosting fonts (downloading the font files and serving them from your own server) eliminates the external DNS lookup and connection overhead of loading from Google's servers. Use WOFF2 format, which is compressed and widely supported. Load only the weights you actually use — loading Regular, Bold, Italic, and Bold Italic as four separate files when your design only uses Regular and Bold is wasteful.

The CSS font-display property controls what happens while a font loads. font-display: swap tells the browser to show text immediately in a fallback font and swap in the custom font when it loads. This prevents invisible text during load (FOIT — flash of invisible text) and improves LCP.

Third-party scripts

Every third-party script you add to your site — analytics, chat widgets, social media embeds, cookie consent tools, A/B testing tools, pixel tracking — adds load time. Some add substantial load time. A Facebook pixel, a Google Tag Manager container with eight tags, a live chat widget, and a cookie consent script can easily add a second or more to your load time on their own.

Audit what third-party scripts you actually use and what value they deliver. A chat widget that no one actually monitors is adding load time for zero return. An analytics tool that you never log in to check is adding overhead with no benefit. Cut anything that is not earning its place.

For scripts you do need, load them asynchronously or deferred where possible, so they do not block the page from rendering. Google Tag Manager helps consolidate tracking pixels into a single script rather than multiple separate loads.

WordPress-specific considerations

WordPress can be fast or slow depending on how it is configured. The main speed killers: too many plugins (each one adds overhead to every page load, even on pages where its functionality is not used), a heavy page builder like Elementor or Divi that generates bloated HTML and loads large libraries on every page, and an unoptimised database that has accumulated years of revisions, transients, and orphaned data.

Choose plugins deliberately. A plugin that adds one feature is usually faster than a plugin that adds fifteen features with only one being used. A lightweight or code-based WordPress theme is typically faster than a full-featured premium theme — but requires more technical knowledge to customise. Remove deactivated plugins rather than just leaving them disabled.

What not to do

Chasing a perfect 100 PageSpeed score is often not worth the effort. The score is a proxy metric, not the actual goal — a score of 90 on a site that loads in 1.5 seconds on mobile is better for your business than a score of 100 on a site that took three weeks and significant money to optimise. Focus on Core Web Vitals passing thresholds and real-world load times.

Applying complex optimisations before fixing the obvious ones wastes time. If your images are uncompressed and your hosting is slow shared hosting, implementing lazy loading and CSS inlining will have minimal effect. Fix the big things first — images, hosting, caching — then measure again before going further.