We need to talk about Redux and "SSR". Just saw second (large, commercial) site sending > 100/500K (zipped/unzipped) of HTML payload *this week*. When it takes 3-5x the size of a PNG screenshot of your AFT content to "inline" your "critical" HTML/JS/CSS, something's broken.
-
Show this thread
-
Replying to @slightlylate
What formalisms have you seen for what I’d call “subgraph transfer”?
@GraphQL and caching via the@apollographql client seem like the right idea. And SSR for large DOM that could be tiny client JS seems like the wrong one.1 reply 0 retweets 0 likes -
The last one is a complex and nuanced, which is why I think we collectively aren't navigating it well. Also, most people don't seem to encounter the tradeoff as "html vs. tiny client JS".
2 replies 0 retweets 0 likes -
Replying to @slightlylate @gavindoughtie and
My experience has been that teams view SSR as a way to "fix" the problem of slow, overgrown JS payloads. The idea (which I'd love HCI researchers to dig into) is that thread scrolling will buy them time while the document eventually becomes interactive.
1 reply 0 retweets 0 likes -
All these problems seem to center around "when does stuff hit the browser" in order to render and interact quickly. Tradeoffs abound. For example, the B2B app I'm writing now needs much better runtime behavior than first load behavior.
1 reply 0 retweets 0 likes -
We lack good, comparable metrics. I've been pushing hard on TTI/FID in the hopes that we can move past first-interaction to investigate amortized costs. I.e., how long does a session need to be to justify 10 extra KB of JS for ajax-y interactivity in a particular vertical?
1 reply 0 retweets 0 likes -
Replying to @slightlylate @gavindoughtie and
You can model most "rich" apps as a series of form posts (think Plain HTML GMail vs. "regular" GMail). Today we talk about time-to-interactivity in a one-dimenstional way: the first load. We should instead be talking about session-depth amortized costs.
2 replies 1 retweet 2 likes
I.e., it's true that for some experiences, lots of code up-front makes a great deal of sense. But that's something we should be able to put a number on and measure.
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.