Discussion: Improving Google Lighthouse scores

[jamesericdavidson]

Problem Statement

The README mentions the Google Lighthouse score for exampleSite. Without context, the user could believe that Gokarna's performance is "baked in", and requires no action on their part.

Moreover, Lighthouse continues to identify minor issues with Gokarna, which can be either avoided in source code, or by virtue of how the site is deployed.

Please read and discuss below if this is of interest. 👇

User sites

Unless we direct users to evaluate their site with Lighthouse (and highlight the benefits of doing so), some site configurations will be less than ideal.

e.g. Users who do not resize images, or use "modern" formats (such as WebP), are penalised.

Suggestion: Some site-level changes are easy to make statically (i.e. without the use of CDNs, load balancers, and other at-scale deployment mechanisms), and should be recommended in the Gokarna docs.

👋 I can pick this up after #243.

exampleSite

When reviewing the Lighthouse score for exampleSite, the following improvements are highlighted:

Can we identify which of these are addressable:

• In source code?
• Via site deployment?

[jamesericdavidson]

We could also add:

• HTML output minification (CSS/JS assets are already minified) ➡️ feat(config): minify exampleSite HTML output #251
  • Are XML (sitemap, RSS), SVG (icons), and JSON assets minified?
• Asset compression
  • Ahead-of-time (requires the web server to check for existing files, see Codeberg Pages)
  • Just-in-time (Cloudflare, GitHub Pages, Netlify, etc.)