Guidance of the Lighthouse. What Is It All About?

Google Lighthouse is an open-source, automated tool developed by Google to help developers improve the quality of their web pages. It audits performance, accessibility, best practices, SEO, and Progressive Web App (PWA) capabilities. Each audit returns a score between 0 and 100 in these categories, making it a powerful benchmark for understanding how well your site performs — not just for users, but also in search engine rankings.

Why Lighthouse scores matter:

• Improved user experience: High scores reflect fast, accessible, and well-structured websites that users find easier and more pleasant to navigate — reducing bounce rates and increasing engagement.
• Better search rankings: Lighthouse evaluates Core Web Vitals, which directly impact Google’s ranking signals. Higher scores can translate into better visibility in search results.
• Conversion and retention: Faster and more reliable sites lead to higher conversion rates. Even small improvements in performance can significantly impact sales, leads, and user satisfaction.
• Trust and credibility: A website that meets modern best practices is perceived as more trustworthy and professional, improving brand perception and user confidence.
• Development guidance: Lighthouse doesn’t just flag issues — it provides actionable insights developers can use to continuously optimize their site over time.

A high Lighthouse score means faster load times, better usability, and increased discoverability — critical elements for retaining visitors and converting traffic into results. Since Google incorporates Core Web Vitals into its ranking algorithm, achieving a strong score isn't just good practice — it’s a competitive edge.

How Google PageSpeed Insights is Different?

Google PageSpeed Insights is a live, Google-hosted version of Lighthouse that is able to measure site performance in various simulated scenarios, e.g.: with throttled data transfer speed, or low-end mobile devices. That gives a real-world example of how potential users might consume a particular website. Sometimes, despite measuring high scores with Lighthouse locally, PageSpeed Insights might still reveal some room for improvement.

Telltale Signs of Low Scores

Many websites suffer from poor Lighthouse scores due to a combination of technical debt, legacy code, and bloated resources. Common culprits include:

• Large JavaScript bundles: Unoptimized scripts that delay first paint and interaction.
• High amount of unused code: Many production bundles that are served to the client contain a high amount of unused code, that does not contribute to the user experience, but on the other hand it can be a burden for the user via longer load times and bundle sizes that have to be served.
• Render-blocking resources: CSS and JavaScript that halt the page from displaying quickly.
• Unoptimized images: Using high-resolution images without compression.
• Poor server response times: Latency in the backend or hosting infrastructure.
• Missing accessibility attributes: Elements that make navigation and general understanding difficult for users with disabilities.
• Inefficient SEO structure: Lack of metadata, improper heading structure, or unoptimized URLs.
• Layout shifts: Unexpected movement of page elements during loading that disrupts the user experience and causes frustration.

These issues not only hurt performance but can negatively affect user satisfaction and search visibility.

Challenges, Tackled by Our Tide

The legacy version of Scriptide's website had mediocre Lighthouse score regarding the Performance and Best practices metrics. As this affects our search engine rankings and user experience, it was both a business and client success requirement, that we needed to improve our score.

Outdated Dependencies

The core framework of our website is Next.js, which is a modern, React based framework that evolves rapidly and continues to improve. A major version upgrade to Next.js is released almost every year.

The legacy version of our website used Next.js 13, however the latest version is Next.js 15. It was a vital point to upgrade to the latest version of the framework, to utilize the performance optimizations that took place over the timespan of the past two years inside Next.js. A version upgrade can seem easy on the first sight, but interconnected dependencies can cause trouble during an upgrade even for a small complexity web app.

Code and Resource Optimization

In case of Scriptide, the site was in a fairly well-managed state already. However, there were three culprits to the suboptimal Lighthouse score. Namely: third-party code bloat, serving unnecessary code and inefficient loading and use of resources. These increase load times and can seriously hurt user experience. First, we identified several key sources:

• Third-party scripts: External libraries that can slow down initial load if not managed properly.
• Unoptimized images: Large, uncompressed images add significant weight. Even, some innocent looking SVGs can silently add hundreds of KBs that might hurt loading time on slower devices.
• Legacy and unused code: Old code no longer in use, unnecessary packages, and dead code blocks bloated our bundles.

To address this, we:

• Used Webpack Bundle Analyzer and Statoscope to pinpoint and remove unused code. ✅
• Implemented lazy loading for third-party scripts, loading them only when needed (e.g., on scroll). ✅
• Leveraged Next.js’s built-in image optimization features to serve responsive, compressed images. ✅

These changes significantly reduced bundle sizes and improved load times, directly boosting our Lighthouse scores.

Render Blocking

On demand loading is not only just useful in the matter of fetching third-party scripts. It can also help delaying the rendering of resource heavy components inside our app, until they just have to be shown.

To make this happen, we utilized the browser native Intersection Observer API and wrapped every render-heavy components with our custom Observable component (note: totally unrelated to RxJS Observables). For reference, see the code below:

Then used that component as such:

This in itself decoupled a lot of computation heavy rendering from the initial page load.

Besides, we used the dynamic import feature of the Next.js to import heavy components.

Website Structure Semantics

Regarding accessibility and best practices, the two things worth mentioning that are related to our app are:

• Heading element hierarchy: Heading elements have different semantic levels (e.g.: h1, h2) which is intended to tell their importance. However it can be easily ignored, these levels have to be used in a logical order, so basically a lower level element shall never be higher in the DOM structure than a higher level heading.
• Using colors with contrast: Using the right amount of contrast ratio is vital for accessibility. On one hand if the UI uses easily differentiable colors, it can indicate for users the different semantics of the elements. On the other hand it is a key aspect of a website to provide the same experience to their users with disabilities (focusing on vision disorders here). Getting the contrast ratio right, plays a huge role in this matter of web accessibility.

So the problematic areas were clear, we just had to adjust our website structure and color utilization to match the expectations.

Layout Shifts

We experienced layout shifts caused by unreserved image space, delayed font rendering, and dynamic content pushing the layout around on initial page load.

To make it more subtle, we had to set:

• fixed dimensions for all our media elements ✅
• preload fonts to minimize flash of unstyled text ✅
• and reserve space for dynamic components using CSS. ✅

These changes significantly improved our Cumulative Layout Shift (CLS) metric.

There Is Light on the Shore

After a sequence of iterative improvements, the results were already visible in the audits of our landing page:

• Performance: Started around the score of 56 - 60 on desktop and 40 - 44 on mobile. We ended up above 90 on desktop and on mobile without changing the look and feel of our website. Feel free to check our scores with Google PageSpeed Insights.
• Accessibility: We had a score of 96 before, but we could increase it to a 100 gladly by fixing all contrast related issues.
• Best Practices: For this one, we were on a moderately good level also, at the score of 75. We managed to go up to 96 points.
• SEO: Our score was 100 already.

Apart from our home page, we also could realize similar growth in Lighthouse scoring on the rest of our pages as well.

Optimizing for Google Lighthouse is more than just chasing a score — it’s about creating a fast, inclusive, and user-friendly experience. By tackling the aforementioned issues, we’ve not only improved our metrics but also built a stronger foundation for future growth.