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 -
Replying to @slightlylate @tomdale and
It's a good thing browsers implement threaded scrolling, else *nothing* would work in those 5 seconds of red.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tomdale and
I don't mean to harp on this to make Fastboot look bad. It's got exactly the same problems as most of the React SSR solutions I've seen deployed. This isn't unique.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @kristoferbaxter and
Yeah, what's running on the FastBoot site is quite old and materially worse than the React SSR implementation. In the LinkedIn feed experiment, we moved to an incremental rehydration model that uses requestIdleCallback to prevent post-JS thread lockup.
1 reply 0 retweets 1 like -
Replying to @tomdale @slightlylate and
In Ember apps today, we still do too much work at runtime, particularly as part of the userland AMD module packaging. Also still too big at ~120kb for emerging markets use cases. But many improvements for both of these issues are in-flight.
1 reply 0 retweets 3 likes -
Replying to @tomdale @kristoferbaxter and
Glad to hear it. 120KB is the edge of the envelope; not much left in the budget after that: https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ …
1 reply 0 retweets 0 likes -
Replying to @slightlylate @kristoferbaxter and
Totally agree. We have an awesome team in Bangalore that builds our LinkedIn Lite product that we serve in emerging markets (https://engineering.linkedin.com/blog/2018/03/linkedin-lite--a-lightweight-mobile-web-experience …). Working with them figure out the right constraints to shoot for.
1 reply 0 retweets 5 likes -
Replying to @tomdale @slightlylate and
Tom Dale Retweeted Zach Leatherman
Oh, one more point on why I think Polymer should be largely disqualified until there is an SSR story in place:https://twitter.com/zachleat/status/1039881142902644736 …
Tom Dale added,
1 reply 0 retweets 0 likes
See, once again, for the umpeenth time, a decent solution for crawlers: https://github.com/GoogleChrome/rendertron …
-
-
Replying to @necolas @slightlylate
Personally, I think there are exciting and unexplored patterns for making SSR UX great by default. I do think it's a design problem more than a technical one. SW helps for consistent users, but sporadic ones? SW likely to have been evicted.
1 reply 0 retweets 1 like - 1 more reply
New conversation -
-
-
Replying to @slightlylate @kristoferbaxter and
That's a lot of operational and architectural complexity to paper over a deficiency in the underlying framework. And much higher resource usage and surface area for attacks. I'd have trouble getting that past SRE and security.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.