igrigorik

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

See: https://github.com/http2/http2-spec/wiki/Implementations. nghttp2 is solid.

Once again, I'm not arguing against SW.

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.

And I replied on G+, but also in short: do a background version ping, force a revalidation if version has changed. Gnarly, yes, but works. :-)

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.

Yes, the hope is that they will be! That's why we're working on the "Resource Hints" spec, which documents "reactive prefetch" as one of explicit use cases: https://cdn.rawgit.com/w3c/resource-hints/e19f621dad9856a92b...

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

Actually, this is already handled with <a ping>, see earlier post: https://plus.google.com/+IlyaGrigorik/posts/fPJNzUf76Nx - you're right it's a big latency improvement!

re 1: see https://istlsfastyet.com/

For the record, it's worth noting that we're starting from a state that's nothing short of disastrous: https://alexgaynor.net/2014/nov/12/state-of-news-tls/

Let's hope that twelve months from now, we're looking at a very different landscape. Kudos to NYTimes for issuing the challenge. At the very least, this is an important conversation starter.

Have a favorite perf fail story? Share it at: http://perf.fail/submit ... Let's fail forward together! :)

It's a noop.

Then you're "stuck" with a script loader. Make sure your script loader is itself not being blocked on CSSOM, and is not blocking DOM construction.

Unfortunately defer is broken in bunch of browsers - doesn't preserve order, etc. As a result, if you need to preserve order, you're better off with the async function queueing pattern.

Also, if you need to wait for DOM/CSSOM, then you can still use an async script and just install an event listener for DomContentLoaded / DomInteractive / etc., when it loads.

"Doesn't take up any real resources" is anything but true. An iframe in particular is basically a new render process, which adds a lot of overhead. Just because you've set "display:none" on an element doesn't mean it's free.

To clarify, both script-injected and regular <script> tags block on CSSOM: there is no difference there. Only the "async" attribute on script (i.e. <script async>) removes the dependency on CSSOM... which is why you should use it.

As for why the browser doesn't download the script-injected scripts: they're hidden inside of the inline script blocks. In order to figure out what you intend to do inside of that block, the browser would have to execute the JavaScript. The behavior that you want (download wait for CSSOM) is exactly what you get when you use regular blocking tags - those are discovered by the preloader and requests are dispatched. That's what the first and second diagram in the blog post illustrate.

If you want to initiate an early fetch, just put the <script async> tag at the top - you won't block DOM construction or block on CSSOM. If you need ordered execution, put your inline script block above CSS and add your logic there (but please keep it lean).