Learning the hard way that the modern answer to "holy cow, why is the TTFB so bad and the HTML payload so bloated?" is SSR + inline'd Redux. `window.__INITIAL_STATE__` is my nemesis.
-
Show this thread
-
Replying to @slightlylate
I'm guilty of this too (Sapper serializes preloaded data — equivalent to getInitialProps in Next.js — and includes it to avoid `preload` running on both server and client). Are you saying that it'd be better to fetch that same 300kb asyncly even if TTI suffers as a result?
1 reply 0 retweets 4 likes -
Replying to @Rich_Harris
Not exactly... This approach can be great in moderation; the problem is over-inclusion in the startup snapshot. Too much data, too little of it used. Delay load what isn't in the critical path.
1 reply 0 retweets 8 likes -
Replying to @slightlylate
tricky problem to solve at the tooling level I suppose. If you're streaming the HTML response, and the 300kb is inlined at the bottom of the page, does that sufficiently mitigate the problem?
2 replies 0 retweets 2 likes -
Replying to @Rich_Harris @slightlylate
those 300KB will still have to be parsed & executed on the main thread...
2 replies 0 retweets 1 like
It's significantly better than some of the other approaches (from a raw latency perspective), and we can do *some* parsing off-thread. But from a tools perspective, you know what's going to be needed in initial model bootstrap via component execution on the server...right?
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.