fwiw when people said Ember was too slow I dove in and took it seriously. Same with @sebmarkbage. It's real.
-
-
Yeah, I don't buy this line of argument. I've seen many sites adopt "SSR" and then lock up devices for 10-15s w/ script. Simply broken.
-
Worse, it's *invisibly* broken. There needs to be some name for this (I'm bad at names), but locking the main thread ain't cool. TTI matters
-
Totally agree about this. Some bad stuff you can get into, and we should make JS-powered sites more bulletproof by default.
-
Honestly, I'd love to see "SSR"d sites simply not ship JS on first load and only pull in JS when served from SW.
-
That'd make the TTFB hit you usually pay for "SSR" more reasonable and prevent invisible breakage.
-
What's the problem with background loading JS? Why does it affect TTFB?
-
Honestly, nobody should use SSR if it makes TTFI worse. TTFB also shouldn't be worse but if worse TTFB improves TTFI, seems ok?
-
Most SSR solutions I've traced do not flush() early, delaying delivery of markup to request critical resources; critical path pushed out.
- 9 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.