12 Page Speed Best Practices to Follow for SEO

Why Page Speed Matters

Speed has two audiences. Users drop off fast sites less often: Google’s own data shows that as mobile load time goes from 1 to 3 seconds, bounce probability jumps 32%; from 1 to 5 seconds, it jumps 90%. Slow pages don’t just frustrate readers — they cost conversions.

Search engines use speed as a ranking input too. Google has officially counted page speed in mobile rankings since 2018 and formalized Core Web Vitals as ranking signals in 2021. After the March 2026 core update, Google tightened the thresholds and sites that fail them now see measurable ranking drops. Speed is also one of the clearest compounding advantages in SEO — every millisecond you shave adds to UX scores, conversion rates, and ranking stability at the same time.

Page Speed, Site Speed, and Core Web Vitals

Page speed is how fast a single page displays its content. Site speed is the average across all your pages. They’re related, but page speed is what Google evaluates on a per-URL basis — and what you tune one page at a time.

Since 2020, Google has measured page speed through Core Web Vitals, three metrics that capture how a real visitor actually experiences the page:

• Largest Contentful Paint (LCP) — how long the biggest visible element takes to render. Google tightened the “good” threshold from 2.5 to 2.0 seconds in the March 2026 core update.
• Interaction to Next Paint (INP) — how responsive the page feels across every interaction. INP replaced First Input Delay in March 2024. Good: under 200 ms. After March 2026, below 150 ms is the ranking-stability threshold.
• Cumulative Layout Shift (CLS) — how much content moves around unexpectedly as the page loads. Good: under 0.1.

Only about 47% of mobile sites pass all three, which makes Core Web Vitals one of the easiest places to overtake a competitor — if you treat speed as a discipline, not a one-off fix.

1. Measure Before You Optimize

Every performance project starts with a baseline. Guessing which bottleneck matters most wastes hours on changes that don’t move the needle.

Start with Google PageSpeed Insights for a quick view of lab scores plus field data from the Chrome User Experience Report (CrUX). Chrome DevTools’ Performance panel is invaluable for profiling specific interactions. WebPageTest and GTmetrix add waterfall charts and multi-location runs. For an overview of what else is available, see our guide to speed-measurement tools.

Record baseline numbers for LCP, INP, CLS, and total page weight before touching anything. You’ll need them to prove the next eleven steps actually worked.

2. Optimize for Core Web Vitals Specifically

A page can score well on “overall performance” in some tools and still fail Core Web Vitals in the field. Target the three metrics directly:

• For LCP: identify which element is your LCP (DevTools shows it), then make that element render faster — usually by preloading the image, prioritizing its download, and keeping the server response under 600 ms.
• For INP: audit long tasks on the main thread. Break up heavy JavaScript, and defer third-party scripts that block input.
• For CLS: reserve space. Set width and height attributes on images and video, use CSS aspect-ratio, and avoid injecting ads or banners above existing content after load.

Field data from CrUX is what Google uses for ranking. Lab data from PageSpeed Insights only predicts it. Always verify improvements in field data over a 28-day window.

3. Serve Modern Image Formats (WebP and AVIF)

Images are typically 50 to 70 percent of page weight. Modern formats cut that dramatically:

• AVIF — roughly 50% smaller than JPEG at equivalent quality
• WebP — roughly 25 to 35% smaller than JPEG, broader browser support
• JPEG — only as a last-resort fallback for legacy browsers

Use the <picture> element or let a CDN serve the best format by negotiation. Tools like Squoosh (free, web-based) and ImageOptim (macOS) handle the conversion, and most CDNs do it automatically. Combined with responsive srcset, this single step often cuts LCP by over a second.

A concrete example: a 1,200-pixel-wide hero photo at 85% quality weighs roughly 300 KB as JPEG, 200 KB as WebP, and 120 KB as AVIF. Across a page with ten images, that’s the difference between a 3 MB and a 1.2 MB payload — with no visible quality loss.

4. Lazy-Load Below-the-Fold Images

There’s no reason to download images the visitor hasn’t scrolled to yet. Add loading="lazy" to every image below the fold:

<img src="chart.webp" loading="lazy" width="800" height="400" alt="...">

This typically shaves 30 to 40 percent off initial page weight on content-heavy pages. But never lazy-load the LCP image or any image above the fold — lazy loading delays those resources, which hurts LCP. Keep them eager.

5. Prioritize Your LCP Element

The browser doesn’t know which resource is “most important” by default. Tell it. For the LCP image, set fetchpriority="high" and use loading="eager":

<img src="hero.avif" fetchpriority="high" loading="eager" width="1200" height="600" alt="...">

Combined with a preload hint in the <head>, this often moves the LCP element up by 200-600 ms. It’s a five-minute change with outsize impact.

6. Enable Brotli (or Gzip) Compression

Compression reduces the bytes sent over the wire for HTML, CSS, and JavaScript. Brotli is the modern standard — it compresses 15 to 20 percent better than Gzip and is supported by every current browser. If your host offers Brotli, enable it. If not, Gzip is still worth having; uncompressed is not.

Don’t apply compression to images, videos, or fonts — they’re already compressed, and re-compressing just burns CPU without shrinking the file.

7. Minify CSS, JavaScript, and HTML

