The problem with being a slave to these Lighthouse scores is the test is only concerned with the one page you are testing. If you assume your visitor will only visit a single page on your site that's fine, but even if they visit a second page, nearly everything it suggests you do will make that second page load slower than if you had developed the page using the traditional methods- external CSS/JS files that apply to your entire site and can be cached.
The only reason the second page loads slower is because the user hasn't downloaded all the things they need to display it yet - in other words, you're suggesting downloading unused data on the first page in order to make the second page load faster. I'd argue that's not optimal because what you're gaining on the second page you're losing on the first page.
Also you always have to remember that users won't necessarily hit the homepage first. If they click a link from a search or a social media post they might end up on any page in the site. Everything that you do to optimize the homepage should be done for every page. You end up with cacheable assets that are shared between pages and everything else is only downloaded when the user hits a page that actually needs it. That's the way to a fast site.
With HTTP2 request parallelisation having lots of small files is not a bad thing. You can also add prefetch headers for big things like fonts. There's lots of ways to make sites load better.
The Opportunities and Diagnostics sections don't contribute to your Performance score. Your overall Performance score is a weighted average of the Performance metrics [1]. The Opportunities and Diagnostics sections are just potential ideas on changes that may help you. It's up to you to decide what's best for your site.
Webpack 5's federated modules have the potential to be a game-changer for addressing precisely this. Exciting times at the leading edge of webperf optimization.
> …the test is only concerned with the one page you are testing
I use a Lighthouse score for troubleshooting, but at the end of the article there is a chart of the change in Core Web Vitals, which tracks performance of _all_ pages indexed by Google over time.
> "…nearly everything it suggests you do will make that second page load slower…"
This is just not true for _any_ of the suggestions in the article. I guess you can make this argument for breaking down one CSS bundle into four, but their content was picked based on analytics of where people go more often. We make 1 extra request but load much less cruft, and it applies to any page of the website.
> the test is only concerned with the one page you are testing
A common practice is to use Lighthouse CI to test a set of representative pages across your site (such as your homepage, product search pages, and product detail pages if you're an e-commerce site). Every time that someone submits a pull request, Lighthouse CI runs Lighthouse against all of the representative pages to help you gain confidence that you have not introduced weird regressions on the rest of your site. https://web.dev/lighthouse-ci
> nearly everything it suggests you do will make that second page load slower
Which audits exactly are you referring to? To be frank, I highly doubt that claim.
I haven't read this entire blog post in detail, but I've worked extensively in the past with improving page load times. The approach that works best:
1. Have your initial landing page load and render as fast as possible, and cut stuff out to make this happen.
2. That initial page will usually take the user at least a couple seconds to read. While they are doing that, you can load stuff in the background that is needed for other parts of your site, like larger JS bundles. There are a number of ways to do this.
