The LCP I see is from Google PageSpeed Insights, meaning it's not benchmarked on my machine! In fact, in my setup I'll get much faster load times, but that performance level likely won't be representative of my users (I have a pretty good fiber connection till the last meter, I use Ethernet to connect, and I have a pretty beefy development workstation). The numbers you will see there aren't exactly comparable to the Lighthouse benchmarks you will perform locally: 1.5s LCP is still pretty decent, considering the average website speed nowadays, just not what I would expect from a static docs website, if that makes sense.

The page I tested is the one linked here in HN (the announcement)! I guess I should've referenced the PageSpeed Insights URL [0]. I hope you can get your bundle sizes smaller in the next versions, because honestly, from my first look (not very in-depth, of course), it's the only thing that's not very attractive about it. Likewise, I keep in mind, though, that most web frameworks nowadays ship very large bundles to achieve hydration and client-side routing.

I'm excited to see future updates to this project!

[0]: https://pagespeed.web.dev/analysis/https-hologram-page-blog-...

Thanks! I looked at the PageSpeed Insights report you linked. Apart from the bundle size (which will definitely be optimized) and bundles caching, other performance issues seem to be related to the page content itself - specifically some analytics scripts and a large animation GIF that's contributing to the load time.

I do notice that the report shows 104 KiB transfer size for the runtime bundle, which I think is actually a relatively reasonable result for a modern web framework, though there's certainly room for improvement. The bundle size will definitely decrease substantially in future versions as I focus on optimization.

Also worth noting that the bundles aren't being cached properly yet, which is another thing the framework should handle automatically - that alone would make a significant difference for repeat visits. This one's an easy fix though.

Everything you've mentioned is noted and will be addressed! Thanks again for taking the time to run the analysis and share the specific results - having concrete data like this is really valuable for prioritizing improvements.