{"slug": "how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score", "title": "How AI helped me get my website to a perfect Lighthouse score", "summary": "Developer Dean Hume raised his blog's worst-performing pages from a Lighthouse score of 73 to 100 on almost all pages, including mobile, by handing the Lighthouse output to GitHub Copilot running a mix of Opus and GPT Astra. The AI's suggestion to use SVG for images proved wrong when testing showed AVIF and WebP were smaller, so Hume's build now only serves an AVIF width if it is at least 10% smaller than its WebP equivalent, and the first article-card image gets loading=\"eager\" and fetchpriority=\"high\" while the rest stay lazy-loaded. Hume cautioned the result still needs testing on real-world devices.", "body_md": "6 October 2026 ยท [Dean Hume](https://deanhume.com/about/)\n\n# How AI helped me get my website to a perfect Lighthouse score\n\nI've been into web performance for as long as I can remember. Back in the day, I cared about it enough to write a book, [Fast ASP.NET Websites](https://www.manning.com/books/fast-asp-dot-net-websites). My career has since moved into gaming, and while I've kept an eye on web performance, I haven't stayed as up to date as I'd like.\n\nA few of the worst-performing pages on this blog were sitting at a Lighthouse score of 73. I'd been putting off tackling them, but after making some changes to the blog recently, I tried something different: I handed the performance problem to GitHub Copilot, using a mix of Opus and GPT Astra.\n\nI gave AI the Lighthouse output, pointed it at my theme, and asked it to work through the biggest problems first.\n\nI now have a Lighthouse score of 100 on *almost* all pages including mobile.\n\nIt still needs testing on real-world devices, but I've never quite been able to achieve that in the past without a lot of pain.\n\n## Where it got it wrong\n\nIt didn't get it perfect the first time round, but it did a pretty amazing job. The AI assumed SVG would be the smallest and best image format for many of the pages. It's a reasonable guess - SVGs are brilliant for the right job - but when I actually tested it, AVIF and WebP came out smaller for my images.\n\nAVIF are a new format for me personally, although they have been around for a while and are well supported.\n\nIf I hadn't checked, I'd have shipped a slower site and felt very pleased with myself ๐Ÿ˜‚\n\n## Smaller images, measured rather than assumed\n\nOn other pages, AI suggested that the feature image changed from SVG to PNG so it could go through the image build, which already generated responsive WebP versions.\n\nRather than assume AVIF would win for every image, the build now compares the files. Every generated AVIF width has to be at least 10% smaller than its WebP equivalent. If any width fails that comparison, the site sticks with WebP for that image.\n\nWhere AVIF meets the threshold, a `` element offers it to the browser with a WebP fallback. The size comparison happens during the build, so the browser doesn't need to download both formats to decide which to use.\n\n## Load the important image first\n\nSmaller files were only part of the work. I also had to think about the order images load in.\n\nOn some pages (for example [this one](https://deanhume.com/tag/game-development/)), the first image a visitor sees is in the top article card. But it was set to load late, the same as every other image on the page. That meant the most noticeable thing on screen was one of the last things to show up.\n\nThe fix was to load that first image straight away and let the rest load as the visitor scrolls. Pages that already have a header image at the top work as before. That first image is a likely candidate for Largest Contentful Paint, or LCP: the metric that tracks when the largest visible image or block of text appears. It's not a good candidate for delaying until later.\n\nThe template now gives that image `loading=\"eager\"` and `fetchpriority=\"high\"`. The remaining cards stay lazy-loaded. If the tag already has a header image, the first card doesn't get that extra priority.\n\nYou don't need every image to load fast. You need the one people see first to load fast.\n\n## Shorten the font request chain\n\nLighthouse also flagged a chain of critical requests. For the main font, the browser had to discover the stylesheet, then discover the font through that CSS.\n\nAdding a preload before the stylesheet makes the font discoverable directly from the HTML:\n\n```\n\n```\n\nOnly the main Inter Latin font gets that preload. The other fonts still load when needed, and `font-display: swap` stays in place so text can appear in a fallback font while the download completes.\n\n## What to take from this\n\nIf you've been putting off tricky web performance work on your site, give AI the actual lighthouse report or performance metrics rather than just asking it to \"make the site faster\". That gives it somewhere useful to start, and gives you specific changes to check.\n\nAI helped me act on performance problems I'd been putting off. The final result still needed a little testing, but I'm really glad with how things turned out!", "url": "https://wpnews.pro/news/how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score", "canonical_source": "https://deanhume.com/how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score/", "published_at": "2026-10-06 00:00:00+00:00", "updated_at": "2026-10-21 09:41:40.941561+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "generative-ai"], "entities": ["Dean Hume", "GitHub Copilot", "Opus", "GPT Astra", "Lighthouse", "AVIF", "WebP", "Inter"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score", "markdown": "https://wpnews.pro/news/how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score.md", "text": "https://wpnews.pro/news/how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score.txt", "jsonld": "https://wpnews.pro/news/how-ai-helped-me-get-my-website-to-a-perfect-lighthouse-score.jsonld"}}