Loadzen

PageSpeed optimisation service

Improve your Google PageSpeed score with fixes that stick

Chasing a number is not enough — you need changes that improve real load time, SEO, and conversions. We translate Lighthouse audits into work your team can ship, with before and after measurement for every change.

A low PageSpeed score is a warning sign: heavy images, slow servers, or JavaScript blocking the main thread before your content can render.

Aligned with Google PageSpeed Insights and real-user field data where available.

Why your PageSpeed score matters beyond the badge

Google PageSpeed Insights scores your site from 0 to 100 based on how quickly it loads and becomes usable on mobile. A score below 50 sits in the red band — a direct signal that real users are waiting too long before they can read, scroll, or interact. Most sites in this range are not failing because of one big problem; they are failing because of five or six overlapping issues that each add a few hundred milliseconds.

The score is calculated from lab metrics — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and others — that together reflect how a page feels to a visitor on a mid-range mobile device on a standard mobile connection. A score of 88 on desktop but 34 on mobile is common, because desktop hides the cost of heavy JavaScript and large images behind faster CPU and network speeds. Google primarily uses mobile performance when ranking your pages.

Search engines and ad platforms reward fast experiences. Pages that load slowly see higher bounce rates before the content appears, lower conversion rates from visitors who stay, and weaker organic rankings over time. A one-second improvement in mobile load time has been measured to lift conversions by 7–10% for ecommerce stores. For lead generation sites, the same improvement reduces form abandonment and cost per lead from paid traffic.

The gap between a score of 35 and 80 is usually closed by the same set of fixes: compressing images and serving them in modern formats, deferring render-blocking JavaScript, configuring caching correctly, and eliminating layout shift. These are well-understood problems with well-understood solutions — the challenge is identifying which issues affect your specific site and implementing fixes that survive future content and plugin changes.

  • Unoptimised images are the single most common cause of a low mobile PageSpeed score
  • Render-blocking JavaScript delays first paint before your content is visible
  • Third-party scripts — analytics, chat, ads — add load time that benefits only you, not the visitor
  • A slow server TTFB drags every downstream metric regardless of front-end work
  • Layout shift from fonts, ads, and dynamic injections fails Cumulative Layout Shift
  • Missing cache headers force browsers and CDNs to re-download assets on every visit

Key performance facts

35→80

typical mobile score range

Sites starting between 25 and 45 on mobile PageSpeed commonly reach 70–85 after targeted image, script, and caching improvements — no redesign required.

7–10%

conversion lift per second saved

A one-second improvement in mobile load time produces measurable revenue uplift for ecommerce stores, according to Google's research.

53%

of mobile users leave at 3 seconds

More than half of mobile visitors abandon a page that takes longer than three seconds to load. Most unoptimised sites exceed that threshold on mobile.

How we increase your PageSpeed Insights score

Every fix maps to a specific Lighthouse audit so progress is measurable before and after.

Image optimisation

Hero and product images are converted to WebP format, resized to match the largest viewport they are served at, and given explicit width and height attributes to prevent layout shift. Preload hints are added for the LCP image so the browser fetches it at the highest priority before discovering it in the HTML. On most sites, image work alone moves LCP from failing to passing.

Caching and CDN

We configure browser caching headers so static assets are served from local cache on repeat visits rather than re-downloaded. A CDN is configured to serve assets from edge locations close to your visitors, reducing round-trip time for users outside your server's region. Stale-while-revalidate policies allow cached pages to be served instantly while fresh versions are fetched in the background.

Render-blocking resource removal

We audit every stylesheet and script that loads in the document head and blocks the browser from painting the page. Non-critical CSS is deferred or loaded asynchronously. Above-fold critical styles are inlined directly into the HTML so the first paint does not wait for a full stylesheet download. The result is a measurable reduction in First Contentful Paint and Total Blocking Time.

JavaScript reduction and deferral

Third-party scripts — analytics tags, chat widgets, marketing pixels, A/B testing tools — are profiled individually for their network and execution cost. Non-critical scripts are deferred until after the page is interactive. Scripts that are never used are removed. For scripts that cannot be deferred, we look for lighter alternatives or consolidation through a tag manager. This directly reduces Total Blocking Time, the second-highest-weighted PageSpeed metric.

Core Web Vitals targeting

We address each of the three Core Web Vitals directly: LCP by optimising hero images and reducing TTFB; INP by profiling and reducing main-thread JavaScript tasks that delay tap responses; and CLS by adding explicit dimensions to images and embeds, stabilising font loading, and preventing late-injected banners from shifting content. Each metric is measured in both lab and field data.

Lazy loading

Images and iframes that appear below the initial viewport are given native lazy loading attributes so the browser defers their download until the visitor scrolls toward them. This reduces the initial page weight, improves Speed Index, and allows the browser to prioritise the LCP element. Third-party embeds — maps, videos, review widgets — are replaced with click-to-load facades that defer the full embed until user interaction.

Font optimisation

We audit every font family and weight loaded on each page and reduce them to the minimum required by the design. Google Fonts are either self-hosted for cache efficiency or given preconnect hints to reduce connection time. The most-used font weight is preloaded so above-fold text renders immediately. Font-display swap is applied to prevent invisible text during load, eliminating a common source of CLS.

Server response time

