What evidence would be persuasive to you? Any SSR app being faster than any Polymer app at FMP? Seems like there will be confounding factors.
-
-
For example, these results are pretty lackluster. SSR would at least improve the awful FMP results.pic.twitter.com/gv5xOO9JTf
1 reply 0 retweets 0 likes -
You can dismiss the results from our Preact & Glimmer experiment if you want, but that was a ~60kb JS payload for the same app we ran with both CSR and SSR with rehydration. CSR was indeed faster for fast devices/networks, but SSR handily outperformed at 90th %ile.
1 reply 0 retweets 2 likes -
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.
2 replies 0 retweets 0 likes -
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
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?
-
-
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 - 18 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.