Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

epic: addressing Google Lighthouse audits #250

Open
2 of 9 tasks
jamesericdavidson opened this issue Oct 10, 2024 · 12 comments
Open
2 of 9 tasks

epic: addressing Google Lighthouse audits #250

jamesericdavidson opened this issue Oct 10, 2024 · 12 comments
Assignees

Comments

@jamesericdavidson
Copy link
Contributor

jamesericdavidson commented Oct 10, 2024

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 (advanced docs)
  • Background-to-foreground colour ratio is insufficient:
    • Syntax highlighting
    • .post-date (dark 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.

@jamesericdavidson jamesericdavidson changed the title Discussion: Improving Google Lighthouse scores Improving Google Lighthouse performance Oct 25, 2024
@526avijitgupta
Copy link
Member

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:
image

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
Copy link
Contributor Author

@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
Copy link
Member

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 jamesericdavidson changed the title Improving Google Lighthouse performance epic: addressing Google Lighthouse audits Oct 25, 2024
@jamesericdavidson
Copy link
Contributor Author

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
Copy link
Member

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

image

But Accessibility is at 90 :/

image

@jamesericdavidson
Copy link
Contributor Author

jamesericdavidson commented Oct 28, 2024

@526avijitgupta
Copy link
Member

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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)

@jamesericdavidson
Copy link
Contributor Author

@526avijitgupta I've condensed the tasks discussed into the OP - please edit more in as appropriate, or leave a comment telling me about them.

Creating a PR now to pass more audits on more exampleSite pages

@526avijitgupta
Copy link
Member

Thanks @jamesericdavidson Mostly looks good to me. A few comments:

  1. I would personally say we can skip addressing the color ratio for syntax highlighting. @yashmehrotra what do you think?

Background:foreground colour ratio is insufficient:
Syntax highlighting
.post-date (dark mode)

  1. Let's add a bullet point to the To-Do to update the screenshot of Desktop Lighthouse score in the README. It has become outdated with the new improvements :)

@jamesericdavidson

This comment was marked as outdated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants