I use preact instead of react for small applications to control the overall size of the bundle to improve performance, rather than using more complex build tools or other ssr frameworks for optimization, an example is our personal website. (of course, there is also a reason that it is not complicated and does not require the use of huge ui frameworks or various third-party libraries)
Accessibility Specialist. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
You need to run the mobile page speed test not the desktop one, the reduced CPU power and increased latency that a mobile user may experience is the bit you need to worry about and the mobile test accounts for this with network throttling and CPU slow down.
If you go to page speed insights it will show mobile by default, you still score well 81 / 100 FYI just thought I would give you a heads up as your blocking time from JS is high and could be an easy fix 👍❤️
Thanks for the reminder, I simply did some optimizations and it should be better now. The long blocking time of js seems to be caused by markedjs parsing and rendering markdown. Is there a smaller library recommended?
Accessibility Specialist. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Sadly I am an old school "render it on the server" type of person so I have no recommendations, but perhaps there is a way to "chunk" the page and only render the Markdown that appears above the fold (content visible without scrolling) first and then do the rest in small chunks. That way you won't block the main thread for too long? Just an idea, it might be a nightmare to implement depending on the library you use and your setup.
Either way, 250ms saved on TBT is not to be sniffed at, that is great!
Eventually, I gave up looking for a smaller library of markdown parsers, and instead converted markdown to html during the build phase to avoid the performance penalty of runtime parsing, and it should perform pretty well on mobile as well.
Accessibility Specialist. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
and instead converted markdown to html during the build phase to avoid the performance penalty of runtime parsing
With Astro you should be able to minimize (or delay) the component JS sent to the client to only what's necessary for interactivity (though the migration would be quite a bit more effort).
For the time being Astro considers itself in early beta (0.25.0) focusing on SSG, expanding later to SSR (one experience report).
In short, I don't want to not use a framework at all, I need jsx to split the page into components, and writing html/css/js purely naked is hard to get used to now. . . In addition, the js bundle is mainly stuck on markedjs, which accounts for 70k of the entire bundle size, and is a cpu-intensive function.
I use preact instead of react for small applications to control the overall size of the bundle to improve performance, rather than using more complex build tools or other ssr frameworks for optimization, an example is our personal website. (of course, there is also a reason that it is not complicated and does not require the use of huge ui frameworks or various third-party libraries)
rxliuli.com/
you should really start using PWA
You need to run the mobile page speed test not the desktop one, the reduced CPU power and increased latency that a mobile user may experience is the bit you need to worry about and the mobile test accounts for this with network throttling and CPU slow down.
If you go to page speed insights it will show mobile by default, you still score well 81 / 100 FYI just thought I would give you a heads up as your blocking time from JS is high and could be an easy fix 👍❤️
Thanks for the reminder, I simply did some optimizations and it should be better now. The long blocking time of js seems to be caused by markedjs parsing and rendering markdown. Is there a smaller library recommended?
That is better.
Sadly I am an old school "render it on the server" type of person so I have no recommendations, but perhaps there is a way to "chunk" the page and only render the Markdown that appears above the fold (content visible without scrolling) first and then do the rest in small chunks. That way you won't block the main thread for too long? Just an idea, it might be a nightmare to implement depending on the library you use and your setup.
Either way, 250ms saved on TBT is not to be sniffed at, that is great!
Eventually, I gave up looking for a smaller library of markdown parsers, and instead converted markdown to html during the build phase to avoid the performance penalty of runtime parsing, and it should perform pretty well on mobile as well.
Yeah SSR is the way forward for anything like this, great work hitting that magic 100! It took me longer than 3 hours to fix mine put it like that!
With Astro you should be able to minimize (or delay) the component JS sent to the client to only what's necessary for interactivity (though the migration would be quite a bit more effort).
For the time being Astro considers itself in early beta (0.25.0) focusing on SSG, expanding later to SSR (one experience report).
I've completed
dev.to/rxliuli/personal-website-pe...
I don't see a reason why you would use a framework for this site. This is a one pager
In short, I don't want to not use a framework at all, I need jsx to split the page into components, and writing html/css/js purely naked is hard to get used to now. . . In addition, the js bundle is mainly stuck on markedjs, which accounts for 70k of the entire bundle size, and is a cpu-intensive function.
stats.html: file.io/ziBNipcv9Pzd
JSX to split page into components? Im pretty sure every templating language has it (ie liquid) and framework is not necessary to do it.
I would go as far as say that 11ty with some liquid is good enough for that and has 0 js served by default.