igrigorik

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.

Comment · 5 years ago

FWIW, think of SSR and RSC as complimentary. A tour that explores this: https://shopify.engineering/high-performance-hydrogen-powere...

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.

Comment · 6 years ago

@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.

Comment · 6 years ago

Input delay is bad, period.

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.