How To Optimize Your Website Speed: Top 12 Tips & Guide

Table of contents

Why optimize your website for speed?

Page load time is the duration from the moment a user requests a URL to the moment the page is usable. Google’s Core Web Vitals framework (LCP, INP, CLS) made speed a direct ranking factor — and the thresholds are tight.

Three business levers depend on it:

Conversion

The conversion impact of speed is well-documented. HubSpot, Walmart, and Amazon have all published data showing that each additional second of load time drives measurable drops in revenue. The exact figures shift over time, but the direction never does: faster = more conversions.

As of 2026, AI-powered search surfaces (Google AI Overviews, Perplexity, ChatGPT search) add a new wrinkle: if your page is slow to crawl or fails Core Web Vitals, it is less likely to be sourced in AI answers. Speed is no longer just a UX concern — it’s an AI-visibility concern.

Relevant: Ways to improve your ecommerce conversion rate

Visibility (SEO + AI search)

Google has used page experience signals — including Core Web Vitals — as ranking inputs since 2021, and those signals carry into 2026. The three metrics to know:

• LCP (Largest Contentful Paint): How fast the biggest visible element renders. Target: under 2.5 s.
• INP (Interaction to Next Paint): How quickly the page responds to clicks/taps. Replaced FID in 2024. Target: under 200 ms.
• CLS (Cumulative Layout Shift): How much the layout jumps during load. Target: under 0.1.

Google’s mobile-first indexing has been the default for years now — your mobile page speed is what gets indexed, full stop.

Relevant: Top search engines reviewed

Usability

Heavy pages don’t just rank lower — they frustrate real people. A slow-loading hero image, a layout that shifts right before a user taps a button, a page that freezes on a mid-range Android phone: these experiences all damage trust. Users don’t distinguish between “your image was large” and “your site is broken.”

How to measure your website speed in 2026

Before optimizing, measure. The tools I use:

• PageSpeed Insights (pagespeed.web.dev) — runs Lighthouse and shows real-world Core Web Vitals from Google’s CrUX dataset. Free, authoritative.
• WebPageTest (webpagetest.org) — filmstrip view, waterfall charts, multi-location testing. Excellent for diagnosing TTFB and render-blocking resources.
• Chrome DevTools — built into every Chrome browser. Performance tab and Lighthouse tab give you a local baseline.

These tools have largely replaced the older generation of speed checkers. They surface the exact Core Web Vitals scores Google uses, so you’re optimizing for the right thing.

Tips on how to speed up your website

Tip 1. Use a Content Delivery Network (CDN)

A CDN caches your static assets (images, JS, CSS, fonts) on edge nodes around the world and serves them from whichever node is closest to each visitor. Instead of every request traveling to your origin server in one data center, users in Tokyo hit a Tokyo node, users in Frankfurt hit a Frankfurt node.

CDNs also dramatically improve TTFB (Time to First Byte) — the delay before the server starts responding. TTFB is an upstream input into LCP, so cutting it moves multiple Core Web Vitals at once.

Options range from free tiers (Cloudflare) to performance-optimized paid services (Fastly, Bunny.net). For most sites, Cloudflare’s free tier is a meaningful starting point.

Relevant: Pillar content strategy

Tip 2. Move to a better host (or go static/edge)

Hosting tier has a ceiling effect: no amount of optimization compensates for a slow origin. The stack in 2026:

• Shared hosting — cheapest, slowest. Fine for low-traffic experiments; a liability for anything revenue-generating.
• VPS / managed cloud — you control resources; faster than shared. Good for dynamic apps.
• Static site / edge deployment — if your content doesn’t need to be dynamically rendered per request, deploy a static build to a global CDN (Netlify, Vercel, Cloudflare Pages). Zero origin TTFB because there is no origin — every edge node serves the full page. This is now the default for high-performance marketing and blog sites.
• Serverless / edge functions — for dynamic routes that still need speed, serverless functions executed at the edge (Cloudflare Workers, Vercel Edge Functions) beat traditional server round-trips.

Check my detailed breakdown: Bluehost review and GoDaddy review.

Tip 3. Use modern image formats (WebP and AVIF)

In 2020 this tip was about using ImageOptim to compress JPEGs. In 2026, the first question is format.

WebP offers roughly 25–35% smaller files than JPEG at equivalent quality. AVIF goes further — often 40–50% smaller than JPEG — and is now supported by all modern browsers. For photographic content, AVIF is the first choice; WebP is the reliable fallback.

Practical approach:

