Page Speed Optimization: How to Score 90+ on PageSpeed Insights

How Page Speed Scores Are Calculated

PageSpeed Insights combines two data sources: Lighthouse lab data (a simulated performance test run on emulated hardware) and Chrome User Experience Report (CrUX) field data from real user visits. The lab score (0-100) is calculated from weighted combinations of performance metrics including LCP (25% weight), Total Blocking Time (30% weight), Speed Index (10% weight), CLS (15% weight), First Contentful Paint (10% weight), and Time to Interactive (10% weight). The field data section shows actual Core Web Vitals scores from real users — this is what Google uses for ranking. It is possible to have a high lab score but poor field data (or vice versa), so optimisations should target both. A score of 90+ typically requires: LCP under 2 seconds, Total Blocking Time under 200ms, CLS under 0.1, and a fast server response time (TTFB under 600ms).

• Lab score: weighted Lighthouse simulation on emulated mobile hardware
• Field data: real user CrUX data — this is what Google uses for ranking signals
• LCP (25% weight) and Total Blocking Time (30% weight) are the highest-weighted lab metrics
• A score of 90+ generally requires LCP under 2 seconds and TBT under 200ms
• Mobile scores are typically 30-50 points lower than desktop due to emulated slower hardware
• Target both lab score improvement and field data improvement — they require similar but not identical changes

Step 1: Diagnose Before You Optimise

Optimising page speed without diagnosis is inefficient — different sites have different bottlenecks. Start with PageSpeed Insights (pagespeed.web.dev) for any page you want to improve. The Opportunities and Diagnostics sections identify the specific issues causing your score to be low, ranked by estimated impact in seconds saved. The most common high-impact opportunities are: Eliminate render-blocking resources (deferred JS/CSS), Properly size images, Serve images in next-gen formats, Reduce unused JavaScript, and Remove unused CSS. For root-cause diagnosis beyond PageSpeed Insights, use WebPageTest (webpagetest.org) — it provides a full waterfall diagram showing exactly when each resource loads, which resources block rendering, and where the bottlenecks are. Chrome DevTools' Coverage tool shows exactly how much of your loaded JavaScript and CSS is actually used on each page.

1. 1Run your target URL through PageSpeed Insights — record the current mobile score
2. 2Review the Opportunities section — note the top 3 opportunities by estimated savings
3. 3Run a WebPageTest using a Moto G Power profile from an Indian location for realistic results
4. 4Use Chrome DevTools Coverage tool to measure unused JavaScript and CSS percentage
5. 5Check the CrUX field data section — compare LCP, INP, and CLS values against Good thresholds
6. 6Create a prioritised optimisation list based on estimated impact from PageSpeed Insights

Image Optimisation: The Largest Single Impact

Images are the largest file type on most web pages and the most common cause of slow LCP. A comprehensive image optimisation strategy delivers 40-70% reductions in image payload and 0.5-1.5 second improvements in LCP for typical sites. The hierarchy of image optimisations is: format conversion (WebP or AVIF), compression, correct sizing, lazy loading for below-fold images, and priority loading for the LCP image. WebP format reduces file sizes by 25-35% compared to JPEG at equivalent perceived quality; AVIF reduces by 40-55% but has slightly lower browser support. Use the picture element with type='image/webp' for WebP with JPEG fallback. For the LCP image specifically, add fetchpriority='high' and remove loading='lazy'. For compression, target under 80KB for standard content images and under 150KB for hero images without visible quality degradation. Tools like Squoosh (squoosh.app), ImageOptim, and Sharp (for server-side processing) handle format conversion and compression efficiently.

1. 1Identify all images over 100KB using PageSpeed Insights or Screaming Frog
2. 2Convert identified images to WebP using Squoosh or Sharp — use picture element for browser fallback
3. 3Compress WebP images targeting under 80KB for content images, under 150KB for hero images
4. 4Add explicit width and height attributes to every img element to prevent CLS
5. 5Add loading='lazy' to all images below the fold — remove it from the LCP image
6. 6Add fetchpriority='high' to the LCP image element
7. 7Preload the LCP image with a link rel='preload' as='image' tag in the document head

JavaScript Optimisation: Eliminating Render-Blocking and Unused Code

JavaScript is the most common cause of poor Total Blocking Time (TBT) and INP scores. Render-blocking JavaScript delays the First Contentful Paint and LCP because the browser must download, parse, and execute the script before it can render any content below it in the HTML. Adding the defer attribute to non-critical scripts moves their execution after the HTML is parsed. Adding async allows download in parallel but execution as soon as downloaded — useful for analytics. Unused JavaScript is JavaScript loaded on a page that is never executed — common in sites using large frameworks (jQuery, lodash) or page-builder tools that load their entire feature set on every page. Chrome DevTools Coverage tool quantifies this: a typical WordPress site with multiple plugins may have 60-80% unused JavaScript on any given page. Code splitting (loading JavaScript bundles on-demand rather than all upfront) and tree shaking (removing unused code from bundles at build time) are the standard solutions.

• Add defer to all script tags that are not required before page render
• Add async to analytics and tracking scripts (Google Analytics, Meta Pixel, etc.)
• Use Chrome DevTools Coverage tool to identify unused JavaScript percentage
• Remove unused jQuery or lodash if only a few utility functions are needed — use vanilla JS
• Implement code splitting in webpack or Vite to load JavaScript bundles on-demand
• Remove unused WordPress plugins — each active plugin typically adds 10-100KB of JavaScript
• Use dynamic import() for features that are only needed on user interaction (modals, chat widgets)

CSS Optimisation: Reducing Parse Overhead and Layout Cost

