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-...
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.
The 1.5s LCP you're seeing is quite different from what I'm observing. Performance can vary significantly based on location, network conditions, and device capabilities, so perhaps that's contributing to the difference in our results?
It's also possible that different pages have different performance characteristics depending on their content complexity and the navigation structure. Could you share which specific page you tested? That would help me understand the discrepancy better.
Regarding the runtime size - it hasn't been optimized at all yet, so I expect it will be much smaller in the future. I wouldn't be surprised if we can reduce it by a few times through proper optimization.
You're absolutely right that for a pure documentation site, a no-JS approach with prefetching would be lighter. The Hologram docs site is indeed dogfooding - I wanted to showcase the framework's capabilities and stress-test it with real-world usage, even if it means some overhead for this particular use case.
The goal was to demonstrate the instant navigation experience you mentioned, plus features like client-side search and interactive examples in the future that benefit from the stateful client-side architecture.
Thanks for taking the time to test the site and provide this feedback!