And this was even with several non-optimal conditions, like the gating API call for SSR performing at 1.2s at 90th %ile. A more optimized service tier would have made the improvement even larger, I suspect.
-
-
I believe
@chadhietala has the WPT traces if you'd like to see them.2 replies 0 retweets 1 like -
Replying to @tomdale @slightlylate and
Don’t want to be involved here but feel compelled to respond. Data helps toward the end goal of a great experience for users of many applications. I’ll assume variables are equally accounted for in cells and look at the results, can you provide the raw data to support claims?
2 replies 0 retweets 0 likes -
Replying to @kristoferbaxter @slightlylate and
Take Glimmer out so I don't have a horse in the race and just look at Preact. Preact is much lighter than Polymer out of the box, and for the experiment our JS bundle size was tiny (much much smaller than e.g. YouTube Gaming). Even in that scenario, SSR had better FMP at 90p.
1 reply 0 retweets 1 like -
Replying to @tomdale @kristoferbaxter and
All I'm trying to say is that Preact is a much better fit for pages at the extreme end of performance, because it's both lighter than Polymer and gives you the option of SSR if you need it.
1 reply 1 retweet 1 like -
Replying to @tomdale @kristoferbaxter and
@chadhietala posted traces in the comments: https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/#comment-256438 … Here are the preact-only sets of runs: CSR: http://www.webpagetest.org/result/180202_67_ae21f1a34a7f570599edae125e1c292a/ … SSR+CSR: http://www.webpagetest.org/result/180202_VF_84ae556dc7c51e405d5fccccccb383ae/ …1 reply 0 retweets 0 likes -
Replying to @slightlylate @tomdale and
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.
2 replies 0 retweets 0 likes -
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
...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?
-
-
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 - 17 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.