Fair, we'll have demo links and examples to share in the future. The focus right now is to get hands-on developer feedback on ergonomics, API shape, etc.
I've demoed https://hydrogen.new to many folks.. It's fun to see the eyes light up when they realize that, with one click, they have a fully virtualized and custom environment running in their browser. Amazing product & platform.
The key to unlocking fast first-render is combination of streaming SSR (i.e. streaming HTML instead of just JS blobs), which is enabled by adopting Suspense (i.e. async the data fetch and stream data when available in HTML response, which then hydrates relevant component). RSC layers on top: it establishes a clear boundary between client and server logic, which enables better bundling strategies (as you highlighted), but also per-component and efficient subtree updates for subsequent interactions.
RSC is early but we've been working with the React core team on our use case and, based on the past few months of work and progress, we feel pretty confident about the direction. In particular, shifting legacy React apps towards Suspense+RSC will be a big shift for many, but we don't have that constraint.. We have the "luxury" of starting anew and we're leaning into the bleeding edge because it enables all the right primitives for commerce: fast first render, efficient updates, open space for optimizing bundles and RSC transport protocol, etc.
@cramforce nailed it. One thing I'll add.. I would strongly encourage everyone to collect "field" (real user measurement) data for each of these metrics via their own analytics, as that'll give you the most depth and flexibility in doing root cause analysis on where to improve, etc. The mentions of CrUX and other Google-powered tools are not to create any dependencies, but to help lower the entry bar for those that may not have RUM monitoring already, or will need some time to get that in place.. For those users, we offer aggregated insights and lab-simulations (Lighthouse) to get a quick pulse for these vitals.
It's not a matter of first vs rest but observation that input while the page is loading is, often, where most of the egregious delays happen: the browser is busy parsing+executing oodles of script, sites don't chunk script execution and yield to the browser to process input, etc. As a result, we have FID, which is a diagnostic metric for this particular (painful) user experience problem on the web today.
Note that Event Timing API captures all input: https://github.com/WICG/event-timing. First input is just a special case we want to draw attention to due to the reasons I outlined above. That said, we encourage everyone to track all input delays on their site, and it's definitely a focus area for future versions of Core Web Vitals -- we want to make sure users have predictable, fast, response latency on the web.
I think you're misreading the copy: "PSI estimates this page requires 1 additional round trips to load render blocking resources and 0.0 MB to fully render. The median page requires 4 round trips and 2.7 MB. Fewer round trips and bytes results in faster pages."
Independent and unrelated to Observatory project, but if anyone is curious to dig deeper into Alexa top ~500K and how it changed over time, take a look at the HTTP Archive dataset. Some examples @ https://discuss.httparchive.org/latest.
We should be thinking about how to deliver the best of both worlds: a great experience for older (non-SW) browsers, and an even better experience for those that do. The underlying patterns are effectively the same, SW just makes many things much simpler, and there is no reason to block on SW to start on this path.
To be clear, my squabble is not an argument against SW in any way. SW affords a lot more control to the developer and makes this pattern significantly simpler to implement and deploy.
I'm simply pointing out that you can get most (if not all) of the claimed perf benefits using existing API's. Yes, it won't look as pretty, but if you want to deliver a better experience to existing + older browsers.. this is something to consider.
Actually, you're both right. With http/2 the server can push critical assets delivering similar results. But, that requires that the server supports http/2 and is smart enough to initiate the push, AND those resources are same-origin.
The benefit of above technique is that it's deployable today, doesn't require the destination server to be upgraded, and works for cross-origin resources.
No, HTTP/2 has no effect on this. The insight here is that we're initiating the fetch for the HTML and its critical resources in parallel... which requires that the page initiating the navigation knows which critical resources are being used on the target page.
The early feedback from FF, IE, (and to some extent, Webkit), folks have been positive, and I'm hoping this can be a cross-browser feature in 2015 (yes, I'm an optimist).