Core Web Vitals improvements
gioboa opened this issue · 13 comments
Prerequisites
- I have written a descriptive issue title
- I have searched existing issues to ensure the feature has not already been requested
🚀 Feature Proposal
Here is the current Core Web Vitals metrics and I think there is space for improvements
Motivation
With Fastify you raised the bar of the Node.js ecosystem for performance, usability, and much more.
I would like to help you to reach the same level on your website.
I have studied the repository and my proposal is to use Qwik to not provide JS at startup with a clear benefit for the CWV and usability for the end users.
I can work on this and create a new website to show you.
Example
No response
I am -1 on this.
To clarify the lighthouse issues:
The 22 images without caching policy are the avatars, which are loaded from github. If we store them locally in the website as suggested in #168 we can set the caching policy.
The excessive dom and the excessive JavaScript main thread is the sourcecode highlighter. We would potentially still have the issue with qwik. What we need is checking if there is a less excessive highlghter implementation.
The other findings can be solved imho easy.
I see 🤔 I collaborated in QwikUI doc https://qwikui.com/ and CWV results for this website clearly show that Qwik can help to improve them.
The performance analysis is based on mobile, I don't think there is a lot of people checking the document using mobile. (I know it is too subjective.)
If you are benchmark using the desktop, the score would be difference.
Before evaluating this migration, there is a list of requirements we need to satisfy:
- we need a template to minimize the CSS-horrors we may write
- we need a search engine to look into the docs. right now we are not running any external services for it thanks to orama-search
- we need to render MD files
- we must support versioned documentation
- we should display code snippets
- we must ( 😢 ) support legacy/older links
- the easier, the better: this means that less config win over tons of config files
- which are the pros over docusaurus? Is it "only" a performance issue? Saving those 4 seconds, how much would it cost to maintainers free time?
The docusaurus migration was performed after a POC:
orama results in a 1.3 mb download, which takes on my machine 1 second. Thats why we have the delay. Also
Ok, I see. I will close the issues first
Using docusaurus reduces quite a bit of maintenance effort and lowers the bar of contributions for docs.
Essentially @gioboa you are volunteering to rewrite Docusaurus or write a custom version of it for us.
It would be great to evaluate when that tool became available. I would love a more performant solution.
yep @mcollina my idea is to create a custom solution with Qwik. it's important to use markdown to lower the bar and use a common easy language. I will work on it, I'm sure to create a performant and maintainable solution.
I would recommend building a new OSS project for "docs with Qwick"
I created this OSS project RoadPlan and I've done the first implementation of this starter with the Fastify docs.
This is the mobile experience, the desktop one is even better.
It's an SSG website hosted on Cloudflare
https://roadplan.pages.dev/
With this link you can run the test
The build process is fast, but I didn't recreate your docs entirely because I would like to hear your thoughts first before spending my time.
No response for months, maybe this aspect is not important for the project. I'll clean up and close this issue. Thanks.
I guess the problem is not that we are not presumable interested. But @Eomm was the driving power behind the whole website project. And now the focus shifted so we have not much manpower behind the website project.
I dont know what I can recommend so that you are not disappointed and on the other hand, I dont know if this is the next step of this project or not.
I see, I'm not disappointed at all, I understood your point of view. 👍
Thanks for clarifying it.