You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SPA Mode. Frameworks that support a full SPA mode not just a route
caching repeated navigations is also a big performance thing, it might be nice for the benchmark to include a repeated navigation somewhere to demonstrate and measure the reuse of cached data (from TanStack Team)
Add a navigation-after-hover benchmark: hover for 100 ms, click, and measure time from click to destination content painted across all frameworks. (from TanStack Team)
It would be interesting to test hydrated components with server rendered markup in addition to the current tests for client rendering. Client rendering in React for example should be largely equivalent across different frameworks that support React, so the tests are likely mostly measuring React rather than the framework. The bigger differences may be where the frameworks provide unique takes on the server–client boundary to optimize performance (islands vs React Server Components etc.)
a cpu throttled variant, everything runs unthrottled desktop right now which hides js cost. something like 4x would show where hydration actually hurts
hmr latency next to dev server startup, the time from a file edit until the browser shows it. startup is measured but the edit loop is what devs feel all day
My biggest request for that list would be this: measure an actual navigation. I think this is probably one of the most important metrics for a "meta-framework benchmark". Basically: the time from a click on a link until the destination of that link is rendered.
Currently the only measure close to this is the INP (called "Interaction Breakdown" in https://frameworks.e18e.dev/all-frameworks) but this stops before the actual navigation, it's basically just the click handling itself, and since all frameworks included in this benchmark have async operations between the click and the render of the next page, it doesn't actually measure the navigation.
I just realized that this benchmark does not measure the amount of bytes loaded by the client. There is "body size" which is the HTML document in bytes, but another good one would be "total bytes on initial load" (i.e. HTML + JS bundles since i don't think these apps ship any CSS)
Activity
delucis commentedon Jul 14, 2026
It would be interesting to test hydrated components with server rendered markup in addition to the current tests for client rendering. Client rendering in React for example should be largely equivalent across different frameworks that support React, so the tests are likely mostly measuring React rather than the framework. The bigger differences may be where the frameworks provide unique takes on the server–client boundary to optimize performance (islands vs React Server Components etc.)
dreyfus92 commentedon Sep 28, 2026
nice list, two things i would add are:
Sheraff commentedon Oct 5, 2026
My biggest request for that list would be this: measure an actual navigation. I think this is probably one of the most important metrics for a "meta-framework benchmark". Basically: the time from a click on a link until the destination of that link is rendered.
Currently the only measure close to this is the INP (called "Interaction Breakdown" in https://frameworks.e18e.dev/all-frameworks) but this stops before the actual navigation, it's basically just the click handling itself, and since all frameworks included in this benchmark have async operations between the click and the render of the next page, it doesn't actually measure the navigation.
delucis commentedon Oct 5, 2026
This might be relevant here as presumably @Sheraff means measuring SPA navigation: https://developer.chrome.com/docs/web-platform/soft-navigations
Sheraff commentedon Oct 22, 2026
I just realized that this benchmark does not measure the amount of bytes loaded by the client. There is "body size" which is the HTML document in bytes, but another good one would be "total bytes on initial load" (i.e. HTML + JS bundles since i don't think these apps ship any CSS)