Website Speed Optimization 2026: 8 Techniques That Work

A faster website keeps more visitors, converts better, and ranks better. The direct answer: the biggest speed wins for most sites are image optimization, cutting JavaScript bloat, and fixing slow server response — in that order. This guide gives you a systematic, technique-by-technique program for 2026, with the measurement workflow first so you fix what actually matters instead of guessing.

Measure first: know your baseline

Speed work without measurement is decoration. Use three tools, each for a different job:

Google PageSpeed Insights — the starting point. It combines Lighthouse lab diagnostics with real-user field data (CrUX) and gives prioritized recommendations. Always read the field section first: that is how your actual visitors experience the site.
WebPageTest — the diagnostic deep end. Its waterfall chart shows every single resource loading in sequence, so you can see exactly which file blocks rendering, which third-party script stalls the page, and where the bytes go. Run tests from a location and connection speed matching your audience.
GTmetrix — useful for historical tracking: test the same page over weeks and watch the trend line as you apply fixes.

Record your baseline before changing anything: mobile Performance score, LCP, INP, CLS, total page weight, and number of requests. Every technique below should move at least one of those numbers. If it does not, revert it — complexity without measured benefit is just technical debt.

Technique 1: Image optimization — the biggest single win

Images are typically the largest single category of bytes on a page. Most sites serve images that are far bigger — in dimensions and file size — than they need to be. Fix this layer completely before touching anything else.

Serve modern formats

Convert images to WebP, and consider AVIF for photographic content. Both are dramatically smaller than JPEG or PNG at equivalent visual quality. Most image optimization plugins and CDNs can do this conversion automatically, including serving the modern format only to browsers that support it.

Resize to actual display dimensions

A 4000-pixel-wide photo displayed at 400 pixels wastes roughly 99% of its pixels. Resize images to the largest size they will actually be displayed at — with responsive variants for different screens:

<img src="photo-800.webp"
     srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
     sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
     width="1600" height="900"
     loading="lazy"
     alt="Descriptive alt text">

Lazy-load below the fold, never above it

loading="lazy" on below-fold images is free performance — the browser skips them until the visitor scrolls near. But never lazy-load your hero or LCP image; that directly delays your largest contentful paint. Above-fold images should use fetchpriority="high" instead.

Always include dimensions

width and height attributes (or CSS aspect-ratio) let the browser reserve space before the image loads, preventing layout shift. This is an image technique that pays off in your CLS score too.

Technique 2: Put your JavaScript on a diet

JavaScript is the number one cause of slow interactive pages. It blocks the main thread, delays interactivity, and third-party scripts pile on silently with every marketing tool someone adds.

Audit with the Coverage tool

Open Chrome DevTools → Coverage, reload the page, and look at how much of your JavaScript actually executes. It is common to find that half or more of loaded JS never runs on a given page — dead code from themes, plugins, and libraries included "just in case." Remove or conditionally load what does not execute.

Defer everything non-critical

Scripts that are not needed for the initial render should not block it:

<!-- Blocks rendering: avoid for non-critical scripts -->
<script src="analytics.js"></script>

<!-- Parses after HTML, executes in order: good default -->
<script defer src="app.js"></script>

<!-- Executes ASAP, order not guaranteed: for independent scripts -->
<script async src="tracker.js"></script>

Split code and load on demand

Code splitting means visitors download only the JavaScript needed for the current page — not the entire application's bundle. Route-level splitting for SPAs, and loading heavy components (rich text editors, maps, video players) only when the user actually needs them, are the two patterns with the biggest payoff.

Question every library

jQuery on a modern site is a ~30KB tax for conveniences that vanilla JavaScript now provides natively (querySelector, fetch, classList). Audit each library the same way: what does it do, what does it cost, is there a native alternative?

Budget your third parties