Minification strips whitespace, comments, and anything else the browser doesn’t need to execute the code. It’s tiny on any individual file and substantial in aggregate.

In 2026, build tools do this automatically: esbuild and Vite minify JavaScript as part of the default production build, and CSSNano handles CSS. For HTML, WordPress plugins like WP Rocket, W3 Total Cache, and FastPixel apply minification site-wide. If you maintain raw JavaScript, Terser is the modern replacement for the older UglifyJS.

8. Use a Content Delivery Network (CDN)

A CDN caches your static assets — images, CSS, JavaScript, fonts — on servers distributed worldwide, so a visitor in Tokyo downloads from a Tokyo-region edge instead of your origin in Virginia. Latency drops from hundreds of milliseconds to tens.

Cloudflare (with a generous free tier), BunnyCDN, and Fastly are the popular choices. Most also throw in modern-image-format conversion, Brotli compression, and basic DDoS protection at no extra cost. For any site serving visitors across regions, a CDN is the single biggest speed win available.

9. Audit and Reduce Third-Party Scripts

Every third-party tag — analytics, chat widgets, A/B testing, heatmaps, ads — is bytes you don’t control, parsed on your visitor’s device. A typical marketing site loads 20 to 40 such scripts, and their cumulative INP cost is often the single largest performance problem.

Audit them quarterly. For each one, ask: is it still producing value worth the speed cost? Remove anything that hasn’t been looked at in months. For the essentials, defer them with async or defer, or load them only after the main page is interactive. Removing five to ten unneeded scripts often improves INP more than any advanced optimization.

For analytics and marketing tags specifically, consolidating under a single Google Tag Manager container cuts the number of separate network requests. Going further, tools like Partytown move third-party scripts into a web worker so they run off the main thread entirely, which can rescue INP on script-heavy pages without removing the scripts.

10. Preload and Preconnect Critical Resources

Two resource hints tell the browser to start work early:

• <link rel="preload" as="image" href="hero.avif" fetchpriority="high"> — download this asset immediately
• <link rel="preconnect" href="https://cdn.example.com"> — resolve DNS and open a TCP connection to this host early

Use preload for the LCP image and any render-blocking font. Use preconnect for third-party origins you know will be hit (fonts, analytics, CDN). Both are small hints with real impact on first render.

11. Set Proper Browser Caching Headers

Returning visitors shouldn’t have to redownload assets that haven’t changed. Cache-Control headers tell the browser how long it can keep an asset without checking back with your server.

A reasonable pattern: Cache-Control: public, max-age=31536000, immutable for versioned static assets (CSS, JS, and images with hashes in the filename), and shorter values for HTML so content updates reach visitors quickly. Most hosts, WordPress caching plugins, and CDNs configure this for you — but verify in the Network panel that your assets actually send the header.

12. Optimize Web Fonts

Fonts block text rendering by default, which hurts LCP. Three fixes that stack:

• Self-host fonts instead of pulling from Google Fonts — you avoid the cross-origin hop and control caching.
• Subset fonts to only the characters you actually use (Latin-1 for most English sites) — file sizes drop by half or more.
• Use font-display: swap so text renders in a fallback font immediately and swaps in the custom font when it arrives.

For pages with heavy custom typography, font optimization alone can shave 300 to 700 ms off LCP.

Frequently Asked Questions

Is page speed still a ranking factor in 2026?

Yes. Google’s March 2026 core update reinforced Core Web Vitals as direct ranking signals. Sites with INP above 200 ms saw average ranking drops of nearly one position. LCP, INP, and CLS thresholds are what you need to pass.

What’s a “good” page speed score?

The targets Google considers “good” in 2026: LCP under 2.0 seconds (down from 2.5 s earlier), INP under 200 ms (under 150 ms for ranking stability), and CLS under 0.1. All three are measured at the 75th percentile of real-user data.

What’s the single biggest thing I can do to speed up my site?

For most sites, it’s a tie between enabling a CDN and reducing third-party scripts. Both are usually free or nearly so, and they produce larger gains than image optimization alone. After that, converting images to WebP or AVIF and lazy-loading below-the-fold assets are the next biggest wins.

How do I know if my site passes Core Web Vitals?

Use Google Search Console’s Core Web Vitals report (under “Experience”) for the field-data verdict on every indexed URL. PageSpeed Insights gives a per-page detailed view with both lab and field data. The PageSpeed Insights API and CrUX dataset let you pull the same data programmatically for site-wide monitoring.

Does page speed matter more on mobile than desktop?

Yes. Google uses mobile-first indexing (since 2019) and evaluates Core Web Vitals separately for mobile and desktop. Mobile devices run on slower networks and less powerful CPUs, so the same page often fails on mobile while passing on desktop. Always optimize for mobile first and verify lab tests use a throttled mid-range phone profile, not desktop broadband.

Bottom Line

Page speed isn’t one setting to flip — it’s a dozen small disciplines that compound. Measure first. Optimize images and fonts. Serve modern formats. Lazy-load what’s below the fold, prioritize what’s above it. Compress, minify, cache, and push assets to a CDN. Audit third-party scripts ruthlessly. Tune for the three Core Web Vitals specifically, because those are the numbers Google uses to rank you.

Every one of these practices is documented by Google and measurable in the field. Work through them in order, verify each change in real-user data, and the numbers — and the rankings — will move.