This is a super quick post, as I’m mired in a few projects. But! The web is a living document, and I want to get these thoughts out there; I can always update this later.
I’ve spent a fair bit of time over the past 3 weeks trying to chase down how to get a good Lighthouse performance score, particularly as I refine Little CRM and hone in my Web Awesome usage. Lighthouse was constantly dropping the score to the ~80s, leading me to:
- Build a whole static site in 11ty that was just the markup + asset compilation
- Figure out a Caddy setup that would give me HTTP/2 with full compression locally
- Burn even more time after that spamming the “analyze page” button.
Ultimately, the lessons I’ve learned are:
- The Lighthouse tab is finicky; particularly the Cumulative Layout Shift. The other stuff it checks is good, though!
- What Lighthouse reports for Simulated Throttling might not actually reflect real-world loading. Switch to DevTools throttling to check those results as well
- For layout shifting and overall loading details, check the “Performance” tab, it’s much more insightful.
- Make sure to throttle CPU & Network to get reasonable information when testing locally
- Building a good Web Awesome bundle (or really, any framework-layer bundle) is really important for first load performance. a Cloak can work, but for slow network connections it can make things unnecessarily worse. General rule for building the Web Awesome bundle:
page,callout,card,icon,avatar,divider,tab-group. Then, pick the things you really really want to be available ASAP. But everything else (eg: tooltips) should be autoloaded - Break up your applicaton bundles from your framework bundles. Combined with
preloaddirectives on Font Awesome’s CDN, that improves caching and load performance thanks to HTTP/2. - Most importantly: with a slow network connection, there is always going to be some rearranging until SSR gets to be stable. So, aim for getting content on the page for users ASAP. They already know they’re on a bad network
