If you want to know how to speed up your website, start by thinking bigger than plugins, minification, or a higher Lighthouse score. Website speed is an infrastructure problem, an application problem, and an SEO problem — all at the same time.
Google has treated speed as a ranking signal for years. The mobile Speed Update began in July 2018, and page experience signals entered ranking systems in mid-2021. Today, performance work centres on three Core Web Vitals that Google actually measures and uses in ranking.
Slow pages do not just frustrate visitors. They also have worse server response times, slower render starts, weaker LCP, more script contention, and often worse crawl efficiency. web.dev recommends a TTFB of 0.8 seconds or less for most sites. This guide breaks the work into the 12 changes that most often move the needle.
Still optimizing for FID? INP replaced First Input Delay in March 2024. Older guides that focus on FID are out of date — INP measures the full interaction lifecycle, not just the first input.
Before You Optimize: Know What Fast Actually Means
A fast site is not just one that "loads eventually." It sends HTML quickly, prioritizes above-the-fold content, avoids blocking the critical rendering path, minimizes JavaScript execution, and serves assets efficiently from cache. Before you touch a single setting, run a baseline and write down your numbers.
Hosting Type Comparison
Before diving into tips, it helps to understand how your hosting tier affects your performance ceiling. No amount of frontend optimization will save you from a fundamentally underpowered server. If you are a Canadian business, hosting locally also helps with speed and data sovereignty.
| Type | Cost | Performance | Best For |
|---|---|---|---|
| Shared Hosting | Low | Low – Med | Small brochure sites, early-stage projects |
| VPS Hosting | Medium | Med – High | Growing WordPress sites, PHP apps, stores |
| Managed Hosting | Med – High | High | Site owners who want performance without server admin |
| Cloud Hosting | Variable | High | High-traffic apps, APIs, custom stacks |
Upgrade Your Hosting and Infrastructure
Cheap hosting is often the hidden reason a site feels slow. If your server is overloaded, underpowered, far from your users, or stuck on slow storage, no amount of frontend cleanup will fully fix it. TTFB rises, dynamic pages queue longer, and LCP suffers because the browser cannot even begin rendering until the HTML arrives.
Common mistake: Upgrading bandwidth instead of CPU, RAM, or storage quality. Also: assuming Cloudflare alone can fix a slow origin. A CDN cannot compensate for a fundamentally slow server — it just moves your slow responses closer to the user.
Use a CDN Properly
A CDN is not a magic switch. A good CDN reduces latency, shortens delivery distance, and serves static assets from edge locations. But if your origin is slow, uncached HTML and API calls will still be slow. Cloudflare's caching documentation makes the distinction clear: by default, Cloudflare mainly caches eligible static assets. For WordPress, Automatic Platform Optimization can also cache dynamic HTML at the edge.
WordPress tip: Enable Cloudflare APO if you need HTML edge caching. Always test login, cart, and personalized pages separately after enabling — these must be excluded from the cache.
Optimize Images Aggressively
Images are still one of the biggest payload problems on the web. web.dev recommends WebP and AVIF as strong choices for photos and screenshots. AVIF can deliver major savings versus JPEG, though exact gains depend on content type and settings.
Do not lazy-load your hero image. If the above-the-fold image is lazy-loaded, you are directly damaging LCP by design. Check your theme — many WordPress themes apply lazy loading to all images indiscriminately.
Implement the Right Caching Strategy
Caching is not one thing. There is page caching, object caching, browser caching, and opcode caching. Each solves a different bottleneck, and stacking them correctly is what separates a genuinely fast site from one that just has a cache plugin installed.
Minify and Reduce CSS, JavaScript, and HTML
Minification helps, but it is not the same as optimization. Google's guidance on render-blocking resources consistently flags unused CSS, unused JavaScript, and oversized payloads as bigger problems than un-minified code.
Where payload reduction actually matters: unused CSS commonly accounts for 60–90% of loaded stylesheet weight. Third-party JavaScript often makes up 40–60% of total JS weight. Minification typically saves 10–20% on top of that. Prioritize in that order.
Remove dead CSS and unused JS. Split code by page or route where practical. Audit third-party payload weight — not just first-party code. Believing minification alone fixes bloat is one of the most common misconceptions in web performance.
Clean and Optimize Your Database
Database drag is common on WordPress and older PHP apps. Revisions, transients, spam comments, stale options, and missing indexes add overhead on every page request. WordPress's optimization docs specifically call out autoloaded options as a performance risk when they grow large.
Audit autoloaded options first. Run SELECT option_name, length(option_value) FROM wp_options WHERE autoload = 'yes' ORDER BY 2 DESC LIMIT 20; — plugins frequently leave large serialized data here that loads on every single page request.
Remove old revisions and expired transients. Clean spam comments and orphaned metadata. Use slow query logs before changing indexes — adding indexes without query analysis often causes more problems than it solves.
Upgrade PHP to a Modern Version
If you are still on PHP 7.4, you are overdue. PHP's supported-versions policy provides two years of full support plus one year of security support per release. PHP 8.2 and 8.4 both bring performance improvements alongside security updates.
Always test in staging first. Move to a supported PHP 8.x branch and test all plugins and page builders before the production cutover. Older commercial themes and abandoned plugins are the most common source of PHP 8 compatibility errors.
Eliminate Render-Blocking Resources with Critical CSS
CSS is render-blocking by default. Large stylesheets can delay meaningful rendering even before a single pixel of your site appears. web.dev's LCP guidance explicitly recommends reducing stylesheet size, deferring non-critical CSS, and fixing render-blocking resources to improve paint metrics.
defer so scripts download without blocking parsing. Script executes after HTML is parsed.rel="preload" tag surfaces it earlier.Add Lazy Loading for Below-the-Fold Assets
Lazy loading is a strong win when applied correctly — on below-the-fold assets. web.dev's lazy loading guide recommends the native loading attribute for images and iframes, but also warns that overusing it above the fold directly hurts LCP.
loading="lazy"Use Brotli Compression
Compression for text assets is still easy, high-return work. Cloudflare's compression documentation states that Brotli is its preferred algorithm, with Gzip fallback based on browser support. Brotli typically compresses HTML, CSS, and JS 15–20% better than Gzip.
Modern font formats like WOFF2 and image formats like WebP and AVIF already have compression built in. As MDN notes, do not expect the same gains from server-side compression on already-compressed assets — focus it on HTML, CSS, JS, and SVG.
Optimize Fonts for Speed
Fonts can quietly damage both LCP and CLS. web.dev's font best practices guide recommends font-display: swap, using WOFF2 format, reducing font families and weights, and preloading critical fonts when appropriate.
font-display: swap — shows text in a fallback font immediately rather than staying invisibleAudit Plugins and Third-Party Scripts for Bloat
A lot of "slow websites" are really "too many scripts" websites. Analytics tags, chat widgets, A/B testing tools, heatmaps, social embeds, sliders, and page builder payloads can wreck INP and inflate main-thread work. web.dev recommends loading third-party JavaScript with async or defer unless it is truly critical.
Don't just measure your homepage. Marketing tags, chat scripts, and tracking pixels are often loaded conditionally. Check your product pages, blog posts, and checkout flow separately — the heaviest third-party bloat is often hiding there.
Open a waterfall and identify the heaviest third-party requests by size and main-thread time. Remove tools with weak ROI. For WordPress: audit plugins by frontend impact, not just count. Be especially cautious with visual builders, pop-up suites, and multi-purpose all-in-one plugins — these tend to enqueue scripts and styles globally regardless of whether the current page uses them.
Full-page cache
Redis object cache
Image optimization
Plugin and script audit
Critical CSS
OPcache enabled
DB query and index work
Route-level asset splitting
Proper cache headers
Third-party script reduction
Frequently Asked Questions
How can I speed up my website quickly?
Start with the highest-impact items: better hosting, full-page caching, image optimization, Brotli compression, and removing heavy third-party scripts. Run a PageSpeed Insights audit first — it will tell you which of these is your biggest bottleneck right now.
What slows a website down the most?
The biggest causes are usually slow hosting, poor server response time, oversized images, too much JavaScript, render-blocking CSS, weak caching, and bloated plugins or third-party tags.
Does website speed affect SEO?
Yes. Google has used speed as a ranking consideration since the 2018 mobile Speed Update, and later incorporated broader page experience signals into ranking. Faster pages also improve crawl efficiency and reduce bounce rates — both of which affect organic performance indirectly.
Is a CDN enough to make a site fast?
No. A CDN helps reduce latency and offload cacheable static content, but a slow origin, bad database queries, uncached HTML, and heavy client-side code will still keep the site slow. Think of a CDN as the last mile — it cannot fix what happens before your server sends a response.
What is a good TTFB or LCP score?
A practical target is TTFB at or below 0.8 seconds. For Core Web Vitals, a good LCP is 2.5 seconds or less, a good INP is 200 milliseconds or less, and a good CLS is 0.1 or less.
Does Canadian hosting actually make my site faster for Canadian visitors?
Yes, meaningfully. Hosting in a Toronto or Montreal data centre instead of Dallas or Virginia can reduce round-trip time by 30 to 60 milliseconds or more for Canadian visitors. That translates directly into lower TTFB and better LCP scores. See our full breakdown of why Canadian hosting matters for Canadian businesses.
