Page speed optimization focuses on reducing load times and improving Core Web Vitals to enhance user experience and Google rankings. In 2026, metrics like LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift) are important ranking signals. The highest-impact fixes include converting and compressing images into WebP format, enabling lazy loading for below-the-fold images, deferring non-essential JavaScript, using browser caching with CDN delivery, and upgrading hosting performance. Most websites can improve page speed by 40–60% within 30 days by optimizing images and JavaScript alone.
Slow pages lose rankings and revenue simultaneously. Google's Core Web Vitals are direct ranking signals, and every additional second of load time drops conversion rates by 7%. The good news: for most websites, 70–80% of the speed improvement comes from fixing images and JavaScript, two areas where the changes are straightforward, and the impact is immediate. This guide covers 20 specific, actionable page speed fixes, ranked by impact.
Page speed optimization works best as part of a broader technical SEO complete guide strategy that includes crawlability, indexing, rendering, and site architecture improvements.
Key Takeaways
- LCP (Largest Contentful Paint) should be under 2.5 seconds unoptimised images are the most common cause of LCP failure.
- INP (Interaction to Next Paint) replaced FID in 2024. Heavy JavaScript execution is the primary INP killer.
- CLS (Cumulative Layout Shift) should be under 0.1. Late-loading ads, fonts, and images without reserved dimensions cause most CLS failures.
- Converting images to WebP delivers a 25–35% file size reduction with no visible quality loss, the single highest-impact free fix.
- Lazy loading images below the fold reduces initial page weight by 40–60% on image-heavy pages.
- Every render-blocking script in the <head> delays LCP defer or async all non-critical JavaScript.
- Core Web Vitals scores differ between lab tools (Lighthouse, PageSpeed Insights) and field data (GSC CWV report) optimise for field data.
Understanding Core Web Vitals: What You Are Actually Optimising For
Page speed optimization is no longer just about a number on a testing tool. Since Google embedded Core Web Vitals into its ranking algorithm and strengthened them further in the March 2026 core update, these three metrics now determine both your search visibility and your visitors' experience. Businesses struggling with LCP, INP, and CLS issues should first understand the fundamentals covered in this detailed Core Web Vitals guide.
| Metric |
What It Measures |
Good Threshold |
Common Fix |
| LCP Largest Contentful Paint |
Load speed of the biggest visible element |
Under 2.5 seconds |
Compress hero image, preload it, use AVIF format |
| INP Interaction to Next Paint |
Responsiveness to clicks, taps, and key presses (replaced FID in 2024) |
Under 200 ms |
Defer JavaScript, break long tasks, yield to the main thread |
| CLS Cumulative Layout Shift |
Visual stability; elements jumping around during load |
Under 0.1 |
Declare image dimensions, reserve ad space, and fix font loading |
Key distinction: Google evaluates your site using field data from the Chrome User Experience Report (CrUX) real visitor sessions over a rolling 28-day window, NOT the simulated lab scores from Lighthouse or PageSpeed Insights. Your field data must pass at the 75th percentile. A perfect Lighthouse score will not compensate for a slow real-world experience on older mobile devices.
To check your scores, open Google Search Console and navigate to Experience > Core Web Vitals. For per-URL details, run pagespeed.web.dev. Both tools show lab data and field data side by side. Prioritise the field data column, which is what actually influences your ranking.
Fixes 1–5: Image Optimization (Highest Impact)
Images account for 50–70% of a typical web page's total weight. Therefore, image optimization consistently delivers the highest return on investment of any single category of fix. Work through these five steps before touching anything else.
Fix 1: Convert to WebP or AVIF
Switching from JPEG or PNG to AVIF can reduce file sizes by up to 50% while maintaining comparable visual quality, according to tests conducted by Netflix. WebP gives roughly a 25–35% reduction in file size and works in nearly all browsers, so it’s near-universal. AVIF is now the go-to format in 2026, but WebP still appears as a fallback within a tag. For the tools, use Squoosh (it’s free, runs in your browser), or go with Cloudinary, or Imgix; all of them can do automatic on-the-fly transformations at the CDN layer
Fix 2: Compress Without Quality Loss
Even when you’re using a modern format, leaving images uncompressed is just wasted bandwidth. Aim for hero images below 200 KB, and keep standard content under 100 KB. Try TinyPNG, ImageOptim, or Squoosh before you upload. And honestly, many image CDNs do this for you automatically; they figure out the best quality setting for each device, so the user experience ends up smoother and all.
Fix 3: Serve Correctly Sized Images with srcset
Uploading a 2,400-pixel-wide image and letting CSS scale it down to 400 pixels on mobile wastes bandwidth. Use the srcset and sizes HTML attributes to serve each device the exact resolution it needs. The sizes attribute is the most commonly overlooked piece it tells the browser how much viewport width the image occupies before CSS is evaluated, so the browser can pick the right source file at the earliest possible moment.
Fix 4: Add Explicit Width and Height Dimensions (Prevents CLS)
Every image, video, and iframe on your page should have explicit width and height attributes. When these are missing, the browser does not know how much space to reserve before the file downloads. The result is a layout shift: content jumps as the image loads, pushing text and buttons out from under the user's cursor. This single fix often resolves most CLS failures.
Fix 5: Lazy Load Below-the-Fold Images
Adding loading="lazy" to images below the visible viewport defers their download until the user scrolls near them. This reduces the initial page weight and significantly speeds up Time to Interactive. However, never apply lazy loading to your LCP (hero) image. Doing so forces the browser to delay loading the most important image on your page, which directly worsens your LCP score. Use fetchpriority="high" on your LCP image instead.
Fixes 6–10: JavaScript Optimization
JavaScript is the primary cause of both render-blocking delays and poor INP scores. Diagnosing render-blocking resources and execution bottlenecks is a common part of advanced technical SEO services for large or JavaScript-heavy websites. After images, trimming and rescheduling JavaScript delivers the most measurable improvements to page speed insights optimization scores. Work through these five fixes systematically.
Fix 6: Defer Non-Critical JavaScript
By default, a <script> tag in the <head> stops HTML parsing, downloads the script, executes it, and only then continues building the page. Adding the defer attribute downloads the script in parallel and executes it after HTML parsing finishes without blocking the first paint at all. Apply defer to almost every script. Use async only for completely independent scripts like analytics that do not need to interact with the DOM.
Fix 7: Async Third-Party Scripts
Tag managers, chat widgets, social embeds, and ad pixels tend to run synchronously by default, and yeah, they end up contending for the main thread while the page loads. It’s better to load them asynchronously and, ideally, defer them until the site actually becomes interactive. Things like WP Rocket’s “Delay JS” option, or that sort of IntersectionObserver-based loader, can set these scripts in motion only when the visitor first shows some kind of action on the page. That usually helps cut the very first load time quite noticeably.
Fix 8: Remove Unused JavaScript
Open Chrome DevTools and press Cmd/Ctrl+Shift+P, then type "Coverage." The Coverage tab highlights unused JavaScript in red. In a typical WordPress or Shopify build, 40–60% of loaded JavaScript is never executed on a given page. Removing unused code directly reduces parse and execution times, which are the root causes of most INP failures. Use the Coverage report monthly after adding new plugins or features.
Fix 9: Code-Split Large Bundles
Modern JavaScript build tools, like Vite, webpack or esbuild, can do code-splitting, which is kinda like splitting a big bundle into smaller pieces that only get fetched when the relevant page or component is needed. So a visitor who lands on your homepage shouldn’t have to download the JavaScript for the checkout page. In React applications, React.lazy() and dynamic import() help with component-level splitting, too; they usually require very little additional setup, so the change is pretty minimal.
Fix 10 Replace Heavy Libraries with Lightweight Alternatives
jQuery weighs around 87 KB minified. For many sites, it is loaded solely to perform tasks that vanilla JavaScript now handles natively (querySelector, fetch, classList). Similarly, Moment.js adds 67 KB for date formatting, whereas Day.js uses 2 KB. Audit every library in your bundle and ask whether a native browser API or a smaller alternative would serve the same purpose. Bundlephobia.com shows the exact cost of any npm package before you add it.
Fixes 11–13: CSS and Render-Blocking Resources
CSS is render-blocking by design. The browser refuses to paint anything until it has built the full CSS Object Model. These three fixes break that dependency, so above-the-fold content appears immediately while the rest of the stylesheet loads in the background.
Fix 11: Inline Critical CSS
Extract only the styles needed to render what is visible on screen at load (typically 5–20 KB) and paste them into a <style> tag directly inside your HTML <head>. This gives the browser everything it needs to paint above-the-fold content without a single external file request. The 2025 Web Almanac found that 85% of mobile pages still fail the render-blocking resources audit, meaning this single fix puts you ahead of most competitors. Tools: Critical (npm package), WP Rocket (WordPress), or Cloudflare's Rocket Loader.
Fix 12: Defer Non-Critical CSS
After inlining critical CSS, load your full external stylesheet asynchronously using fetchpriority="low" on the <link> tag, or the classic media="print" swap technique. This keeps the initial render path clear while the larger stylesheet downloads in the background. Combine this with Brotli compression on the stylesheet file to minimise transfer time.
Fix 13: Remove Unused CSS
Large CSS frameworks like Bootstrap or Tailwind ship with hundreds of utility classes your site never uses. PurgeCSS scans your HTML and JavaScript to find which selectors are actually referenced, then removes everything else. A typical Bootstrap implementation goes from 190 KB down to under 10 KB after purging. Tailwind CSS ships with built-in purging via its content configuration. Run this as part of your production build process.
Fixes 14–16: Hosting, CDN, and Server Response Time
No amount of frontend optimization compensates for a slow server. If your Time to First Byte (TTFB) exceeds 200 ms, fix your infrastructure before touching a single image. In roughly 40% of performance audits, TTFB alone accounts for more than 60% of total LCP time.
Faster rendering and reduced resource waste also support crawling efficiency, especially on large websites following a structured crawl budget optimization guide.
Fix 14 Upgrade Your Hosting Tier (TTFB Target: Under 200 ms)
Shared hosting is economical but imposes severe resource constraints. Moving to managed WordPress hosting (Kinsta, WP Engine, Cloudways) or a VPS immediately reduces TTFB. Serverless platforms like Vercel and Netlify achieve a median TTFB of just 89 ms, compared to 320 ms for shared hosting, according to KeyCDN benchmarks. For website speed for small business owners, moving to a hosting tier is often the highest-impact change available, no code required.
Fix 15: Implement a CDN for Static Assets
A Content Delivery Network replicates your images, CSS, and JavaScript files across dozens of edge servers worldwide. When a visitor in Mumbai requests your site hosted in New York, they instead receive the files from a Mumbai edge node, cutting latency by up to 150 ms. CDNs reduce average page load times by 52% and make sites 3.8× faster for international visitors. Cloudflare's free plan covers most small business needs; its $5/month APO add-on caches full HTML pages at the edge, slashing TTFB to 20–60 ms.
Fix 16 Enable HTTP/2 or HTTP/3
HTTP/2 allows multiplexing, sending multiple files over a single connection simultaneously, eliminating the request queue that HTTP/1.1 creates. HTTP/3 goes further by using QUIC (UDP-based) instead of TCP, removing head-of-line blocking and improving performance on lossy mobile networks. As of 2026, HTTP/3 handles 30% of global web traffic and is supported by 95% of browsers. Enable it in Nginx 1.25+, LiteSpeed, or Caddy. If you use Cloudflare, HTTP/3 is on by default.
Fixes 17–18: Caching and Compression
Caching and compression are the two most reliable ways to improve speed for returning visitors while simultaneously reducing bandwidth costs. Both are server-side settings that require minimal ongoing maintenance once configured.
Cache-Control headers sort of tell the browser how long to keep a file on disk locally before it bothers to ask again, so yeah. If you use static assets with hashed content names (for example, styles.a3f9b2.css), you can usually set max-age=31536000, which is about 1 year. HTML pages, though, should do something calmer, like smaller max-age values or no-cache, plus validation via ETag.
For WordPress sites, plugins such as WP Rocket and LiteSpeed Cache can automatically configure these headers for you, which is handy. If it’s a custom setup, you can set the headers in your Nginx or Apache config, or at the CDN layer.
Fix 18 Enable Brotli (or Gzip) Compression
Brotli outperforms Gzip by 15–30% in file size reduction for text assets (HTML, CSS, JavaScript). Use Brotli at level 11 for static assets pre-compressed during your build pipeline, and Brotli at level 6 for dynamic HTML. Always maintain Gzip as a fallback for legacy browsers. Brotli is supported by 95%+ of modern browsers and is available natively on Nginx, LiteSpeed, Caddy, and through Cloudflare without any configuration on your origin server.
Fixes 19–20: Fonts and Third-Party Scripts
Fonts and third-party scripts are often the last performance bottlenecks teams address and frequently the ones that cause the most frustrating, hard-to-diagnose CLS and LCP failures.
Fix 19 Preload Critical Fonts, Use font-display: swap, Host Locally
Google Fonts loads from an external domain, adding a DNS lookup and TLS handshake delay of 100–300 ms before any font data arrives. Self-hosting your fonts eliminates this entirely. Combine self-hosting with three additional practices: add font-display:swap in your @font-face declaration so text remains visible in a system font during load; add a <link rel="preload"> tag for your .woff2 file so the browser discovers it at the earliest possible moment; and subset your font to remove character sets your language does not use, reducing file size by up to 80%. Next.js users get all of this automatically via the next/font module.
Fix 20 Audit and Remove Unused Third-Party Scripts
Every analytics pixel, chat widget, heatmap tool, A/B testing script, and marketing tag adds load time, competes for main-thread time (harming INP), and can inject unexpected layout shifts. Open Chrome DevTools Network tab, filter by third-party domains, and list everything that loads. Then ask: Does this script generate measurable business value? Remove anything that cannot answer yes. For the remaining scripts, load them via a tag manager with deferral enabled so they execute after the page is fully interactive.
Tag Audit Method: Export a Network waterfall from WebPageTest. Filter requests by domain. Identify every third-party origin. Map each script to a business owner. If no owner claims it, remove it. Teams routinely discover legacy pixels from campaigns that ended years ago still firing on every page load, costing 200–400 ms per visit.
The fixes above apply universally, but each CMS platform introduces its own specific performance patterns. This table maps the most common bottlenecks to the most effective platform-specific solutions.
| Platform |
Most Common Issues |
Recommended Solutions |
| WordPress |
Plugin bloat, unoptimised images, no caching by default, render-blocking scripts |
WP Rocket (caching + critical CSS + JS deferral), Imagify or ShortPixel (image compression), Redis object cache, Cloudflare CDN with APO |
| Shopify |
Heavy theme JS, large product images, third-party app scripts, limited server control |
Switch to a lightweight theme (Dawn), use Shopify's built-in image optimizer, audit and remove unused apps, defer non-critical theme JS |
| Wix |
Platform-generated code overhead, limited technical control, slow TTFB on free plans |
Enable Wix's Turbo mode, use only Wix-native apps, upgrade hosting plan for better TTFB, minimise the number of sections per page |
Related Blog: e-commerce SEO complete guide
Page Speed Tools: How to Audit and Monitor
Use multiple tools at different stages. Each one measures a different slice of the performance picture, and no single tool tells the complete story.
Google PageSpeed Insights (pagespeed.web.dev): Shows both lab data and real-user CrUX field data for any URL. Best for: per-page audits, and kind of seeing exactly what Google measures, like pretty directly. Also, always check mobile scores separately, even if the desktop looks fine.
Google Search Console Core Web Vitals Report: It aggregates field data across your entire site, groups URLs by failure type, and helps you validate fixes after you deploy. This is best for figuring out which pages need the most urgent attention, not the fancy stuff, but the real issues.
Lighthouse (Chrome DevTools): It runs a simulated lab test and gives you a scored report along with quite specific diagnostics. Best for development and debugging. Just remember, Lighthouse scores are different from field data. So use it more like a diagnostic tool.
WebPageTest (webpagetest.org): This one gives detailed waterfall charts, third-party request maps, and tests from real devices on throttled connections. Best for diagnosing TTFB, spotting third-party bottlenecks, and validating performance from particular geographic locations.
GTmetrix: It blends Lighthouse-style scoring with historical performance tracking, plus it shows video playback of the page loading sequence. Best for ongoing monitoring and sharing clear reports with non-technical stakeholders.
People Also Read: technical SEO checklist
Conclusion
Start with your biggest bottleneck. Run PageSpeed Insights right now and find it. In most cases, image optimization or server response time delivers the fastest win. Work through the 20 fixes above in order of impact, monitor your Core Web Vitals field data in Search Console monthly, and treat page speed optimization as an ongoing practice rather than a one-time project. Faster pages rank higher, convert better, and keep visitors engaged; every investment here pays dividends across every other part of your digital marketing.
