The web's superpower is ephemeral use. If first run is unusably slow, who's gonna stick around for another go?
-
-
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.
-
This seems particularly framework-centric. Excited to see streaming pulled into this discussion to avoid the TTFB delays.
-
The approach that I've seen that works around this isn't much better: statically SSRing an "entrypoint", rehydrating full app for content
-
Hm that doesn't seem like a useful SSR solution. The point of user facing SSR is to get them Googlable content fast.
-
Googlebot runs JS; so that works fine. Anyway, we agree that SSR should not delay TTFB = )
-
Fine bingable. Also Googlebot runs some godawful old version of chrome that nobody wants to target (yay evergreen!)
-
today it's Cr41.
- 3 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.