1/3. I'm glad you agree that it is way more impactful for almost everyone for frameworks to solve the size problem for apps on top, vs trimming 50KB from the framework. I encourage people to switch from evaluating & evangelizing framework size to that!
-
-
Replying to @lmeyerov @slightlylate and
2/3. Personal note: Apologies for using the colloquial interp of "who know what they're doing". As a language & system designer, I'm sensitive to when we push our inability to solve problems to our users, especially for enabling a wider pyramid of folks.
2 replies 0 retweets 0 likes -
Replying to @lmeyerov @slightlylate and
3/3. I'm curious for state of the art (for reasonable *super low* effort): What is the cost of those extra ~50KB? - Network: ~none b/c cdn/vendor cache - Parsing: light to beginwith - Lazy interp: 10ms? 50ms?
3 replies 0 retweets 0 likes -
Good question! I've been digging into what the probable (global) P75 and P90 devices & networks for Q2'21 will be. There's actually some good news on the network front. Devices, not so much.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @lmeyerov and
The network situation has gotten pretty good compared to old 2G-ish baselines, even in the rural US, but oversubscription remains a major challenge even when you have "4G". I predict a 3Mbps connection will be a reasonable "slow" target over the next year or so.
1 reply 0 retweets 1 like -
Replying to @slightlylate @lmeyerov and
If you set a 5 second window to interactive, and ignore all connection setup and client processing costs, you can get something like 1.5MiB of data to a client in that window. But the clients and site designs make the target much harder in practice.
1 reply 0 retweets 1 like -
Replying to @slightlylate @lmeyerov and
Most sites I trace that have H/2 enabled *still* have (at least) two critical-path HTTP connections to set up. Assuming 2 connections and a P75-speed device, we cut that 1.5MiB to something like 500K. Each additional connection you need to set up subtracts an additional 50K.
1 reply 0 retweets 1 like -
Replying to @slightlylate @lmeyerov and
That P75 device is likely to have a Snapdragon 625; something like the Redmi S2: https://www.gsmarena.com/xiaomi_redmi_s2_(redmi_y2)-9185.php …
1 reply 0 retweets 1 like -
Replying to @slightlylate @lmeyerov and
P90-concerned sites -- folks that need to reach all users; think budget-market e-commerce, govt sites, etc. -- are on a much tougher budget this time next year. At the margin, networks aren't going to have even 3Mbps; so let's sub in 1.6Mbps as that's "fast 3G" today.
2 replies 0 retweets 1 like -
No caching sounds like broken browsers that can't special case the most common frameworks, and is the p90 a sequence of fully unrelated page views? The snapdragon thing is interesting, but seems similar: modern JS should be be able to lazy load 50KB fast (200ms?)
2 replies 0 retweets 0 likes
Modern frontend practice compiles frameworks into per-site bundles. Caching defeated even if we offered it! It's worse than that, but a deep topic w/ many nuances.
-
-
Replying to @slightlylate @lmeyerov and
On "lazy load", one thing I want to see: does it get "honest" pixels to the user quickly? Critical-path JS puts network in the way. Late long tasks (usually from large scripts and/or "rehydration") delay user input, which breaks UX ("dishonest" pixels; they don't respond).
1 reply 1 retweet 2 likes -
Replying to @slightlylate @lmeyerov and
Smaller bundles help address both effects. And remember, your view framework is a critical dependency unless you architect for progressive enhancement. How lazy can it be, really?
1 reply 0 retweets 1 like - 11 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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.