Time to First Byte is measured across key templates. When TTFB exceeds 600ms, we diagnose the cause: slow PHP execution, missing object caching, insufficient database indexing, or hosting limitations. We implement server-side page caching and object caching where available, and provide a clear recommendation when hosting itself is the ceiling preventing further improvement.

What actually moves a PageSpeed score

PageSpeed Insights uses Lighthouse to generate a weighted score from six metrics. Largest Contentful Paint and Total Blocking Time carry the most weight — together accounting for roughly 60% of the total score. LCP measures when the largest visible element on screen finishes loading: usually the hero image or a large heading. If that element loads in under 2.5 seconds you pass; at four seconds you are in the red. Total Blocking Time measures how long the main thread is blocked by JavaScript before the page can respond to user input. A single third-party marketing script loading synchronously can add 500ms of blocking time on its own.

The practical implication is that not all optimisations move the score equally. Lazy-loading images below the fold improves Speed Index and reduces page weight, but it does not move LCP because LCP measures above-fold content. Minifying CSS reduces file size but rarely moves Total Blocking Time because CSS is not the primary bottleneck on most sites. The changes that move scores most reliably are: serving the hero image as WebP with correct dimensions and a preload hint, deferring non-critical JavaScript (especially third-party tags), and ensuring the server responds in under 600ms. Those three changes address the two highest-weighted metrics directly.

Field data versus lab data is another important distinction. PageSpeed Insights shows both: lab data from Lighthouse run in a controlled environment, and field data from real users captured via Google's Chrome User Experience Report. The two can diverge significantly — a site that scores 72 in the lab may show Needs Improvement in field data if real users have slower devices or the page behaves differently for logged-in visitors. Lab data is actionable and reproducible; field data is what affects your organic ranking signal in Google Search Console.

Before & after results

Representative outcomes from optimization projects. Your results depend on stack and traffic.

SaaS marketing site

Before

Mobile PSI 29

After

Mobile PSI 84

Hero WebP conversion and critical CSS inlining

Local services brand

Before

Desktop 52

After

Desktop 91

CDN configuration and cache headers

Ecommerce landing

Before

FCP 3.1s

After

FCP 1.2s

JavaScript budget enforced and third-party scripts deferred

How Loadzen helps you get faster

  1. 1

    Audit

    We run a deep speed and Core Web Vitals audit on your key templates — home, collection, product, and checkout where relevant. Every issue is ranked by its impact on real user experience and revenue.

  2. 2

    Optimisation

    We implement prioritised fixes: images, scripts, caching, and theme or app bloat — focused on revenue pages first. Each change is tested in staging and measured against a baseline.

  3. 3

    Monitoring

    You get ongoing checks so regressions from new apps, themes, or campaigns are caught before they hurt SEO and sales. Alerts fire when scores drop below your target threshold.

Frequently asked questions

Straight answers about timelines, risk, and what to expect.

What is a good PageSpeed score?
Google classifies scores as Good (90–100), Needs Improvement (50–89), or Poor (0–49). For SEO and conversion purposes, a mobile score above 70 is a practical target for most sites. Scores above 80 place you comfortably above average. Scores below 50 on mobile are worth prioritising, as they typically indicate issues that are also felt by real users as slow load times.
Why is my PageSpeed score different on mobile and desktop?
PageSpeed Insights tests each separately using different device profiles. The mobile test simulates a mid-range Android phone on a 4G connection, which reveals the cost of heavy JavaScript and large images far more harshly than desktop. Most sites score 15–30 points higher on desktop. Google primarily uses mobile performance for ranking, so the mobile score is the one that matters most for organic search.
How do I improve my PageSpeed score quickly?
The fastest gains consistently come from three changes: compressing and converting images to WebP with correct dimensions, deferring non-critical JavaScript (especially third-party tags like analytics and chat), and ensuring the server responds in under 600ms. Together these address the two highest-weighted PageSpeed metrics — LCP and Total Blocking Time — and produce the largest score movements for the least effort.
How fast can you improve my PageSpeed score?
Image and caching fixes often ship in the first week and produce immediate score improvements. JavaScript and font work follow in the second week. Most sites see meaningful mobile score gains within two to three weeks. The full impact on Google's field data — which affects rankings — takes 28 days to refresh in Search Console.
Is mobile or desktop PageSpeed more important?
Mobile comes first for most businesses — Google uses mobile performance for indexing and ranking. We optimise mobile as the primary target, then validate desktop. Desktop scores are almost always higher by default because the test device is faster and the network is better.
Why is my PageSpeed score different from real user speed?
Lab data from Lighthouse and field data from real users can diverge. Lighthouse tests on a fixed simulated device; real users have varying devices, networks, and browser caches. We use both: lab data for reproducible, actionable fixes and field data to verify that improvements show up for actual visitors in Google Search Console.
Can you fix a low PageSpeed score without redesigning my site?
Usually yes. The majority of score improvements come from delivery-layer changes — how and when assets load — rather than from the design itself. We start with images, caching, fonts, and scripts. A redesign is only recommended if the page architecture itself is the bottleneck and no delivery change can compensate.
Do you guarantee a specific PageSpeed number?
We guarantee a structured plan and implementation of agreed priorities. We do not guarantee arbitrary numbers because every site has different constraints — hosting, platform, third-party dependencies — that set a practical ceiling. We will tell you what we believe is achievable for your specific stack before work starts.

See your score — and what to fix first

Run a free PageSpeed check with Loadzen. Get issues, suggestions, and platform-specific next steps.