Low performance score

Larger project

Found on 72% of audited stores.

Improve your Lighthouse/PageSpeed performance score by reducing page weight, eliminating render-blocking resources, optimising images, and addressing Core Web Vitals so Google ranks your store higher in search results.

What it is

The Lighthouse Performance Score (shown in Google's PageSpeed Insights tool) is a single number from 0–100 that summarises how fast your web page loads and responds for real users — especially on mobile. It is calculated from five timing metrics, with the three Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) carrying the most weight. A score below 50 is considered "Poor" by Google; a score above 90 is "Good." Think of it as a health-check report card for your page's speed: every point you gain means real customers are waiting less and leaving less.

Why it matters

Google officially uses page experience signals — including Core Web Vitals — as a ranking factor, meaning a very low score can directly suppress your position in search results and reduce organic traffic. Beyond rankings, a slow page destroys conversions: industry data consistently shows that each additional second of load time drops conversion rates by 10–20 %, and mobile shoppers are the most sensitive. A score of 8/100 on mobile means the vast majority of your mobile visitors are likely bouncing before they even see your products, costing you both ad spend and organic sales. Closing this gap is one of the highest-ROI technical improvements an ecommerce store can make.

How to fix it

  1. Measure first: run your key pages (home, category, product) through Google PageSpeed Insights (pagespeed.web.dev) and note the specific failing audits — LCP, INP, CLS, Total Blocking Time, and Speed Index — before touching anything.
  2. Optimise and compress all images: convert to WebP or AVIF, resize images to their actual display dimensions, add explicit width/height attributes to prevent layout shift (CLS), and enable lazy-loading on below-the-fold images.
  3. Eliminate or defer render-blocking JavaScript and CSS: move non-critical JS to load with defer or async attributes, inline only the critical CSS needed for above-the-fold content, and remove or replace heavy third-party scripts (chat widgets, ad pixels, poorly-coded apps/plugins) that block the main thread.
  4. Reduce total page weight: enable GZIP or Brotli compression on your server/CDN, minify HTML, CSS, and JavaScript files, and audit installed apps/plugins — remove any that are unused, as their scripts load on every page.
  5. Enable a CDN (Content Delivery Network) and browser caching: a CDN serves assets from servers close to each visitor, dramatically cutting Time to First Byte (TTFB), while proper cache headers prevent repeat visitors from re-downloading unchanged assets.
  6. Re-test after each change in PageSpeed Insights and Google Search Console's Core Web Vitals report to confirm real-world improvement, and set a target of reaching a score ≥ 50 (ideally ≥ 90) on mobile.

Fix it on your platform

Pick your platform for the exact steps.

How to fix low performance score on Shopify
  1. Audit apps: Admin → Apps → remove every app you no longer use actively; each installed app injects JS on every storefront page.
  2. Switch to a performance-optimised theme: Online Store → Themes → Explore free themes → choose Dawn (Shopify's reference theme, built for Core Web Vitals). Dawn scores 90+ on mobile out of the box.
  3. In your theme's Liquid, ensure all <img> tags use loading='lazy' for below-the-fold images and include explicit width and height attributes to prevent CLS. Dawn does this by default.
  4. Use Shopify's built-in image CDN: when you reference images via {{ image | image_url: width: X }}, Shopify automatically serves WebP via its global CDN — never hotlink external image sources.
  5. Install a trusted performance app such as Crush.pics or TinyIMG to bulk-compress existing product images, and enable lazy loading store-wide.
  6. Defer third-party scripts: in theme.liquid, move non-essential <script> tags to just before </body> and add the defer attribute.
  7. Enable Shopify's built-in speed optimisations: they are on by default (CDN, HTTP/2, GZIP) — verify nothing has been overridden in Settings → Files or a custom app.
  8. Re-check: use PageSpeed Insights on your live store URL to confirm improvement.
Full Shopify guide →Official Shopify docs ↗
How to fix low performance score on WooCommerce
  1. Install a caching plugin: WordPress Admin → Plugins → Add New → install WP Rocket (paid, best all-in-one) or W3 Total Cache (free). Enable page caching, GZIP, and browser caching.
  2. Install an image optimisation plugin: Plugins → Add New → Imagify or ShortPixel → run bulk optimisation on your Media Library; enable WebP conversion and lazy loading.
  3. Add a CDN: WP Rocket integrates with Cloudflare and BunnyCDN out of the box; alternatively configure Cloudflare free tier via your hosting DNS to proxy all traffic.
  4. Minify & defer JS/CSS: in WP Rocket → File Optimisation → enable Minify JS, Combine JS, Defer JavaScript execution, Minify CSS, Combine CSS, and Load CSS asynchronously.
  5. Reduce plugin bloat: deactivate and delete any plugin that is not in active use — each adds HTTP requests and JS. Plugins → Installed Plugins → bulk deactivate unused ones.
  6. Switch to a lightweight theme: Themes → Add New → install Kadence, Astra, or GeneratePress — all score well on Core Web Vitals with WooCommerce.
  7. Verify via PageSpeed Insights after enabling each feature, then check WordPress Admin → WooCommerce → (Google integration) or a Search Console plugin for field data CWV.
Full WooCommerce guide →Official WooCommerce docs ↗
How to fix low performance score on BigCommerce
  1. Use Cornerstone theme (BigCommerce's official reference theme): Storefront → Themes → select Cornerstone — it ships with lazy-loaded images and CDN-optimised assets.
  2. BigCommerce automatically serves all store assets via Akamai CDN and delivers images via its built-in Image Manager CDN — ensure you are not hot-linking external image URLs in product descriptions.
  3. Optimise product images before uploading: target ≤ 200 KB per image at actual display size; BigCommerce's Image Manager will serve them at the right dimensions.
  4. Reduce third-party script load: Storefront → Script Manager → review every script; delete or disable any that are unused. Set non-critical scripts to load in the Footer and mark them as 'Deferred'.
  5. Enable Cloudflare (free or paid) in front of your BigCommerce store via CNAME setup for additional edge caching and Brotli compression: Settings → Domains → follow the BigCommerce Cloudflare setup guide.
  6. Check App Marketplace for performance-focused image apps (e.g., Amasty Image Optimizer equivalent on BC App Store) if you have a large product catalogue.
  7. Re-test with PageSpeed Insights; monitor Core Web Vitals in Google Search Console → Experience → Core Web Vitals.
Full BigCommerce guide →Official BigCommerce docs ↗
How to fix low performance score on Wix
  1. Wix handles server infrastructure, CDN, and GZIP automatically — you cannot control these directly, but you can control what you put on pages.
  2. Reduce the number of Wix Apps installed: Dashboard → Manage Apps → remove any app not actively used, as each adds JS payload.
  3. Compress and resize images before uploading: use Squoosh (squoosh.app) to convert to WebP and resize to actual display dimensions before adding to Wix Media Manager. Wix will then serve them efficiently.
  4. In the Wix Editor, avoid stacking multiple large video backgrounds, animated GIFs, or auto-playing videos above the fold — these are the most common causes of high LCP on Wix.
  5. Turn on Wix's built-in performance features: Dashboard → Settings → Performance → enable 'Turbo' mode (if available on your plan) and ensure lazy loading is on.
  6. Remove unused custom code blocks: Dashboard → Settings → Custom Code → delete any tracking pixels or widgets you no longer need.
  7. Re-test with PageSpeed Insights and consider upgrading to a higher Wix plan if your current plan limits performance features.
Full Wix guide →Official Wix docs ↗
How to fix low performance score on Squarespace
  1. Squarespace hosts all sites on its CDN with GZIP automatically — focus on what you control: content and third-party code.
  2. Optimise images before uploading: resize to the largest display size needed (max ~2000 px wide) and compress with Squoosh to WebP under 200 KB. Squarespace resizes on the fly but starts from your uploaded file.
  3. Avoid embedding heavy third-party iframes (YouTube embeds load a large JS bundle) — use a lite-embed approach: Pages → Edit → replace standard YouTube blocks with a linked thumbnail image.
  4. Remove unused Code Injection: Settings → Advanced → Code Injection — delete any old analytics, chat, or pixel scripts you no longer use.
  5. Minimise custom fonts: Design → Fonts — each additional font family adds an external HTTP request; limit to 2 families total.
  6. Disable or limit Squarespace Fluid Engine animations and parallax effects on product/category pages — these contribute to CLS and INP on mobile.
  7. Re-test with PageSpeed Insights; note that Squarespace's platform constraints mean scores above 70–80 mobile are hard to achieve without migrating to a more flexible platform.
Full Squarespace guide →Official Squarespace docs ↗
How to fix low performance score on Webflow
  1. Webflow serves assets via Fastly CDN with GZIP — core delivery is handled; focus on asset optimisation and JS.
  2. Optimise images: in Webflow Designer, select each Image element → Asset panel → re-upload WebP versions; enable 'Lazy load' in element Settings panel for all below-the-fold images.
  3. Set explicit width and height on all images to prevent CLS: in the Designer, set fixed dimensions or use intrinsic sizing in Style panel.
  4. Audit custom code and third-party embeds: Project Settings → Custom Code (site-wide head/footer) and Page Settings → Custom Code (page-level) — remove any unused scripts; move non-critical scripts to Before </body> and add defer attribute.
  5. Minimise interactions and animations: heavy Webflow Interactions (GSAP-based) on mobile are a leading cause of high Total Blocking Time — audit via Designer → Interactions panel and remove or simplify any page-load triggers.
  6. Use Webflow's Asset Manager to compress fonts — or switch to system fonts for body text to eliminate font-loading delay.
  7. Re-publish the site after changes: Designer → Publish, then re-test with PageSpeed Insights.
Full Webflow guide →Official Webflow docs ↗
How to fix low performance score on Adobe Commerce (Magento)
  1. Enable built-in full-page cache: Admin → Stores → Configuration → Advanced → System → Full Page Cache → set to 'Varnish Cache' (recommended) or 'Built-In Cache'.
  2. Enable JS and CSS bundling and minification: Admin → Stores → Configuration → Advanced → Developer → JavaScript Settings → Minify JavaScript Files = Yes; CSS Settings → Minify CSS Files = Yes.
  3. Configure a CDN for static assets: Admin → Stores → Configuration → General → Web → Base URLs (Secure) — point static and media base URLs to your CDN endpoint (Fastly, Cloudflare, or CloudFront).
  4. Optimise images: use a Magento extension such as TinyPNG for Magento or Cloudinary to auto-compress and serve WebP; alternatively pre-compress images before upload via bin/magento catalog:images:resize after optimising source files.
  5. Enable Brotli/GZIP at the Nginx/Apache or Varnish layer — this is a server configuration change; work with your hosting provider or DevOps engineer if on managed hosting (e.g., Adobe Commerce Cloud has this available via .magento.env.yaml).
  6. Audit and disable unused third-party modules: Admin → System → Web Setup Wizard → Component Manager, or via CLI: bin/magento module:disable Vendor_ModuleName — each enabled module can add JS/CSS to the frontend.
  7. Re-test with PageSpeed Insights and monitor via New Relic (included with Adobe Commerce Cloud) for TTFB and server-side bottlenecks.
Full Adobe Commerce (Magento) guide →Official Adobe Commerce (Magento) docs ↗
How to fix low performance score on Magento Open Source
  1. Enable full-page cache: Admin → System → Cache Management → enable 'Full Page Cache'; configure Varnish via Admin → Stores → Configuration → Advanced → System → Full Page Cache.
  2. Enable JS/CSS minification: Admin → Stores → Configuration → Advanced → Developer → set Minify JavaScript Files and Minify CSS Files to Yes (use in production mode only).
  3. Set up a CDN: configure static and media base URLs to point to a CDN endpoint in Admin → Stores → Configuration → General → Web.
  4. Compress images in bulk using a free Magento 2 extension (e.g., Kraken Image Optimizer) or pre-process images before uploading to pub/media/.
  5. Enable GZIP at the server level in your Nginx config: add 'gzip on; gzip_types text/css application/javascript image/svg+xml;' to the server block, then reload Nginx.
  6. Run bin/magento deploy:mode:set production and bin/magento setup:static-content:deploy to bundle and minify all static assets.
  7. Monitor performance with PageSpeed Insights after each change.
Full Magento Open Source guide →Official Magento Open Source docs ↗
How to fix low performance score on PrestaShop
  1. Enable CCC (Combine, Compress, Cache): Admin → Back Office → Advanced Parameters → Performance → CCC → enable 'Smart cache for stylesheets', 'Smart cache for JavaScript', 'Minify HTML', and 'Compress inline JavaScript in HTML'.
  2. Enable browser caching: Advanced Parameters → Performance → Browser cache → set to enabled.
  3. Optimise images: Catalog → (any product) → Images tab — PrestaShop has a built-in image resizer; also install a free module like WebP Images by MyPrestaModules to serve WebP format.
  4. Place PrestaShop behind Cloudflare (free tier): update your domain's DNS nameservers to Cloudflare for automatic CDN, GZIP, and caching.
  5. Remove unused modules: Modules → Module Manager → disable and uninstall any module not actively in use — modules inject JS/CSS on every page load.
  6. Re-test with PageSpeed Insights.
Full PrestaShop guide →Official PrestaShop docs ↗
How to fix low performance score on Headless / Custom (I build in code)
  1. Run Lighthouse in CI (GitHub Actions or similar) on every deploy using the lighthouse-ci npm package so regressions are caught automatically.
  2. Implement Next.js Image component (next/image) or equivalent framework image optimisation — it handles WebP conversion, lazy loading, and prevents CLS via reserved space automatically.
  3. Code-split aggressively: use dynamic imports for non-critical components (modals, chat, reviews carousels) so the initial JS bundle is minimal.
  4. Serve from a CDN edge (Vercel Edge Network, Cloudflare Workers, AWS CloudFront); set Cache-Control headers on static assets: 'public, max-age=31536000, immutable'.
  5. Inline critical CSS for above-the-fold content at build time using tools like critical (npm) and load the rest with <link rel='preload' as='style'>.
  6. Use <link rel='preconnect'> and <link rel='dns-prefetch'> in <head> for every third-party origin (fonts, analytics, payment SDKs) to reduce connection setup latency.
  7. Add explicit width and height to all <img> tags or use aspect-ratio CSS to reserve layout space and eliminate CLS.
  8. Monitor real-user Core Web Vitals via web-vitals npm package reporting to your analytics or Google Search Console.
Full Headless / Custom (I build in code) guide →Official Headless / Custom (I build in code) docs ↗
How to fix low performance score on Elementor
  1. In your WordPress admin, go to Elementor → Settings → Performance tab. Enable 'Optimized Asset Loading' (Improved Asset Loading) to load only the CSS/JS required for each page instead of site-wide, then save changes.
  2. Still in Elementor → Settings → Performance, enable 'Improved CSS Loading' to inline critical CSS and defer non-critical stylesheets, and turn on 'Lazy Load Background Images' so off-screen background images set via Elementor widgets are deferred.
  3. Go to Elementor → Settings → Experiments and activate 'Optimized DOM Output' — this reduces the number of wrapper divs Elementor renders, cutting HTML payload and improving rendering performance.
  4. For every image widget in Elementor editor, open the Content tab of the Image or Section/Column background, set the Image Size to the smallest adequate preset (e.g. 'Large' instead of 'Full'), and in the Advanced tab enable the native 'Lazy Load' attribute so images below the fold are not fetched on initial load.
  5. Install a WordPress caching + minification plugin compatible with Elementor (e.g. LiteSpeed Cache or WP Rocket), configure it to minify & combine CSS/JS, enable browser caching, and in its 'Excluded JS/CSS' list whitelist Elementor's core files (elementor/assets/js/frontend.min.js) to avoid breaking interactions.
  6. After applying all changes, go to Elementor → Tools → Regenerate CSS & Data to flush Elementor's stylesheet cache, then verify scores in Google PageSpeed Insights or Lighthouse to confirm Core Web Vitals (LCP, CLS, FID/INP) have improved on both mobile and desktop.
Full Elementor guide →Official Elementor docs ↗
How to fix low performance score on Next.js (Headless)
  1. Replace every native <img> tag with Next.js <Image> from 'next/image', always supplying width, height, and a descriptive alt prop. For above-the-fold hero images set priority={true} to preload them; for everything else rely on the default lazy loading.
  2. Audit third-party and custom scripts: move any <script> tags into Next.js <Script> from 'next/script' and set strategy='lazyOnload' (analytics, chat widgets) or strategy='afterInteractive' (tag managers). Never use strategy='beforeInteractive' unless absolutely required.
  3. Enable the built-in font optimisation: import all Google/custom fonts via 'next/font' (next/font/google or next/font/local). This eliminates the render-blocking font request, self-hosts the font file, and injects an inline font-face declaration automatically.
  4. Reduce JavaScript bundle size: run 'next build && next analyze' (add @next/bundle-analyzer to next.config.js) to spot large dependencies, then code-split heavy components with dynamic(() => import('./HeavyComponent'), { ssr: false }) so they are not part of the initial bundle.
  5. Configure next.config.js for maximum asset optimisation: enable the 'swcMinify' option (default in Next 13+), add image 'formats' (['image/avif','image/webp']), set appropriate 'deviceSizes' and 'imageSizes', and add 'Cache-Control' headers via the 'headers()' function to maximise CDN caching.
  6. Improve Core Web Vitals (LCP, CLS, INP): ensure the LCP image uses priority={true} + explicit dimensions to avoid layout shift, wrap dynamically sized ad/embed containers in a fixed aspect-ratio shell to eliminate CLS, and defer all non-critical data fetching to avoid blocking the main thread.
Full Next.js (Headless) guide →Official Next.js (Headless) docs ↗
How to fix low performance score on Klaviyo
  1. Audit your Klaviyo script loading: In your theme's code (e.g. Shopify theme.liquid or equivalent), locate the Klaviyo onsite JavaScript snippet (typically a <script> tag loading 'static.klaviyo.com/onsite/js/klaviyo.js' or the older 'a.klaviyo.com/media/js/analytics/...'). Confirm it is NOT placed in the <head> without a 'defer' or 'async' attribute — a synchronous load here is a render-blocking resource and kills your Lighthouse score.
  2. Add 'async' to the Klaviyo script tag: Change the snippet from <script src='https://static.klaviyo.com/onsite/js/klaviyo.js?company_id=XXXXXX'></script> to <script async src='https://static.klaviyo.com/onsite/js/klaviyo.js?company_id=XXXXXX'></script>. This prevents the script from blocking the browser's render pipeline while still loading Klaviyo functionality.
  3. Disable or lazy-load unused Klaviyo popup/signup forms: In Klaviyo Admin → Sign-up Forms, review all Published forms. Pause or archive any forms that are not actively used — every active form injects additional JS and CSS into every page load. For forms you keep, ensure they are set to trigger on interaction/exit-intent rather than on page load to defer their payload.
  4. Remove duplicate Klaviyo scripts: Search your theme files and any installed third-party apps for multiple instances of the Klaviyo analytics or identify.js snippet. Having more than one Klaviyo script on a page doubles the network cost. Remove all duplicates, keeping only the single official async snippet.
  5. Defer Klaviyo's Back-in-Stock or embedded form embeds: If you use Klaviyo's embedded forms (placed via a <div class='klaviyo-form-XXXXX'> block), load the Klaviyo Onsite JS snippet only on pages that contain that embed by conditionally rendering the script tag (e.g. using a Liquid 'if' block on product pages only), rather than globally on every page including the homepage and collection pages.
  6. Re-run PageSpeed Insights after each change: After saving your theme edits, run your URL through https://pagespeed.web.dev. Confirm that 'klaviyo.js' no longer appears under 'Eliminate render-blocking resources' or 'Reduce unused JavaScript' in the Opportunities section, and verify your performance score has improved.
Full Klaviyo guide →Official Klaviyo docs ↗
How to fix low performance score on Yotpo
  1. Audit which Yotpo widgets are actively loaded on each page type: in your Yotpo Admin go to Settings → Widgets and disable any widget (e.g. Q&A, Visual UGC carousel, Loyalty panel) that is not displayed on that page — unused widget scripts still load by default and add unnecessary JavaScript payload.
  2. Enable Yotpo's asynchronous / deferred loading: in your theme's Yotpo snippet (usually snippets/yotpo.liquid or the Yotpo app embed block in the theme editor), confirm the <script> tag includes 'async' or 'defer' so it does not block first render. If using the legacy inline snippet, replace it with the async loader script found in Yotpo Admin → Account Settings → Store → Installation.
  3. Lazy-load the Reviews widget below the fold: in the Yotpo Admin go to Settings → Widgets → Reviews Widget → Widget Settings and enable 'Lazy Load' (or 'Load on scroll') so the reviews iframe/JS bundle is only fetched after the main content has rendered, improving LCP and TBT.
  4. Optimise Yotpo UGC / Star-rating images: in Yotpo Admin → Visual Marketing → Gallery, reduce the number of images shown in the initial load (set 'Initial items to display' to 4–6) and ensure 'Image quality' is set to 'Optimised' rather than 'Original' so Yotpo's CDN serves compressed, correctly-sized images instead of full-resolution uploads.
  5. Remove duplicate Yotpo script tags: search your theme code (Layout/theme.liquid, product.liquid, collection.liquid) for multiple yotpo.com/widget.js or staticw2.yotpo.com references — each extra copy doubles the network request. Keep exactly one initialisation call per page, ideally in theme.liquid just before </body>.
  6. Verify Yotpo is served via its CDN and HTTP/2: in Chrome DevTools → Network, filter by 'yotpo' and confirm all assets are served from staticw2.yotpo.com (their global CDN) with status 200 and protocol h2. If you see redirects (301/302) or assets served from your own domain, re-install the widget using the canonical snippet from Yotpo Admin → Account Settings → Store → Installation to restore CDN delivery.
Full Yotpo guide →Official Yotpo docs ↗
How to fix low performance score on Gladly
  1. Audit where the Gladly Sidekick (chat widget) script is loaded: in your theme's layout file (e.g. theme.liquid) or via a tag manager, locate the Gladly snippet — typically a <script> tag loading cdn.gladly.com/gladly/chat/widget.js or similar.
  2. Change the Gladly script tag to load with the 'defer' attribute (e.g. <script defer src='...'>) so it no longer blocks the browser's critical rendering path and does not contribute to render-blocking resource warnings in Lighthouse.
  3. If Gladly is injected via a Tag Manager (Google Tag Manager, Shopify Scripts, etc.), set the tag's firing trigger to 'Window Loaded' or 'DOM Ready' instead of 'Page View' so the widget initialises only after the main content has painted, protecting LCP and FID/INP scores.
  4. Enable Gladly's lazy-initialisation option if available in your Gladly Admin under Settings > Sidekick > Widget Behaviour: toggle 'Delay widget load' or set a timeout (e.g. 3–5 seconds after page load) so the widget assets are fetched after Core Web Vitals are measured.
  5. In Gladly Admin (Settings > Sidekick > Availability), restrict the widget to pages where customer support is most needed (e.g. cart, order-status, contact) rather than loading it site-wide. Remove it from high-traffic landing and collection pages to avoid unnecessary third-party payload on SEO-critical URLs.
  6. Re-run PageSpeed Insights or Lighthouse after applying changes and confirm that the Gladly widget script no longer appears under 'Eliminate render-blocking resources' or 'Reduce the impact of third-party code', then verify Core Web Vitals (LCP, CLS, INP) have improved before deploying to production.
Full Gladly guide →Official Gladly docs ↗

Does your site have this issue?

Run a free SEOLZ scan to find low performance score — and every other issue — across your whole site in minutes.

Scan my site free

Frequently asked questions

What is Low performance score?

The Lighthouse Performance Score (shown in Google's PageSpeed Insights tool) is a single number from 0–100 that summarises how fast your web page loads and responds for real users — especially on mobile. It is calculated from five timing metrics, with the three Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) carrying the most weight. A score below 50 is considered "Poor" by Google; a score above 90 is "Good." Think of it as a health-check report card for your page's speed: every point you gain means real customers are waiting less and leaving less.

Why does low performance score matter?

Google officially uses page experience signals — including Core Web Vitals — as a ranking factor, meaning a very low score can directly suppress your position in search results and reduce organic traffic. Beyond rankings, a slow page destroys conversions: industry data consistently shows that each additional second of load time drops conversion rates by 10–20 %, and mobile shoppers are the most sensitive. A score of 8/100 on mobile means the vast majority of your mobile visitors are likely bouncing before they even see your products, costing you both ad spend and organic sales. Closing this gap is one of the highest-ROI technical improvements an ecommerce store can make.

How do I fix low performance score?

Improve your Lighthouse/PageSpeed performance score by reducing page weight, eliminating render-blocking resources, optimising images, and addressing Core Web Vitals so Google ranks your store higher in search results.

Authoritative references

Related SEO issues