[FEATURE] Optimize Web Performance based on Lighthouse Metric

[jerensl]

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

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:

• Implementing next/image
• Implementing performance budget using lhcli

🚧 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?

• [X] I have read the Contributing Guidelines

Are you willing to work on this issue?

Yes

[github-actions[bot]]

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]

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]

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