igrigorik

Shop across millions of stores: find products, build carts, check out, and track orders. Pay for browser purchases with a card the user approves in Shop.

Tip: have a WebMCP-enabled browser? Try it on shop.dev playground.

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.

Click on https://hydrogen.new, it'll spin up a demo store that you can play with in the preview pane.

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.

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.

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

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.

Yep, good feedback. Will route it to the team :)

Interesting. Can I bug you to file this on https://groups.google.com/forum/#!forum/pagespeed-insights-d...? We should investigate what's going on there.

Can you provide a specific URL or example where you're seeing this? I can't reproduce this: https://developers.google.com/speed/pagespeed/insights/?url=...

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

The 2.7MB is a reference to the median.

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.

E.g, to identify sites with CSP: https://discuss.httparchive.org/t/which-sites-have-content-s....

You can access raw HAR captures, as well as pre-aggregated stats via BigQuery.

\o/ ... a pleasant surprise to see this at the top of HN!

If you have any feedback, questions, or suggestions on the contents of the book, please file an issue on GitHub: https://github.com/igrigorik/hpbn.co/issues

See http://httpd.apache.org/docs/trunk/mod/mod_h2.html