Front-end Performance Suggestions (Via Google Lighthouse)

@mgifford I am getting all 100s locally with no changes other than 🐛 Front page meta description still references obsolete node:summary Active (as long as the SEO tools recipe is applied).
Setting a cache here /admin/config/development/performance

What exactly does this refer to? By default it's set to 15 min. Just looking for specific actionable tasks and I'm not sure what they are!

Ah, performance is 99 sometimes right after a cache clear :)

We added performance tests to Drupal CMS around alpha, and I also did some manual review around that. I think all the major issues I found were fixed in time for the 1.0 release, so what lighthouse reports is mostly issues we haven't fixed in core yet, and maybe some contrib.

Serve static assets with an efficient cache policy 12 resources found

I think this might be ddev's default nginx config, it won't happen with apache2 because of Drupal's default .htaccess. Worth looking for/opening an issue against ddev to see if they'd consider adding some static asset caching, possibly the answer will be 'no' because it's for local development. Mostly I would ignore this unless running against and actual production site. You could also switch ddev to use apache (I think there's a command or config option) to confirm.

Consider using a module to inline critical CSS and JavaScript, and use the defer attribute for non-critical CSS or JavaScript.

See ✨ Support inlining critical CSS for faster core web vitals Active for a core issue to add support for this. There are contrib modules but only the theme author knows which CSS is critical or not so it would be better to get the API into core, adjust Olivero to use it, then adjust the Drupal CMS subtheme to use it - or whichever theme Drupal CMS ships with by the time that happens. Adding CSS inline means it's not cacheable by the browser, so it's always a trade-off and could be counter-productive if not done very carefully.

Consider removing unused CSS rules and only attach the needed Drupal libraries to the relevant page or component in a page.

📌 Refactor system/base library Needs work removes up to 6-7kb unused CSS from every page served by Drupal, however the MR has numerous bugs and it should probably be split into smaller issues for easier manual review/testing. I would love some help getting that issue over the line, then we can see what's left.

Passive listeners, issue is here: ✨ Implement passive listeners in jQuery to improve scrolling performance Needs work . However this one might be a Drupal CMS issue indirectly. It would be good to turn off js aggregation, see which js files are loaded, and whether that includes jQuery, and if so which library depends on jQuery. Then we could open an issue to try to either avoid loading that library for anonymous users or to remove the jQuery dependency, or something like that.

Four related issues (including this one):

1. https://www.drupal.org/project/drupal_cms/issues/3500771 🐛 Front-end Performance Suggestions (Via Google Lighthouse) Active
2. https://www.drupal.org/project/drupal_cms/issues/3479394 ✨ Add Google Lighthouse testing Active
3. https://www.drupal.org/project/drupal_cms/issues/3500770 📌 Aim For 100 in Google Lighthouse Scores Active
4. https://www.drupal.org/project/drupal_cms/issues/3481524 📌 CMS Benchmarking Active

Did some very quick testing to see what was loading jQuery for anonymous users.

Drupal CMS out of the box does not load jQuery for anonymous users, this is good.

Drupal CMS with the search recipe enabled does. This is almost certainly due to search_api_autocomplete. We don't have performance tests with the optional recipes installed yet but should add some. I didn't check the other recipes yet for jQuery dependencies on the anon front page.

The search recipe takes the js loaded on the front page from about 10kb to about 284kb which seems like a lot of overhead for something that users won't interact with on the vast majority of requests.

One way to deal with that would be find a way to load the extra js on demand, opened 📌 Try to load autocomplete and other js when the search button is clicked Active for that.

While I was there, I also noticed 📌 Preload lora-v14-latin-regular Active in core.

Could use performance tests for the optional recipes probably, at least the ones that have module dependencies.

Moving back to active but making it a 'plan' because so far at least, this is more about tracking core/contrib issues than Drupal CMS itself.