Repository navigation
perf: lazily resolve install size and vulns - #3315
Conversation
Both of these are intensive and scale with package size and/or number of releases and/or number of transitive dependencies. Neither should really block the page load. Both should be cached. In the worst case scenario in my testing, this cut 55% of the cold render ttfb for a package page.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to The page can render its initial placeholders and load analysis and install-size content in the browser; no material merge-blocking regression is established. Pre-merge checks |
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
🔗 Linked issue
N/A
🧭 Context
Both of these operations are intensive and scale with package size and/or number of transitive dependencies. Neither should really block the page load. Both should be cached at a fine grain.
📚 Description
In the worst case scenario in my testing, this cut 55% of the cold render TTFB for the package page:
The SSR response also gets significantly smaller in the worst case (e.g. nitropack's
_payload.jsongoes from 54.6 KB to 11.9 KB, −78%), but of course this size is just shifted to a different downstream request. (However, this latter cost isn't paid when the page is loaded by a crawler that doesn't execute JS 👀.)or, more directly measuring the work that should be removed from the SSR hot path:
(These operations run concurrently, so don't try to add them up.)