Please share!
-
-
Replying to @simonhearne
1.) `font-display: optional` 2.) Perf Budgets (e.g., via Lighthouse CI) 3.) Workers (e.g., via Comlink) 4.) CSS Custom Paint (off-thread in '20) & Animation Worklet (w/ Scroll Timeline) 5.) SW-based MPA architecture (content stitching w/ streams) 6.) 4G penetration (yes, 4G!) ...
3 replies 2 retweets 8 likes -
Replying to @slightlylate @simonhearne
7.) Feature Policies for control (e.g., via Never-Slow Mode) 8.) Observability & feedback (on your list) 9.) Anaheim (Chromium-based Edge) killing polyfill bloat 10.) CSS features replacing JS libraries (no JS for, e.g., carousels) 11.) Bonus! Sequestering JS to the server-side.
1 reply 1 retweet 1 like -
Replying to @slightlylate @simonhearne
Others will have impact on fewer (but more heavily used) sites, e.g., better understanding and use of Service Worker code caching optimisations. Some have played out in '19 w/ too little fanfare; notably layout for non-latin text and JS parse speed improvements.
1 reply 0 retweets 0 likes -
Replying to @slightlylate
All good points! In terms of crystal ball big shifts in web perf - SW.js, Lighthouse CI, removing polyfills, updating carousels etc. all require effort for _every_ site to improve. I wonder what % of sites changed 0 LOC in 2019.
2 replies 0 retweets 0 likes -
Replying to @simonhearne @slightlylate
Developer inertia is a big challenge with web performance, not because of lack of drive or knowledge. Companies constantly prioritise features over speed. An advantage shared by JAMstack, WASM (& workers), Edge & Web Monetisation is that they're new & shiny. Maybe = investment.
1 reply 0 retweets 0 likes -
Replying to @simonhearne
Alex Russell Retweeted Rick Byers
Shiny gets too much play as an incentive. See:https://twitter.com/RickByers/status/1199384180632764417?s=20 …
Alex Russell added,
Rick Byers @RickByersWhen Google Search started using speed as a (very small) ranking signal, they saw a 15%-20% improvement in perf metrics and a 20% reduction in page abandonment: https://webmasters.googleblog.com/2019/04/user-experience-improvements-with-page.html …. This is huge! One of the key studies which drives our performance strategy in Chrome.Show this thread1 reply 0 retweets 0 likes -
Replying to @slightlylate
Yup and I think that might be because there is more budget for technical SEO than web perf in the average org:https://simonhearne.com/2019/2020-predictions/#4---observability …
1 reply 0 retweets 1 like -
Replying to @simonhearne @slightlylate
We need to stop treating WebPerf as a technical problem and start treating it as business problem… Until then it's always going to play second fiddle to shiny
1 reply 2 retweets 22 likes -
Agreed. No one cares about security/accessibility until after they’ve been hacked/sued; until it’s hit them right in the business. Because poor perf never really culminates in anything so drastic, most businesses don’t care. Ergo needs reframing from the outset.
1 reply 0 retweets 2 likes
I've seen perf cause drastic business failure, but like getting pwn'd, nobody talks about it because it's embarrassing. Doubly so because you do it *to yourself*. In the dysfunctional orgs, folks even get promoted for fixing se of what their (much anticipated!) launch breaks.
-
-
Right. But it’s never (or rather, very very rarely) big-bang failure. It’s usually a slow and painful demise.
1 reply 0 retweets 1 like -
I spoke to the CTO of a large company today (~50 brands) who knew that one of their key landing pages took 32s to load, but had never seen a waterfall chart. No one knew why it took 32s
I'm really not sure how to fix that (at scale)3 replies 0 retweets 3 likes - 5 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.