Performance optimisation with Lighthouse
Load time shapes bounce rate, conversion and visibility in Google Search. Lighthouse and field data show where to improve it.
Background
Slow pages hurt most on mobile. Google assesses user experience through three Core Web Vitals. Good scores are:
Largest Contentful Paint (LCP): the main content is visible within 2.5 seconds.
Interaction to Next Paint (INP): the page responds to input within 200 milliseconds.
Cumulative Layout Shift (CLS): layout shifts stay at 0.1 or less.
INP replaced First Input Delay in March 2024.
Lab data and field data
Lighthouse tests under fixed lab conditions, which helps to find causes. Google, however, relies on field data from real users in the Chrome UX Report. What counts is the 75th percentile: three out of four page views must hit the target.
Typical fixes
Lazy-loaded images in AVIF or WebP
Critical CSS first, unnecessary JavaScript removed or deferred
Long JavaScript tasks split up
Self-hosted, preloaded fonts
Fixed placeholders to prevent layout shifts
Approach
We measure the key page types in the lab and in the field, then report measures, effort and expected impact. After the changes, we measure again. Field data is collected over 28 days, so the full effect shows later. Performance budgets in the CI pipeline then check every change.
Tracking without the speed penalty
Tracking, advertising and consent scripts often slow a site more than its own code. We load them only after consent and as late as possible. Server-side tagging can reduce browser load further.