I like to think we have a lean, mean engine here in WebKit. Actually the most lean-n-mean.
Do your frustrations apply to us too or is this Mozilla-specific? Have I missed some context? Are we talking evangelism or engine work here?
-
-
Replying to @johnwilander @googlechrome
I like me some modern
@webkit! More of that, less of the other ;-)1 reply 0 retweets 1 like -
OK, we’ll focus on modern rather than legacy then. But let’s talk mobile web in emerging markets. I get the push for offline and more device APIs. But where are we on: 1) Power consumption? 2) Data consumption? 3) Safety of non-curated apps? 4) UI consistency? 5) Accessibility?
2 replies 0 retweets 2 likes -
Power: hard (both to measure and control). Data: web often the winner; PWAs are frequently a (tiny) fraction the size. Safety: web sandbox beats unlatched Android! Consistency: it's an open platform. a11y: not as good
1 reply 0 retweets 0 likes -
Power: Hard problems need love too. Could we come up with something? Data: If we could agree on incentives we could probably shave it down significantly. Safety: I don’t know enough about Android curation. Especially not outside Google Play Store.
3 replies 0 retweets 0 likes -
On Data, we're looking at incentives. I've often advocated for a "slow script warning", but for heavy content (coupled to the Reporting API). Search moving to real-world speed rankings will also help: https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html …
2 replies 0 retweets 1 like -
Let’s play with the idea of hard incentives for a moment. Imagine an opt-in setting “Block data heavy websites” with clear limits that developers can adapt to. Where would that take us? We could have a similar opt-in block for sites with poor accessibility.
1 reply 0 retweets 0 likes -
Replying to @johnwilander @slightlylate and
Knowing which sites are light and have good accessibility could probably be automated for the popular web but browsers could stop loading when a certain condition is not met.
2 replies 0 retweets 0 likes -
Browsers are one part of the equation. It's also important for big traffic sources to prefer lighter content and direct to them. Chrome's User Experience Report data can help:https://developers.google.com/web/tools/chrome-user-experience-report/ …
1 reply 0 retweets 0 likes -
Replying to @slightlylate @johnwilander and
The thing to optimise around is the idea that "clicking a link shouldn't cost a lot". That can be in CPU (and battery), bandwidth, or annoyance. There's a legitimate tension with capabilities here, but that's why they pay us to balance them = )
1 reply 0 retweets 1 like
A few idea: - Refuse to load resources that don't send Content-Length - Refuse to load scripts larger than some amount (250KB?) w/o interaction - Prompt user to cancel/continue (w/ reporting to site) over some total size - A header that advertises user-set size budget
-
-
Replying to @slightlylate @johnwilander
Scripts are by far the most visible-latency inducing asset class; throttling them harder seems better.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Replying to @slightlylate
We should absolutely see if this is possible.
0 replies 0 retweets 0 likes - 7 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.