-
-
Notifications
You must be signed in to change notification settings - Fork 142
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
Comments
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 |
@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 |
Regarding this. I'll go through the open points one by one and categorize them. Hopefully this weekend |
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 |
@jamesericdavidson I just re-ran the lighthouse audit and SEO is now at 100! 🎉 But Accessibility is at 90 :/ |
@jamesericdavidson New analysis looks great for desktop and looks good for mobile too. |
@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). |
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) |
@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 |
Thanks @jamesericdavidson Mostly looks good to me. A few comments:
|
To-do
Syntax highlighting.post-date
(dark mode)Affects Theme Documentation - Advanced
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.
The text was updated successfully, but these errors were encountered: