Website Speed Optimisation: Score 90+ on PageSpeed Insights

Let's be direct: if your website scores below 70 on Google PageSpeed Insights, you are leaving money on the table. Every second of load time delay reduces conversions by roughly 7%, increases bounce rates, and tells Google your site isn't worth prioritising in search results. We've audited hundreds of websites across the US, UK, Australia, and the UAE — and the pattern is consistent. Poor PageSpeed scores are rarely about one catastrophic failure. They're the accumulated weight of a dozen small, fixable problems.

This guide covers the exact website speed optimisation process we apply to client sites at Workflow AI Advisors when we're tasked with hitting 90+ on PageSpeed Insights. No vague advice. No list-padding. Just what actually moves the needle.

Why 90+ Actually Matters (and Why 70 Isn't Good Enough)

Google's PageSpeed Insights tool uses Lighthouse under the hood, scoring your site from 0–100 across four weighted categories: Performance, Accessibility, Best Practices, and SEO. When most people talk about "PageSpeed score," they mean the Performance score specifically.

Here's the commercial reality:

• Core Web Vitals are a confirmed Google ranking signal. LCP, INP (Interaction to Next Paint, which replaced FID in 2024), and CLS directly influence your position in organic search.
• Google Ads Quality Score is affected by landing page experience. A slow landing page raises your CPC and lowers your Ad Rank — meaning you pay more for worse placement.
• 70 is not "decent." On mobile — which Google uses for indexing — a score of 70 often masks LCP values above 4 seconds. That is a problem.

Scores of 90+ on both desktop and mobile are achievable for most websites. Here's how to get there.

Step 1: Read the Report Correctly Before Touching Anything

The single most common mistake is jumping straight to fixes without understanding which metrics are actually dragging your score down. PageSpeed Insights weights each metric differently. In 2024, the Performance score is calculated as follows:

• Largest Contentful Paint (LCP) — 25%
• Total Blocking Time (TBT) — 30%
• Cumulative Layout Shift (CLS) — 15%
• First Contentful Paint (FCP) — 10%
• Speed Index — 10%
• Interaction to Next Paint (INP) — 10%

TBT and LCP together account for 55% of your score. Fix those two, and you'll move from a 60 to an 85+ in most cases. Everything else is marginal gain. Start with the diagnostics panel in PageSpeed Insights — it will tell you exactly which opportunities have the highest estimated savings. Work that list top to bottom.

Step 2: Fix Your Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page — usually a hero image, a large heading, or a video thumbnail — to load. Google's threshold for "Good" LCP is under 2.5 seconds. Most unoptimised sites sit between 4 and 8 seconds on mobile.

The primary causes of poor LCP and their fixes:

Unoptimised hero images

Your hero image is almost always the LCP element. It needs to be served in WebP or AVIF format, sized appropriately for each viewport, and preloaded using <link rel="preload"> in your document head. A 400KB PNG hero image converted to WebP typically drops to 80–120KB with no visible quality loss. That alone can cut LCP by 1.5 seconds.

No CDN or slow hosting

If your server is physically located in the US and your visitor is in Singapore, you're adding 200–300ms of latency before a single byte is transferred. A content delivery network (CDN) like Cloudflare or Bunny.net caches your assets at edge nodes globally. This is non-negotiable for any site targeting multiple markets. At Workflow AI Advisors, we specify CDN configuration as a baseline requirement on every web build and performance audit we deliver.

Render-blocking resources delaying the LCP element

If your CSS or JavaScript files load before the browser can render the LCP element, your LCP time climbs. Inline critical CSS (the styles needed to render above-the-fold content) and defer everything else.

Step 3: Crush Your Total Blocking Time (TBT)

TBT is the sum of all time periods where the main browser thread was blocked long enough to prevent user input response. High TBT means your page feels sluggish even if it looks loaded. It's almost always caused by JavaScript.

The main culprits:

Third-party scripts

Chat widgets, marketing pixels, A/B testing scripts, heatmap tools — every one of these fires JavaScript on your page. Run PageSpeed Insights and look for the "Reduce the impact of third-party code" audit. It will list every offending script with its blocking time. Be ruthless. If you have a chat widget that adds 600ms of TBT but converts at 0.3%, the maths don't work. Load non-critical third-party scripts asynchronously using the async or defer attribute, or use Partytown to move them off the main thread entirely.

Unused JavaScript

Most websites — particularly those built on page builders like Elementor, Divi, or Webflow templates — load hundreds of kilobytes of JavaScript that never executes on any given page. Use Chrome DevTools Coverage tab to identify unused JS, then either tree-shake it at build time or implement code splitting so only the code needed for the current page loads.

Long tasks from bloated plugins

On WordPress specifically, plugin accumulation is the silent TBT killer. Run a clean Lighthouse audit with plugins disabled one by one to identify the offenders. Cache plugins, security scanners running on page load, and contact form plugins with large JS payloads are common culprits.

Step 4: Eliminate Cumulative Layout Shift (CLS)

CLS measures visual instability — how much the page layout shifts during load. That jarring jump when an image loads and pushes text down, or when a font swap causes a reflow, is what Google is penalising. The threshold for "Good" CLS is under 0.1.

Fix it with these three changes:

1. Always set explicit width and height attributes on images and video embeds. This tells the browser to reserve space before the asset loads, preventing reflow.
2. Preload your web fonts and use font-display: optional or font-display: swap with size-adjust. Font swaps cause massive layout shifts. Preloading the font and using size-adjust to match fallback font metrics almost eliminates this.
3. Avoid inserting content above existing content dynamically. Cookie banners, notification bars, and dynamic ad slots injected into the page after load are common CLS sources. Reserve the space with CSS before they inject.

Step 5: Optimise Your Server Response Time (TTFB)

Time to First Byte (TTFB) is how long the browser waits before receiving the first byte of page content from the server. Google's threshold for "Good" is under 800ms. If your TTFB is above 1.5 seconds, everything downstream is compromised regardless of how well you've optimised your assets.

TTFB is fixed at the infrastructure level:

• Enable full-page caching. For WordPress, plugins like WP Rocket or LiteSpeed Cache serve pre-built HTML to returning visitors instead of generating it dynamically on every request. This alone can reduce TTFB from 2 seconds to under 200ms.
• Upgrade your hosting tier. Shared hosting at $5/month is appropriate for hobby sites. If you're running a commercial website and your TTFB is 2+ seconds, the hosting is the problem. A managed VPS or dedicated cloud hosting (AWS, Google Cloud, or DigitalOcean) with proper configuration will solve it.
• Optimise your database. On WooCommerce and large WordPress sites, unoptimised database queries are a primary TTFB driver. Implement object caching via Redis or Memcached, and run regular database cleanup to remove transients, post revisions, and orphaned metadata.

Step 6: Apply Image Optimisation Systematically

Images are the single largest contributor to page weight on most websites. A proper image optimisation workflow is not just about compression — it's about serving the right format, the right size, and loading images at the right time.

The complete image optimisation checklist:

• Convert all images to WebP (or AVIF for the highest compression). Most modern browsers support both.
• Use responsive images with the srcset attribute so mobile devices download appropriately sized assets rather than scaling down desktop images.
• Lazy-load all images below the fold using loading="lazy". This is a native HTML attribute — no JavaScript library required.
• Do NOT lazy-load your LCP element. This is a common mistake that dramatically worsens LCP.
• Set maximum image dimensions. If your content column is 800px wide, there is no reason to serve a 2400px image.
• Strip image metadata (EXIF data) before serving. It adds unnecessary bytes.

Step 7: Leverage Browser Caching and Compression

Once assets reach a user's browser, caching ensures they don't re-download unchanged files on subsequent visits. This dramatically improves performance for returning visitors and reduces server load.

• Set long cache-control headers (1 year) for static assets like images, fonts, CSS, and JS files.
• Use cache-busting via versioned filenames (e.g., styles.v2.css) when files change.
• Enable Gzip or Brotli compression at the server level. Brotli compresses text-based assets (HTML, CSS, JS) roughly 20% better than Gzip. Most modern CDNs and hosts support it.

Step 8: Audit, Measure, and Test on Real Devices

PageSpeed Insights shows you lab data (simulated conditions) and field data (real user experience from the Chrome User Experience Report, or CrUX). Both matter. It's entirely possible to score 95 in lab conditions but have "Poor" field data if your audience is on low-powered Android devices on 4G connections in emerging markets.

Test with these tools in combination:

• PageSpeed Insights — for the official score and Core Web Vitals field data
• WebPageTest.org — for waterfall analysis and filmstrip view of your load sequence
• Chrome DevTools Lighthouse — for deeper diagnostic detail
• Google Search Console Core Web Vitals report — for real-world URL-level data across your entire site

If you're investing in SEO and GEO visibility, technical performance is the foundation everything else sits on. A technically weak site limits how much your content and link-building efforts can achieve.

What a 90+ Score Looks Like in Practice

To give you a reference point: a well-optimised site scoring 90+ on mobile PageSpeed Insights typically has these characteristics:

• LCP under 2.0 seconds
• TBT under 150ms
• CLS under 0.05
• TTFB under 500ms
• Total page weight under 1MB on mobile
• Fewer than 5 render-blocking resources
• All images served in WebP/AVIF with correct dimensions

Getting there requires systematic work, not a single plugin or quick fix. The sites we've optimised at Workflow AI Advisors that moved from sub-60 scores to 90+ consistently saw measurable downstream effects: lower bounce rates, improved organic rankings, and in paid media contexts, better Quality Scores that contributed to the kind of CPA reductions we see across our performance media accounts.

Speed optimisation is also one of the highest-ROI technical investments you can make — the improvements compound. Faster sites rank higher, convert better, and make every marketing channel more efficient.