Tag managers, chat widgets, heatmaps, social embeds, and ad scripts each add DNS lookups, connections, and main-thread work. Inventory them quarterly. For each: can it load after interaction instead of on page load? Can an embed start as a lightweight facade that loads fully only on click? Set a hard budget — for example, a maximum number of third-party requests on key templates — and require removing one thing for every new addition.

Technique 3: Trim and streamline CSS

Inline critical CSS — the styles needed to render above-the-fold content go directly in the head, so the browser can paint without waiting for a stylesheet download.
Defer the rest — load the full stylesheet asynchronously for below-fold styling.
Remove unused CSS — themes and frameworks ship thousands of rules you never use. Purge tools strip them at build time; many WordPress optimization plugins do it automatically.
Minify — stripping whitespace and comments from CSS is a small but free win.

Technique 4: Fix your fonts

Web fonts are render-blocking by default and a frequent hidden cause of slow first paint:

Use font-display: swap so text renders immediately in a system fallback and swaps when the web font arrives — no invisible-text delay.
Subset your fonts to only the character sets and weights you actually use. A full font family with four weights can exceed 500KB; a subsetted single weight is a fraction of that.
Self-host instead of loading from a font CDN when possible — it removes a third-party connection and gives you full control over caching headers.
Preload only the hero font file — preloading every weight is counterproductive.
Consider system font stacks for body text. They load instantly, cost zero bytes, and on modern operating systems they look good.

Technique 5: Fix slow server response (TTFB)

Time to First Byte measures how long the server takes to start responding. Nothing on the page can begin until the HTML arrives, so slow TTFB poisons every other metric. Target under 800ms at worst; under 200ms is excellent.

Enable page caching — store fully rendered HTML so the server does not rebuild the page and query the database on every single visit. This is the biggest TTFB lever on WordPress and similar CMS platforms.
Add object caching (Redis or Memcached) for database-heavy sites — repeated queries get served from memory.
Upgrade hosting when it is the bottleneck. Overcrowded shared hosting with slow disks is the most common root cause of bad TTFB we see. A decent VPS or managed host pays for itself in conversion rate.
Optimize the database — clean post revisions, transients, and orphaned tables; add indexes where slow queries show up.
Keep PHP and your CMS updated — each major PHP version has brought meaningful performance improvements.

Technique 6: Cache aggressively at every layer

Caching means repeat visitors — and often first visitors, via edge caches — barely touch your origin server:

Browser caching: set long cache lifetimes (a year is standard) for versioned static assets — CSS, JS, images, fonts. Use fingerprinted filenames so updates bust the cache cleanly. On Apache servers you can generate correct cache-control and compression headers with the .htaccess generator.
Page caching: serve full HTML from cache to anonymous visitors (covered above).
CDN caching: a content delivery network stores your assets — and optionally full pages — on edge servers worldwide, so a visitor in London is not waiting on a server in Texas. For image-heavy sites, an image CDN that auto-converts formats and resizes on the fly can replace most of Technique 1's manual work.

Technique 7: Optimize the network path

Use HTTP/2 or HTTP/3 — multiplexing, header compression, and (in HTTP/3) QUIC-based transport make multiple simultaneous requests dramatically cheaper than old HTTP/1.1. Any modern host or CDN provides this; verify it is actually enabled.
Reduce redirects — every redirect is a full extra round trip before rendering starts. Audit redirect chains, especially http→https→www chains that double up.
Use resource hints deliberately: preconnect for critical third-party origins (your CDN, font host), dns-prefetch as a cheaper fallback, and preload only for the one or two resources the first paint truly needs. Hint spam is worse than no hints.
Enable Brotli or Gzip compression — text assets (HTML, CSS, JS, SVG) typically shrink 70–80% with Brotli. This is a server toggle, not a code change.

Technique 8: WordPress quick wins

WordPress powers a huge share of slow sites, and the fixes are well-trodden:

