How We Took Our Lighthouse Score From 61 to 100: A Core Web Vitals Guide for 2027

Quick answer: Our homepage scored 61 for mobile performance because a WebGL hover animation ran from the moment the page loaded, creating 17,960 ms of Total Blocking Time in Lighthouse’s test. We started the animation only after a visitor interacts, skipped it on devices without a graphics chip, served right-sized WebP images and set one-year caching for static files. The result: 100 for Performance, Accessibility, Best Practices and SEO on both mobile and desktop.

Key takeaways

One heavy script can sink a score that every other metric would pass.
Total Blocking Time carries the biggest weight in the Lighthouse performance score, at 30 percent.
Right-sizing images often matters as much as converting them to WebP.
You can keep ambitious design and still score 100 if you load it at the right moment.

We rebuilt mediasoli.com in November 2026 with a custom WordPress theme and a big interactive wordmark: when you move your cursor over the logo, coloured ink spreads through the letters. It looked great. Then we ran PageSpeed Insights and the mobile performance score came back at 61. Here is exactly what we found and what we changed, with the real numbers.

The before and after

Metric (mobile)	Before	After
Performance score	61	100
Accessibility	100	100
Best Practices	100	100
SEO	100	100
Total Blocking Time	17,960 ms	30 ms
Speed Index	11.5 s	2.8 s
Largest Contentful Paint	0.9 s	1.1 s
Cumulative Layout Shift	0.011	0

Desktop moved to 100 across all four categories as well. Measured with Google PageSpeed Insights on November 7, 2026.

How the Lighthouse performance score is calculated

Lighthouse blends five lab metrics into one score. Knowing the weights tells you where to look first:

Metric	Weight	What it measures
Total Blocking Time (TBT)	30%	How long the main thread is too busy to respond
Largest Contentful Paint (LCP)	25%	When the main content appears
Cumulative Layout Shift (CLS)	25%	How much the layout jumps around
First Contentful Paint (FCP)	10%	When anything first appears
Speed Index (SI)	10%	How quickly the page visibly fills in

Our page painted fast and did not shift, so LCP, FCP and CLS were fine. TBT, the heaviest metric, was the problem.

Fix 1: Start heavy animation on interaction

The ink effect runs a WebGL shader every frame. On a real laptop with a graphics chip that is cheap. Lighthouse, however, tests on an emulated mid-range phone that often renders WebGL in software, so each frame took a long time on the CPU, and the idle animation kept running. The main thread spent 33 seconds working during the test.

We changed two things. First, the animation now starts on the visitor’s first interaction: a mouse move, touch, scroll or key press. Before that, an identical HTML version of the wordmark is shown, so nothing looks different. Second, the script checks the graphics renderer and skips the effect on software renderers, which protects low-end devices too. We also capped the canvas resolution at 1.5x device pixel ratio.

Fix 2: Serve right-sized WebP images

Lighthouse estimated 519 KiB of image savings. The biggest issues were client logos: PNG files up to 300 pixels wide being shown at around 57 pixels tall. We added a dedicated logo image size (240 by 120 pixels), told WordPress to generate every resized copy as WebP at quality 74, and regenerated the media library. Service images got their own 520 pixel size instead of loading the full original.

Fix 3: Cache static files for a year

Images, CSS, JavaScript and fonts were cached for only 24 hours. We set a one-year cache with the immutable flag for those file types. CSS and JavaScript already carry a version number in their URLs, so updates still reach visitors immediately.

Fix 4: Remove scripts you do not use

A Google sign-in script was loading on every page through a plugin module we did not need. Turning that module off removed a large chunk of unused JavaScript. Check your own site for chat widgets, sign-in buttons, sliders and tracking tags that load everywhere but are used nowhere.

Lighthouse score vs Core Web Vitals

Lighthouse is a lab test on one simulated device. Core Web Vitals are field data from real Chrome users, and they are what Google uses as a page experience signal. The 2027 targets, measured at the 75th percentile of visits:

Largest Contentful Paint: 2.5 seconds or less.
Interaction to Next Paint (INP): 200 milliseconds or less.
Cumulative Layout Shift: 0.1 or less.

A high Lighthouse score is a strong sign you are on track, but check the field data section of PageSpeed Insights or the Core Web Vitals report in Search Console too.

Your Lighthouse 100 checklist

Run PageSpeed Insights on mobile first and sort issues by the metric weights above.
Find long main-thread tasks: animations, sliders, page builders, chat widgets.
Delay non-essential scripts until interaction or idle time.
Serve WebP or AVIF images at the size they are displayed, with width and height set.
Lazy-load images below the fold, but never the main hero image.
Self-host fonts and preload the ones used above the fold.
Set long cache lifetimes for versioned static files.
Remove unused plugins, CSS and JavaScript.
Fix accessibility basics: contrast, labels, link names and heading order.
Retest, then check real-user Core Web Vitals after 28 days.

Speed also supports AI search visibility, because fast, lightweight pages are easier for crawlers to fetch and render. More on that in the technical side of AI search.

Frequently asked questions

Is a Lighthouse score of 100 necessary?

No. Scores of 90 and above are considered good. Aim for green Core Web Vitals for real users first, then push the lab score as high as is practical.

Why does my score change every time I test?

Lighthouse runs on shared machines with simulated network and CPU throttling, so results vary by a few points. Test several times and compare the median.

Can a WordPress site with a page builder score 100?

It is possible but harder, because builders add CSS and JavaScript to every page. A lean custom theme makes it much easier, which is the route we took.

Does site speed affect SEO rankings?

Page experience, including Core Web Vitals, is one of many signals Google uses. Speed rarely beats relevance, but it helps conversions, crawling and user satisfaction.

Want a faster site?

We build fast WordPress and Shopify sites and fix slow ones. Start a project and we will send you a free speed review with the top three fixes for your site.

Sources

Ugene Gumus

Founder, Mediasoli. Shopify Partner.

Ugene builds websites, Shopify stores and SEO strategies for businesses across Ontario. He has worked with 30+ brands in Canada, from local shops to the Ontario Government.

Connect on LinkedIn

← Back to blog