CodeForPhilly
Task: Audit performance of Accessibility Statement page
Describe the task
Audit performance of Clean and Green Philly's Accessibility Statement page using Google Lighthouse. Document audit results, including areas of improvement.
Acceptance Criteria
- [x] Generate Lighthouse report for mobile devices
- [x] Generate Lighthouse report for desktop devices
- [x] Post screenshots of results in this issue's comments section
- [x] Write brief summary of audit highlights, including Lighthouse's recommendations for improvement
Additional context
- For instructions on using Lighthouse, see https://developer.chrome.com/docs/lighthouse/overview
Lighthouse report for mobile devices
- Performance score was 74/100, affected by Largest Contentful Paint of 6.3 seconds.
- Accessibilty score was 95/100. The penalty came from
aria-*attribute does not match their roles, which is mentioned in #727 too. - SEO score was 91/100 due to links on page are not crawlable.
Screenshoots
Lighthouse report for desktop devices
- Performance score was 97/100, affected by Largest Contentful Paint of 1.2 seconds.
- Accessiblity score was 95/100 because mismatch of
aria-*attribute and their roles, which is also mentioned #727. - SEO score was 91/100, as links are not crawlable.
Screenshots
Summary
- Performance gets penalty from long image loading time.
- Accessiblity is good (95/100) on both devices. Points deducted from misue of
aria-*attribute on - SEO requires links to be crawlable.
Improvement recommendations
For both mobile devices & desktop devices
- Explore how to reduce image loading time. (Performance)
- Resolve the aria-* mismatch with role issue of the menu button, possibily by refactoring the menu component as discussed in #727. (Accessibility)
- Make links crawlable to search engines. (SEO)
@zheyichn thanks for digging into this. This page has room for improvement on mobile devices. Based on your recommendations, I will create an issue for exploring how to reduce image loading time on this page.
Our SEO score is good on this page (in the 90s). For now, let's prioritize improving page load time because that will benefit our site users more.
@zheyichn I noticed these two recommendations from Lighthouse: "Reduce unused JavaScript" and "Reduce unused CSS." Did the Lighthouse report have details on what JS and CSS can be removed from the page?
Hi @CodeWritingCow , the report didn't directly point out unused code. I tried navigating to the Coverage tab, and it semed to display some compiled CSS/JS code. Do you know how I can trace back to lines of code in our codebase?
Additionally, I looked into how to reduce logo image loading time. The delay mostly came from render delay, meaning rendering is blocked after image resource was loaded.
I found some suggestions on how to improve this, which require cleaning CSS and JS code, or splitting CSS code into smaller files.
- https://web.dev/articles/optimize-lcp
- https://developer.chrome.com/docs/lighthouse/performance/render-blocking-resources#how_to_eliminate_render-blocking_scripts
To ensure the render delay was caused by large stylesheets, I ran Lighthouse on locally served a11y page with global.css removed. And it indeed stopped complaining about LCP as the screenshoot below shows. @CodeWritingCow Do you think this is the right direction to work towards - clean up CSS/JS code? I'm still trying to figure out how to identify unused code blocks for each page precisely. Thanks.
Hi @zheyichn, generally we would use source maps during development to trace compiled code back to the original code. However, Next.js apps disable source maps in production by default.
As a workaround, try running Lighthouse in localhost. The Coverage tab should show uncompiled CSS/JavaScript code.
I like your ideas of cleaning up unused CSS/JS code, and splitting some CSS into smaller files. Definitely worth exploring further. For example, globals.css has many styling rules for maplibregl, but only the Find Properties page needs those rules. Other pages shouldn't have to load those rules.