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

[FEATURE] Optimize Web Performance based on Lighthouse Metric #3045

Closed
1 of 2 tasks
jerensl opened this issue Jun 17, 2024 · 5 comments
Closed
1 of 2 tasks

[FEATURE] Optimize Web Performance based on Lighthouse Metric #3045

jerensl opened this issue Jun 17, 2024 · 5 comments

Comments

@jerensl
Copy link
Contributor

jerensl commented Jun 17, 2024

Why do we need this improvement?

Currently, the website performance metric measured by Lighthouse has fallen under 50, which is not good, imagine a user needs to wait for 2-4 seconds to access the landing page.

To address this issue I have 2 plans:

  1. Short-term, to improve the overall performance above 70%.
  2. Long-term(which required a short-term plan to be done first), adding performance budget for actual site and tracking performance regression on every PR being pushed to master.

How will this change help?

Improving the site performance could have a huge impact on the users when they interact with the website and Improve SEO ranking

The other benefit for developers is to avoid premature optimization in the future, by having performance metrics we avoid making assumptions about performance improvement

Screenshots

Screenshot_17-6-2024_144444_lighthouse-metrics com

How could it be implemented/designed?

Discussion:

  1. Google Tag Manager: The current dependencies we use for Google Analytics are no longer maintained or archived, one reason is the introduction of GA4 which requires you to specify to GTM only and GA4 will work like magic tracking every event. The current GTM has contributed to some performance issues, which block rendering pages, this is more details on how to implement GTM and GA4 using next/script, based on the docs we have half month to started migration before it will no longer supported
  2. Next image optimization: To use an optimized image by NextJS without SSR is not possible, so the other alternative NextJS gives as is by using NextJS Image Loader which required a CDN to store the images. First, we need to make a decision about which CDN to use
  3. Performance budget: First and foremost I would to ask if is there a specific reason to use https://github.com/treosh/lighthouse-ci-action over https://github.com/GoogleChrome/lighthouse-ci because what I see is it's just an abstraction of lhcli from google. We need to discuss what assertion for the performance budget on the website before going to implementation and make sure our web performance already meets the budget first which is being targeted to be above 70 score overall

Tasks that can be taken immediately:

  • Migrate Google Analytics Universal to Google Analytics 4 (Starting July 1, 2023, standard Universal Analytics properties stopped processing data)
  • Implemented next/font for importing font
  • Implemented next/script for scripting and migrate github button script
  • Migrate a current image to webp format, can do it manually one by one using Squoosh App
  • Implementing lazy loading for dropdown, popover, dialog, etc (Should be the last step to take)

A task that required a decision to be made:

🚧 Breaking changes

No

👀 Have you checked for similar open issues?

  • I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

Are you willing to work on this issue?

Yes

Copy link

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

@jerensl
Copy link
Contributor Author

jerensl commented Jun 18, 2024

This issue is very similar to this one. For the Blog my recommendation is to add an infinity scroll for the blog, it's identical to pagination but works on scroll, it will limit the content being shown for example 10 only and when a user scrolls the last content, it will give more content to render. It can be implemented by using intersection observer API

@jerensl
Copy link
Contributor Author

jerensl commented Jun 18, 2024

I spot these issues when measuring the lighthouse performance in staging, netlify has injected a plugin that messes up with the lighthouse score. It will be good to turn this off when measuring lighthouse performance
screenshot-1718702943784

@sambhavgupta0705
Copy link
Member

@jerensl can we continue the discussion here only #89 ??

@jerensl
Copy link
Contributor Author

jerensl commented Jul 30, 2024

@jerensl can we continue the discussion here only #89 ??

My intention in this is to aim for different think, although the performance issues are complex enough and require some nuance to tackle each of the problems. But sure that's also can work

@jerensl jerensl closed this as not planned Won't fix, can't repro, duplicate, stale Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants