The "SSR is for performance" folks need to be posting traces from mid/low-end devices/networks to demonstrate that their experiences get consistently interactive fast enough to make the magic trick actually work.
-
Show this thread
-
When I look at traces, it's 99% this:pic.twitter.com/xvtI02l0FH
6 replies 6 retweets 40 likesShow this thread -
Replying to @slightlylate
This is such a poor take. You constantly rail against performance bubble and when one obvious perf technique goes counter to where WC are at, you point to the opposite: “it’s done poorly so don’t do it at all”
1 reply 0 retweets 1 like -
Replying to @mikesherov
Hrmmmmmm...I genuinely think that rage-click inducing approaches are bad, and I've seen a huge upswing in this over the past few years...and the assumption is motivated reasoning? I'm only asking for folks who make claims to show data.
1 reply 0 retweets 1 like -
Replying to @slightlylate
Yes, I think it’s motivated reasoning. Have you never seen an SSR application that only uses JS for progressive enhancement be fast? And why is the assumption that it’s a “magic trick” somehow?
3 replies 0 retweets 2 likes -
Replying to @mikesherov
The ratios of good/bad (in my experience) suggest that when people bite off a modern, JS-framework-driven architecture + “SSR” (not classic PHP-style “flush to network, then do PE”), things reliably go to hell. It’s not 100%, but it’s close.
2 replies 1 retweet 5 likes
As to the “magic trick” part, what I’m seeing in these traces is that the SSR bits put pixels on screen and then, given the amount of code being loaded late (usually in one or two huge chunks + big hydration tasks), the UI silently breaks. That brokenness gets worse w/ device.
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.