programmingart.bsky.social
Network protocols (HTTP/2, HTTP/3, QUIC) and Web performance
at Akamai. PhD. Dad. Longsword fencer. He/Him.
http://linkedin.com/in/rmarx
@[email protected]
29 posts
1,043 followers
209 following
Regular Contributor
Active Commenter
comment in response to
post
Featured posts this week:
⚡ Fast and furious: @catchpointsystems.bsky.social
⚡ How browsers REALLY load Web pages: @programmingart.bsky.social
⚡ Client-Side Rendering: @adevnadia.bsky.social
⚡ More Edge features get a perf boost: Mohamed Mansour
Special thanks to the authors.🙏
comment in response to
post
The "contributing" options on the web.dev bottom for example don't seem quite as inviting as say github.com/mdn/content, which imo helps reinforce the impression this is a google/chromium-first thing.
(just trying to provide some feedback on why I had my initial impressions on web.dev)
comment in response to
post
Arguably, you can't expect Chrome engineers to add non-chromium behaviours in there, but it's also unclear (at least to me on the outside looking in) if you would accept contributions from say Firefox/Safari/outsiders to extend that type of article with cross-browser content (it's already extensive)
comment in response to
post
Good to know this is the intent (as @paul.kinlan.me also echoed), but from my perspective, web.dev articles that talk about the type of topics I research, are usually still exceptionally chromium-focused, even for features in baseline (prime example being web.dev/articles/fet...).
comment in response to
post
Thanks Patrick. I would definitely be interested in contributing docs, I'm just not sure where they would fit best. Web.dev is traditionally google/chromium-focused and not sure if they'd want to change. MDN doesn't seem to do much of this more "fuzzy" content in my experience, but maybe I'm wrong?
comment in response to
post
Sadly yes... Dinner date with the wife I'm afraid
comment in response to
post
It was just bit.ly/loadline :)
comment in response to
post
Let's hope we can re-invigorate that then :) Thanks for sharing!
comment in response to
post
Hmz that's indeed much lower than I would have expected... Maybe @tunetheweb.com can have a look once he's less busy? 😇
comment in response to
post
But as a percentage of all sites that use preload (the ~2.5 million):
235,535 / 2,506,138 = 0.09 = 9%
228,895 / 2,506,138 = 0.09 = 9%
so about 18% combined (round up to say 20% for the leftovers that uselessly preload more than 2 resources).
Hope that helps :)
comment in response to
post
Hm, I think it's more like 20% :) Looking at the raw results (docs.google.com/spreadsheets...).
2,506,138 used preload (~20 of all desktop homepages)
235,535 has 1 unused preload (~1.9% of all desktop homepages)
228,895 has 2 unused preloads (~1.85% of all)
Combined <4% of total (as reported)
comment in response to
post
MASSIVE thank you to @tunetheweb.com, without whom there would have been no data to write about in the first place!
Barry is consistently one of the kindest and most hardworking people in #webperf (and beyond) and deserves our gratitude!
comment in response to
post
The HTTP chapter was written by @programmingart.bsky.social and being our first name, is a subject close to our heart 😀
almanac.httparchive.org/en/2024/http
Read it for lots of fascinating deep dive into to how web resources are delivered and the latest on how developers can influence that!
comment in response to
post
Not that I know of no... Would actually be quite interesting to have that as a signal imo... @tunetheweb.com @patmeenan.com
comment in response to
post
It's Fastly and QUIC.cloud, as detailed in the paper linked on the bottom of that slide: jherbots.info/public_media...
Note that this is only for HTTP/3. I also have some tests for HTTP/2 (which is still equally broken on some servers) but haven't made anything public for that yet.
comment in response to
post
1. Yeah, could be, didn't really dig super-deep into this one yet because it felt so inconsistent.
2. this was actually SO MUCH HARDER THAN IT LOOKS. I was practicing in my hotel room all night before... luckily I think @guaca.bsky.social has some skills here, so you can book us as a double act ;)
comment in response to
post
Here, I think Safari just falls back to normal tight mode logic: it's still in tight mode, but there's just 1 high-prio resource in flight (the 3rd CSS that's slow to load), so it starts loading low-prio stuff, but only 1 at a time.
I don't think this is a special case due to stylesheets.
comment in response to
post
Probably also of interest to @tunetheweb.com (thanks again for the photoshoot Barry!), @csswizardry.com, @twnsnd.com, @yoav.ws, and @imkev.dev, who's one of the few people who actually researched this topic as well (imkev.dev/fetchpriorit...)
comment in response to
post
This talk is complementary to my talk at @perfnow.bsky.social last year 👇 on resource prioritization, where I didn't have time to fit in the "tight mode" details (they were enough for a whole new talk by themselves!)
Big thanks to @patmeenan.com in particular for all his help (and work!) on this.
comment in response to
post
These differences can be quite stark, such as in the screenshot below, where 1 simple Web page is loaded completely differently in the 3 main browsers... This means it's difficult to build pages that perform consistently well across them, and features like fetchpriority and preload don't help much 🤡
comment in response to
post
Finally, to add credence to others here seeing high iOS usage: I help curate www.rumarchive.org, which aggregates real user data from top Akamai customers worldwide. Our traffic leans heavily towards iOS (61%) with webkit-browsers accounting for 51%+ of all requests (rumarchive.com/insights/#os...)
comment in response to
post
People focus too much on just optimizing for Chromium right now, assuming good results there automatically transfer over to safari/webkit, but with no way to really validate. This all to help you answer "why are numbers for one browser not enough?": because you can't extrapolate between them.
comment in response to
post
My expertise is in networking (protocols, resource download scheduling and prioritization) and I've found many cases of low-level differences between browsers that are undocumented and hard to diagnose (some examples here: youtu.be/MV034VqHv5Q?...).
comment in response to
post
Yes please :) Despite the browsers implementing the same "standards" there are still many differences in concrete implementations/heuristics employed and not everything is standardized. Something working well on one browser engine might perform terribly on another due to this.