Performance Optimization

I start with real user data, not lab reports. I pull the Chrome User Experience Report for the URL or origin and look at the 75th percentile LCP, FID, and CLS. If any of those is in the 'needs improvement' or 'poor' range, that is my signal to investigate. For an e-commerce site I worked on last year, the CrUX data showed LCP at 4.8 seconds across mobile users, caused mainly by a giant hero image that had not been compressed and a slow database query for product recommendations. I prioritised swapping the image format to WebP and caching the recommendation query; LCP dropped to 2.2 seconds within a week.

From there I use Lighthouse as a debugging assistant, not a scorecard. The lab report tells me what specific resources are blocking the render or taking too long to load, but I never take the overall score as a target. Instead I look at the opportunities section and cross-reference with my real-world data. If CrUX says LCP is poor but Lighthouse says LCP is fine, the user network is the difference – I simulate a slower connection using WebPageTest. That understanding of [Core Web Vitals](/core-web-vitals/) helps me prioritise.

Once I have identified the biggest bottleneck, I apply the appropriate fix. For image-heavy pages that means compression, responsive images, and lazy loading for below-the-fold content. For render-blocking resources I inline critical CSS and defer JavaScript. For server response time I move to a CDN, add full-page caching, and optimise database queries. These are standard [website optimisation](/website-optimization/) techniques. I check the impact on the same CrUX metrics after a week to confirm the change worked.

The key is to iterate on the single worst metric, then move to the next one. I have seen teams try to fix everything at once and end up breaking something they did not measure. A systematic approach avoids that.

The most common trap is chasing Lighthouse scores instead of user outcomes. I have seen teams celebrate a 98 performance score while their real LCP worsened because they removed a font that users actually needed. Lighthouse is a lab tool – it measures a synthetic device on a fast network. Your users are on slow 3G with low-end phones. If you optimise for the lab you might compress images so aggressively that they look blurred on a real screen, or strip out a dependency that causes a layout shift. Always validate against field data before and after.

Another watch-out: assuming performance optimisation is a one-time exercise. It is not. Every new feature, plugin, or third-party script can degrade performance. I once consulted for a site that had a perfect performance budget one month and a 4-second LCP two months later because the marketing team added a tracking script that blocked rendering. That kind of [JavaScript SEO](/javascript-seo/) problem is hard to catch without monitoring. You need a continuous monitoring setup. Use a tool like Lighthouse CI or a custom script that runs on every deployment and compares against the budget.

I also see people over-optimise before measuring. They spend hours minifying code that accounts for 2% of load time while ignoring the 800 KB hero image. Measure first, then cut what matters. And do not forget mobile. [Mobile SEO](/mobile-seo/) is increasingly tied to performance because Google indexes the mobile version first and users on phones are more sensitive to slowness. If you only test on a desktop you will miss half the problem.

Finally, be careful with lazy loading. It is great for reducing initial page weight, but if you lazy load the main hero image you can actually hurt LCP because the browser might download it late. I use native lazy loading only for images below the fold.

For years I treated performance optimisation as a one-off project. I would run an [SEO audit](/seo-audit/), fix the biggest recommendations, and move on. A month later the site would be slow again because the team had added a new widget or a heavy carousel. I now insist on a performance budget and a CI check that fails the build if a new commit blows the budget. That change turned performance into a team discipline rather than a solo cleanup job.

I also got wrong by ignoring the mobile experience early on. I used to do all my testing on a wired desktop connection. When I finally started checking on throttled mobile networks I realised that what felt fast on my MacBook was painful on a real phone. Mobile-first measurement is now non-negotiable for me.

Another mistake: assuming all optimisations are positive. I once aggressively lazy-loaded everything, including the main image, which pushed my LCP much higher because the browser held off loading it. I now lazy load only content below the fold and use fetchpriority="high" on the hero image.

I also underestimated the importance of backend performance. I focused on frontend assets like images and JavaScript but ignored the server response time. On a database-heavy site, indexing and query optimisation had a bigger impact than any frontend tweak. Now I include backend profiling in every performance review.

Finally, I used to rely solely on Lighthouse scores for reporting. I learned that CrUX is the only source that matches what Google sees, and that a change in Lighthouse score does not necessarily mean a change in search ranking. Use the right metric for the right audience.