1. Serve <picture> elements with an <source type="image/avif"> and a <source type="image/webp"> before the <img> JPEG fallback.
2. Use build-time tools (Sharp, Squoosh CLI, Astro’s built-in image pipeline, Next.js <Image>) to auto-generate formats at build time — don’t do this manually per image.
3. Always specify explicit width and height attributes to prevent layout shift (CLS).

ImageOptim is still useful for Mac-based batch compression if you’re working with legacy JPEG/PNG files, but the bigger win in 2026 is format conversion.

Tip 4. Implement lazy loading for images and iframes

Lazy loading defers the download of offscreen images until the user scrolls near them. The browser attribute is now native HTML — no JavaScript library required:

<img src="photo.jpg" loading="lazy" alt="…" width="800" height="600" />

Apply loading="lazy" to every image below the fold. Do not apply it to hero images or anything visible in the initial viewport — those need to load immediately for good LCP.

For iframes (YouTube embeds, maps, etc.), the same loading="lazy" attribute works in all modern browsers. A YouTube facade pattern (show a thumbnail, load the iframe only on click) goes further and can save hundreds of kilobytes on initial load.

Tip 5. Minify JavaScript and CSS

Every byte of JS and CSS that loads on the critical path delays rendering. Minification strips whitespace, comments, and redundant characters from source files. For JS, tree-shaking removes unused code entirely.

In 2026, if you’re using a modern build tool (Vite, webpack, Rollup, esbuild, Parcel), minification and tree-shaking are on by default in production builds. There’s no manual step — just confirm your build config is set to mode: 'production' or equivalent.

For sites without a build pipeline (plain HTML/CSS/JS), tools like css-minifier.com and javascript-minifier.com still work. But migrating to a build tool pays compound dividends.

An additional 2026 consideration: code splitting. Don’t bundle your entire app’s JS into one file. Ship only the code needed for the current page; lazy-load the rest. This directly improves INP by reducing JS parse/execution time on page load.

Tip 6. Enable Gzip or Brotli compression

When a browser requests a file, the server can compress it before sending. The browser decompresses it on receipt. This is transparent to users and reduces transfer size by 60–80% for text-based assets (HTML, CSS, JS).

• Gzip — universally supported; enable it in your server config or CDN settings.
• Brotli — newer, compresses roughly 15–20% better than Gzip for most assets. Supported in all modern browsers and all major CDNs. Prefer Brotli where available.

Most managed hosts and CDNs (Cloudflare, Netlify, Vercel) enable compression automatically. If you’re on a VPS, verify via checkgzipcompression.com and add the relevant server config lines if missing.

Tip 7. Use browser and CDN caching

Caching lets returning visitors (and CDN edge nodes) reuse previously downloaded assets instead of re-fetching them from your origin.

Two levels:

1. Browser cache — set Cache-Control headers with appropriate max-age values. Static assets (images, fonts, hashed JS/CSS bundles) can have very long TTLs (a year or more). HTML documents should have shorter TTLs or no-cache so updates propagate.
2. CDN cache — your CDN caches responses at the edge. Configure cache rules to cache static assets aggressively while allowing HTML to refresh on each deploy.

Content-hashed file names (e.g., main.a3f9b2.js) are the practical solution: because the filename changes with every build, you can set a long browser cache TTL without worrying about users seeing stale JS.

Tip 8. Optimize your database and server response time (TTFB)

If you’re running a dynamic site backed by a database (WordPress, custom app, etc.), every page request involves a database query. Slow queries inflate TTFB, which hurts LCP.

Steps to investigate:

• Enable query caching at the application layer (object caches like Redis or Memcached).
• Review slow query logs to find expensive queries and add missing indexes.
• Use a page-level cache (full-page caching) so repeat requests serve a pre-rendered HTML response without hitting the database at all.

For WordPress specifically, plugins like WP-Optimize and WP Rocket handle many of these layers. But the database optimization principle applies to any dynamic stack.

Tip 9. Reduce web font load

Web fonts are a common CLS and LCP culprit. Every custom font file the browser hasn’t seen before is a blocking request.

Best practices for 2026:

1. Use WOFF2 — the most compressed format; supported everywhere.
2. Self-host fonts where possible — removes a third-party DNS lookup and lets you set cache headers. Google Fonts can be downloaded and served from your own CDN.
3. Preload your critical font files in <head>: <link rel="preload" as="font" type="font/woff2" href="/fonts/your-font.woff2" crossorigin>.
4. Use font-display: swap so text renders immediately in a fallback font while the custom font loads. Prevents invisible text (FOIT).
5. Subset your fonts — if you only use Latin characters, strip out Cyrillic, CJK, and other character sets. Tools like pyftsubset or the Google Fonts subsetting API handle this.
6. Limit font weights — load only the weights you actually use. Each weight is a separate file request.

