epic: addressing Google Lighthouse audits

[jamesericdavidson]

To-do

• 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 Achieved by Netlify (moved to docs(advanced): rewrite & expand #277)
• Background-to-foreground colour ratio is insufficient:
  • Syntax highlighting/code blocks Dependent on upstream - wontfix
  • .post-date (dark mode & light mode)
  • Blockquotes (light mode)
  • tableOfContents hoverOver colour (light mode)
• Automatically convert between image formats
  Affects Theme Documentation - Advanced
• Test exampleSite in light mode (desktop, mobile)
• Update Lighthouse screenshot

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 performed in code, or recommended in the Gokarna docs.

[526avijitgupta]

Hi @jamesericdavidson , going through the lighthouse score page I see we do still have a 100% score in performance. Although we have 92 as our lowest score in the SEO category, which arguably is the more important one:

I feel like we should separate out the SEO part (and perhaps work on it first?). Therefore, I've created a new issue specifically for that topic. Would make it easier to track

[jamesericdavidson]

@526avijitgupta I think the word 'performance' was a poor choice on my part - I wanted this issue to begin addressing the red and yellow checks in all four sections, essentially making this an overarching discussion or Epic. Breaking this out is a good idea

[526avijitgupta]

Can we identify which of these are addressable:

In source code?
Via site deployment?

Regarding this. I'll go through the open points one by one and categorize them. Hopefully this weekend
But if you get the time and want to work on it then feel free to do so :)

[jamesericdavidson]

IMO we should do as much as possible in Hugo (e.g. minification, even when that option is provided by web hosts/CDNs) before covering external options (such as compression).

e.g. The docs should prioritise Hugo and theme-specific functionality

[526avijitgupta]

@jamesericdavidson I just re-ran the lighthouse audit and SEO is now at 100! 🎉

But Accessibility is at 90 :/

[jamesericdavidson]

Notes

ARIA documentation

• https://accessibilityinsights.io/info-examples/web/aria-toggle-field-name/
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/switch_role

[526avijitgupta]

@jamesericdavidson New analysis looks great for desktop and looks good for mobile too.
We can keep this epic open to potentially improve upon Mobile performance (current score: 97), although it's not too bad right now

[jamesericdavidson]

@526avijitgupta I hope we can claw back some nebulous mobile performance by addressing audits in code.

Other than that, the strict px CSS rules for the avatar are outstanding, and perhaps others like the syntax highlighting (which are user-configurable, so the best we could do is identify/create themes which pass the audit).

[jamesericdavidson]

As above, I believe triaging and highlighting pitfalls in user sites should come after baking in everything we can (syntax highlighting being an odd mix of both)