Render-blocking CSS is any CSS loaded in the document head that the browser must fully download and parse before rendering any content. Unlike JavaScript (which can be deferred), CSS needed for above-the-fold content must be loaded synchronously. The standard optimisation is Critical CSS extraction: identify the CSS rules needed to render the above-the-fold content, inline that CSS directly in the HTML head (typically 5-15KB), and load the full stylesheet asynchronously for below-fold content. Tools like Penthouse, Critical (npm package), or built-in Critical CSS features in Next.js and Nuxt.js automate this extraction. For unused CSS, PurgeCSS analyses your HTML and removes any CSS rules that do not match any element on the page — particularly useful for sites using Tailwind CSS (which generates large CSS files in development that should be purged for production).

• Extract Critical CSS (above-fold CSS) and inline it in the document head
• Load the full stylesheet asynchronously using media='print' onload trick or a CSS preloader
• Use PurgeCSS to remove unused CSS rules — especially important for Tailwind CSS and large frameworks
• Minify all CSS files with CSSNano or csso
• Avoid @import rules in CSS — they create waterfall loading dependencies
• Combine multiple small CSS files into one (reduces HTTP requests)
• Remove CSS animations from mobile stylesheets that are not essential — they consume GPU and battery

Server and CDN Optimisation: Reducing TTFB

Time to First Byte (TTFB) is the foundational metric — if your server responds slowly, every other optimisation is limited in impact. For Indian businesses, TTFB is frequently 800ms-2,000ms because their site is hosted on servers in the US or Europe. The solution is geographic proximity: either host on Indian servers (AWS ap-south-1 Mumbai, Google Cloud asia-south1, DigitalOcean Bangalore) or use a CDN with Indian edge nodes (Cloudflare has multiple Indian PoPs, AWS CloudFront has Mumbai and Hyderabad). For dynamic sites (WordPress, custom backends), server-side caching drastically reduces TTFB by serving pre-built HTML rather than dynamically generating the response for each request. WP Rocket for WordPress, Nginx FastCGI cache, or Redis object caching all achieve TTFB reductions of 200-600ms on typical dynamic sites. Target TTFB under 500ms for Indian users — achievable with proper hosting and caching configuration.

• Test TTFB from India using WebPageTest with an Indian test location (Mumbai)
• If TTFB is above 800ms, move hosting to Indian data centres or implement a CDN with Indian PoPs
• Configure Cloudflare (free plan) as a CDN — immediate TTFB improvement for most sites
• Implement full-page caching on WordPress sites using WP Rocket or W3 Total Cache
• Enable Gzip or Brotli compression on your server — reduces HTML, CSS, and JS transfer sizes by 60-80%
• Configure HTTP/2 or HTTP/3 on your server — reduces connection overhead for multiple resource loads
• Set long cache expiry headers (1 year) for static assets (images, CSS, JS) and short TTLs for HTML

Third-Party Script Management

Third-party scripts — Google Analytics, Meta Pixel, Google Tag Manager, Intercom, Hotjar, live chat widgets, A/B testing tools — are collectively one of the biggest causes of poor page speed. Each script adds HTTP requests, JavaScript execution time, and often blocks the main thread. A typical e-commerce site or SaaS landing page might load 15-25 third-party scripts, adding 1-3 seconds of blocking time. The audit approach: use WebPageTest's waterfall to identify every third-party script, measure its impact, and classify it as essential (keep), important-but-deferrable (load async), or unnecessary (remove). Load all analytics and tracking scripts asynchronously or via Google Tag Manager with firing rules set to load after 3-5 seconds of page load (reduces impact on LCP metrics). For chat widgets (Intercom, Drift, Crisp), load them on user interaction rather than on page load — this alone saves 300-800ms of main thread blocking.

• Audit all third-party scripts using WebPageTest's Third-Party Summary report
• Remove any third-party scripts that are unused or have unmeasurable business impact
• Load all analytics and marketing scripts asynchronously via Google Tag Manager
• Configure GTM triggers to fire tracking scripts after user interaction or 3-second delay
• Lazy-load chat widgets (Intercom, Crisp, Freshdesk) on user scroll or click rather than on page load
• Self-host Google Fonts to eliminate a third-party DNS lookup and connection overhead
• Use Cloudflare Zaraz for server-side tag management to remove client-side third-party script overhead

Testing and Validating Page Speed Improvements

After implementing optimisations, validate improvements using the same tools used for diagnosis. Run PageSpeed Insights again to confirm lab score improvement and compare the Opportunities section — successful optimisations should reduce or eliminate the issues that appeared in the original audit. For real-world validation, WebPageTest's Film Strip view shows exactly how the page loads visually for a real user, making it easy to confirm LCP timing improvements. For field data validation, monitor Google Search Console's Core Web Vitals report over the following 4-6 weeks — CrUX data updates weekly and reflects real user improvements with a 28-day rolling window. Set up automated monitoring using Lighthouse CI in your deployment pipeline to prevent regressions. Document your baseline scores and improvements for every optimisation implemented — this creates an accountability record and helps identify which changes had the highest impact.

1. 1Re-run PageSpeed Insights after each optimisation to confirm incremental improvement
2. 2Use WebPageTest Film Strip to visually confirm LCP timing and CLS elimination
3. 3Set up Lighthouse CI in your deployment pipeline to prevent future regressions
4. 4Monitor Search Console Core Web Vitals report weekly for 6 weeks post-optimisation
5. 5Document baseline scores, changes made, and resulting improvements for each optimisation
6. 6Test on real Android mid-range devices for Indian audience using BrowserStack or real device testing