Deactivate plugins one by one and re-test — keep only what earns its place.
Switch to a lightweight theme if you are on a heavy page builder; the theme affects every page on the site.
Install one good caching/optimization plugin (page cache + minification + delay-JS), not three overlapping ones.
Convert uploads to WebP automatically and regenerate thumbnails at sensible sizes.
Keep the homepage lean — sliders and video backgrounds are the classic homepage killers.
Clean the database quarterly: revisions, spam comments, expired transients.

Set a performance budget

Optimization rots without guardrails. A performance budget is a set of hard limits your site must stay within — for example: total page weight under 1.5MB on key templates, fewer than 50 requests, Lighthouse mobile Performance above 90, LCP under 2.5s in the field. Enforce it in CI with Lighthouse budgets so a marketing pixel or a new plugin cannot silently blow the budget next quarter. Speed is a feature you have to defend, not a project you finish.

What the research actually says about speed and conversions

You will see the claim "a one-second delay cuts conversions by 7%" repeated everywhere. Treat it as directional folklore, not a law of physics. The underlying research it descends from — Amazon's early-2000s finding that each 100ms of extra latency cost about 1% of sales, and Google's experiments showing measurable drops in searches from sub-second delays — is real, but it is old, context-specific, and widely over-quoted. The honest statement: across industries, faster pages consistently convert better and bounce less, and the effect is largest on mobile. Measure it on your own site with an A/B test rather than quoting someone else's number.

FAQ

How fast should my website be?

Aim for the Core Web Vitals "good" thresholds in real-user field data: LCP under 2.5 seconds, INP under 200ms, CLS under 0.1. In lab terms that usually means a mobile PageSpeed score in the 90s. Beyond that, returns diminish — a 98 and a 100 are indistinguishable to visitors.

Does page speed really affect Google rankings?

Yes, as one signal among many. Google uses real-user Core Web Vitals data as a page experience signal, consistently described as a tiebreaker between pages of similar relevance. But speed's bigger ranking-adjacent effect is behavioral: faster pages bounce less and convert more, and engaged visitors are the foundation rankings are built on.

What is a good Time to First Byte?

Under 800ms is acceptable, under 200ms is excellent. If your TTFB is consistently over a second, fix hosting and caching before touching anything else — no front-end optimization can compensate for a server that takes two seconds to answer.

Is shared hosting enough for a fast site?

For low-traffic brochure sites, decent shared hosting with page caching can be fine. For anything with real traffic, WooCommerce, or membership features, shared hosting's noisy-neighbor CPU contention usually becomes the TTFB bottleneck — a VPS or managed host is the fix.

Should I still use AMP?

Almost certainly not. AMP lost its ranking privileges (Top Stories carousel eligibility, etc.) years ago, and a well-optimized responsive page now matches or beats AMP performance without the constraints. Invest in the techniques in this guide instead.

Which technique should I do first?

In order: (1) measure your baseline, (2) optimize images, (3) cut JavaScript bloat and defer third parties, (4) fix server response time, (5) set up caching and a CDN, (6) polish fonts, CSS, and resource hints. Most sites get 80% of the available improvement from the first four.

Your 30-day action plan

Week 1: Baseline everything (PSI, WebPageTest waterfall). Fix images: formats, sizing, lazy-loading, dimensions.
Week 2: JavaScript diet — Coverage audit, defer non-critical scripts, tame third parties, question libraries.
Week 3: Server side — caching layers, hosting check, database cleanup, compression and cache headers (the .htaccess generator helps here).
Week 4: Fonts, CSS delivery, resource hints, performance budget in CI. Re-measure and compare against week 1.

Keep your SEO fundamentals tight while you work — clean meta tags and an up-to-date XML sitemap ensure crawlers efficiently find the fast pages you just built. For the authoritative methodology behind these techniques, web.dev's performance guides and WebPageTest's documentation are the references worth bookmarking.

Website Speed Optimization 2026: Techniques That Actually Work