As noted in the comments of the post,there's a lot of noise between runs. The user-timeline data seems to vary in access cost, which I presume affects both equally? Hard to know.
-
-
Replying to @slightlylate @tomdale and
It looks like the SSR version gets ~complete 500ms sooner. This is interesting given the waterfall for the CSR version: http://www.webpagetest.org/result/180202_67_ae21f1a34a7f570599edae125e1c292a/3/details/ … Request for data is delayed by ~300ms because it's blocked by script eval? Why?
1 reply 0 retweets 1 like -
Replying to @slightlylate @tomdale and
I'd have thought critical data would be H/2 pushed or at least `<link rel="preload">`-ed to get the parser working for you and prevent device speed from being a factor in getting that request out to the network.
1 reply 0 retweets 1 like -
Replying to @slightlylate @tomdale and
Also, can we just stop and note how weird it is that we're talking about a low-latency network and desktop CPU in 2018? That choice surely needs exposition. One of the reasons I'd have thought SSR would be a win is that it largely removes client CPU from the equation.
1 reply 0 retweets 1 like -
Replying to @slightlylate @tomdale and
...so these traces under-sell the impact of JS size and latency on the experience. Both would factors improve with SSR. Was a cable connection chosen because most LI customers have *faster* networks than that?
1 reply 0 retweets 1 like -
Replying to @slightlylate @tomdale and
Anyhow, back to the data: What I care about (primarily) is interactivity, as defined by having meaningful content that will be responsive to input (i.e., the main thread isn't locked up). Both traces spend most of their main-thread time on...layout? Huh.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tomdale and
What I get from this is that these test largely measure the effect of loading JS in parallel to data rather than serial: http://www.webpagetest.org/video/compare.php?tests=180202_67_ae21f1a34a7f570599edae125e1c292a-r%3A3-c%3A0%2C180202_VF_84ae556dc7c51e405d5fccccccb383ae-r%3A1-c%3A0&thumbSize=200&ival=100&end=full …pic.twitter.com/MxMNvM4E1L
1 reply 0 retweets 1 like -
Replying to @slightlylate @tomdale and
These are also wholly different to most of what I observe in "SSR" traces on more representative devices and networks. This isn't showing the huge script payload camping out on the main thread seconds after content arrives. In short, it's good work all around.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tomdale and
It's fundamentally different to previous traces I've seen built with Ember SSR and nearly all React SSR solutions. With your permission, I'd like to post traces of the Ember Fastboot site to illustrate the difference.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @kristoferbaxter and
No objections here. Mostly I hope your takeaway is that we're on the same page w.r.t. web performance. It just takes a lot of time to shift the culture in big engineering organizations (as I'm sure you've experienced).
1 reply 0 retweets 2 likes
Thanks. I agree a massive change has taken place here and I'm glad to see it. Evidence like this is convincing: https://www.webpagetest.org/video/compare.php?tests=180913_4A_97fde1f7c6cfc56657089645bed79860-r:1-c:0,180913_YC_c0c8e1363bd571286d7c47fd01a44776-r:1-c:0# …
-
-
Replying to @slightlylate @tomdale and
I don't know that the Glimmer site is actually using SSR here, but the Fastboot one sure is...and that's the style of SSR I'm observing in the wild. It's clearly an anti-pattern.
1 reply 0 retweets 1 like -
Replying to @slightlylate @tomdale and
Presumably the same ~400K/1.3MB (zipped/unzipped) is loaded/run on the server. That processing blocks getting content to the user while it thinks, and then delays interactivity until the ~13s mark when the code hits the client. This is a static page: https://www.webpagetest.org/video/compare.php?tests=180913_4A_97fde1f7c6cfc56657089645bed79860-r%3A1-c%3A0&thumbSize=200&ival=100&end=visual …
1 reply 0 retweets 0 likes - 11 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.