Tip 10. Fix and prevent 404 errors

A broken link that generates a 404 is a wasted request — and if crawlers hit them repeatedly, they waste crawl budget. Tools to audit:

• Google Search Console — shows 404s Google has found on your site. Free and authoritative.
• Screaming Frog — crawls your site like a search engine, identifies broken internal and external links.
• Ahrefs / Semrush — surface 404s at scale, especially useful for finding broken inbound links.

When you find a 404 that was receiving traffic (check Analytics or Search Console), set up a 301 redirect to the most relevant live page. A blanket redirect to the homepage is a last resort, not a solution.

Tip 11. Minimize redirect chains

Each redirect in a chain adds a full HTTP round-trip before the user’s browser loads any content. A chain of three redirects (A → B → C → D) can add several hundred milliseconds to LCP.

Common culprits:

• HTTP → HTTPS → www → non-www (can be collapsed to a single redirect)
• Old campaign URLs that chain through multiple tracking redirects
• Mobile redirect chains (m.example.com redirecting to the full URL then to the page)

Audit with Screaming Frog or a browser extension that shows redirect chains. The fix is to update the source link to point directly to the final destination, or consolidate server-level redirects.

Tip 12. Use prefetching and preloading strategically

The browser has several hints that allow you to load resources speculatively before they’re needed:

• <link rel="preload"> — fetch a critical resource (hero image, main font, above-the-fold CSS) at the highest priority. Use sparingly; over-preloading competes with itself.
• <link rel="prefetch"> — low-priority fetch of a resource likely needed on the next navigation (e.g., the next blog post, the checkout page).
• <link rel="dns-prefetch"> — resolve DNS for a third-party domain before a request is made. Cheap and broadly useful for analytics, fonts, CDN domains.
• <link rel="preconnect"> — establishes a TCP connection (and TLS handshake for HTTPS) to a third-party origin early. Use for your CDN and any critical third-party API.

The Speculation Rules API (supported in Chrome/Edge as of 2024) goes further, allowing full prerendering of the next likely page. Worth exploring for high-traffic sites where the next-page prediction is reliable.

Website Speed — 2026 FAQ

What are Core Web Vitals and do they directly affect Google rankings?

Yes. Google has used Core Web Vitals as a ranking signal since 2021, and they remain part of the page experience signals in 2026. The three metrics are LCP (Largest Contentful Paint, target < 2.5 s), INP (Interaction to Next Paint, target < 200 ms), and CLS (Cumulative Layout Shift, target < 0.1). You can see your real-world scores in Google Search Console under “Core Web Vitals” — these are measured from actual Chrome users, not lab simulations.

What’s the fastest way to improve LCP specifically?

LCP is almost always the hero image or the largest heading text. Prioritize: (1) serve that image in AVIF/WebP, (2) add fetchpriority="high" to the hero <img>, (3) never lazy-load the hero (remove loading="lazy"), (4) preload it with <link rel="preload">, (5) serve it from a CDN edge close to your users. Cutting TTFB via a CDN also helps since LCP can’t start until the first byte arrives.

Is page speed still relevant with AI search (ChatGPT, Perplexity, Google AI Overviews)?

Yes, arguably more so. AI search engines pull from pages they can crawl and render quickly. A page that fails Core Web Vitals or takes a long time to respond is a worse candidate for sourcing in AI-generated answers. The underlying mechanism differs from traditional blue-link ranking, but speed remains a prerequisite for visibility.

Do I need to optimize speed differently for mobile vs. desktop?

Google indexes and ranks based on the mobile version of your page. Test on a real mid-range Android device (or use WebPageTest’s mobile emulation with a throttled connection), not just your fast desktop machine. Common mobile-specific issues: render-blocking scripts that block the mobile-sized viewport, fonts that load differently on mobile, and images that aren’t sized for mobile viewports (resulting in unnecessarily large downloads).

Related reading: Wix vs. Squarespace comparison · BigCommerce review · Ways to improve your ecommerce conversion rate

The shorter version

If you’re reading this because the workflow it describes is eating your week, that’s the kind of loop I build AI agents for. Two build slots open at a time.

Updated for May 2026

A short note from May 2026: the workflow this post describes was checked against the current state of the underlying tools and platforms. Where specific tools, UIs, or features have evolved, the structural advice still holds — the implementation will look slightly different in 2026. If you hit a step that doesn’t match what you see on screen, that’s likely a UI refresh, not a fundamental change in approach. Drop a note via the contact form and I’ll patch it explicitly.