HTTP 2021

[rviscomi]

Part IV Chapter 24: HTTP

If you're interested in contributing to the HTTP chapter of the 2021 Web Almanac, please reply to this issue and indicate which role or roles best fit your interest and availability: author, reviewer, analyst, and/or editor.

Content team

Lead	Authors	Reviewers	Analysts	Editors	Coordinator
@dominiclovell	@dominiclovell @rmarx	@ibnesayeed @tunetheweb	@tunetheweb	-	@rviscomi

Expand for more information about each role

• The content team lead is the chapter owner and responsible for setting the scope of the chapter and managing contributors' day-to-day progress.
• Authors are subject matter experts and lead the content direction for each chapter. Chapters typically have one or two authors. Authors are responsible for planning the outline of the chapter, analyzing stats and trends, and writing the annual report.
• Reviewers are also subject matter experts and assist authors with technical reviews during the planning, analyzing, and writing phases.
• Analysts are responsible for researching the stats and trends used throughout the Almanac. Analysts work closely with authors and reviewers during the planning phase to give direction on the types of stats that are possible from the dataset, and during the analyzing/writing phases to ensure that the stats are used correctly.
• Editors are technical writers who have a penchant for both technical and non-technical content correctness. Editors have a mastery of the English language and work closely with authors to help wordsmith content and ensure that everything fits together as a cohesive unit.
• The section coordinator is the overall owner for all chapters within a section like "User Experience" or "Page Content" and helps to keep each chapter on schedule.

Note: The time commitment for each role varies by the chapter's scope and complexity as well as the number of contributors.

For an overview of how the roles work together at each phase of the project, see the Chapter Lifecycle doc.

Milestone checklist

0. Form the content team

• May 31: The content team has at least one author, reviewer, and analyst

1. Plan content

• June 15 The content team has completed the chapter outline in the draft doc

2. Gather data

• June 30: Analysts have added all necessary custom metrics and drafted a PR (example) to track query progress

• July 1 - 31: HTTP Archive runs the July crawl

3. Validate results

• September 30: Analysts have queried all metrics and saved the output to the results sheet

4. Draft content

• October 31: The content team has written, reviewed, and edited the chapter in the doc

5. Publication

• November 15: The completed chapter and all required metadata and figures are converted to markdown and submitted to GitHub

• December 1: Target launch date 🚀

Chapter resources

Refer to these 2021 HTTP chapter resources throughout the content creation process:

📄 Google Docs for outlining and drafting content
🔍 SQL files for committing the queries used during analysis
📊 Google Sheets for saving the results of queries
📝 Markdown file for publishing content and managing public metadata

[rviscomi]

Updated this issue to broaden the scope of the chapter to all things HTTP. Open to suggestions for different scopes or chapter names, for example maybe "Network Stack" or similar? @tunetheweb @dotjs any opinions?

[tunetheweb]

Yes I think changing to HTTP is good. That covers the new versions (HTTP/2 and HTTP/3) without having to pick between those. Last two years we were basically in a HTTP/2 world so that name made sense for 2019 and 2020, but we’re quickly becoming an HTTP/3 world so less relevant for 2021.

It also allows covering the semantics of HTTP which are not version specific (e.g. HTTP Headers) - though some of the HTTP semantics are covered by the other chapters like Caching, Compression. I think we’ve basically ignored potentially interesting analysis of how HTTP is used in last few years while we concentrated on the big shiny new vsrsions of HTTP/2 and HTTP/3, so maybe those can be covered to a lesser degree this year and we can get new insights in going back to basics of how HTTP is actually used by websites rather than by how it’s transported?

I don’t think I’d go beyond HTTP to other network stacks though, as think HTTP is big enough and definitely warrants it’s own chapter. That does leave some other related technology that’s not technically HTTP like Web Sockets and, in particular QUIC, but I those can be covered here while keeping the main chapter under the HTTP title. QUIC is basically synonymous with HTTP/3 for now (and might remain like that for some time, at least for the web).

[tunetheweb]

@LPardue could you persuade any of your IETF buddy's to be involved this year? Had quite good expertise in this chapter for last two years (2019 's author aside!) so would be good to continue that, and this is one of only three chapters that's not had any interest shown yet 😞

[rviscomi]

📟 paging 2019/2020 contributors: @tunetheweb @bagder @rmarx @dotjs @paulcalvano @MikeBishop @LPardue @ibnesayeed @pmeenan @Nooshu @gregorywolf

Would any of you be interested to contribute to the 2021 chapter? I'd especially like to see more 2019/2020 authors become 2021 reviewers to help ease the transition and similarly I think prior reviewers would make great 2021 authors, being familiar with the process already. And prior analysts would make excellent 2021 analysts 😁

Or is there anyone new you'd like to see?

[rviscomi]

@dtikhonov you expressed interest in authoring this chapter. Still interested?

[ibnesayeed]

Sign me up as a reviewer, but later I might change my mind to be a co-author for this one or some other chapter, as long as I am not the lead author.

[rmarx]

I'm plenty willing to act as co-author again this year, primarily for the QUIC/H3 part. Reviewer would also be fine.

I agree with a re-name to "HTTP" and a broader focus, but I'm not entirely sure what the "general HTTP" part would do, as I guess the usage of caching-headers, compression or cookies etc. is already discussed elsewhere in the almanac? A part talking about the new "structured fields" approach could be interesting, but probably will have only limited reflection in the tested sites (since IIUC they're only used for new HTTP headers for now?)

I will repeat my point from last year as well, that WebPageTest will need adjustments to properly measure HTTP/3 (and HTTP/2 even!), as browsers can be fickle in how/when they use HTTP/3 (e.g., chrome will sometimes switch part way through the first page load even). So if we want to get anything more than general support stats (e.g., some performance results), then the WPT setup and potentially the entire HTTPArchive pipeline has to be revised for that (e.g., force H2 and H3 separately through command-line args, but that ~doubles run count). We could ignore that and just show results that indicate what first-time visits will look like in practice, but I'm a bit afraid of the picture that will paint and how useful/stable the conclusions might be. CC @pmeenan @tkadlec

[tunetheweb]

I'm not entirely sure what the "general HTTP" part would do, as I guess the usage of caching-headers, compression or cookies etc. is already discussed elsewhere in the almanac? A part talking about the new "structured fields" approach could be interesting, but probably will have only limited reflection in the tested sites (since IIUC they're only used for new HTTP headers for now?)

Some of the things I think we’ve kind of ignored in the past, that aren’t covered by other chapters (at least not completely):

• How many headers used?
• Which headers
• Size of headers (uncompressed, as we talked before about compressed and too difficult)
• Any interesting common but non-standard headers?
• Bad headers (non-ASCII header name for example)
• Any interesting methods/status codes beyond the usual expect (GET/PUT/POST and 200/301/302/404/403)?
• How many redirects does average site make you jump through?
• How many cookies? (Partially covered by Security chapter)
• How about some of the newer headers like Feature-Policy/Permission-Policy/Document-Policy particularly in light of FLOC (though likely covered by Privacy and Security chapters - but never assume a chapter will cover something!).
• What about related, but non-HTTP, technologies (e.g. Web Sockets), Though conscious only home screens if we use the HTTP Archive crawl data.

That’s just some of the things I can think of, off the top of my head. Might be there’s not interesting data in there at all but won’t know until we look.

I will repeat my point from last year as well, that WebPageTest will need adjustments to properly measure HTTP/3 (and HTTP/2 even!), as browsers can be fickle in how/when they use HTTP/3 (e.g., chrome will sometimes switch part way through the first page load even). So if we want to get anything more than general support stats (e.g., some performance results), then the WPT setup and potentially the entire HTTPArchive pipeline has to be revised for that (e.g., force H2 and H3 separately through command-line args, but that ~doubles run count). We could ignore that and just show results that indicate what first-time visits will look like in practice, but I'm a bit afraid of the picture that will paint and how useful/stable the conclusions might be.

I think we should split traffic into old (HTTP/1.1) and new (HTTP/2 and HTTP/3) and then can use the Alt-Svc header to count HTTP/3 support within the new rather than the protocol actually used, for the reasons you give. I presume no site supports h3 but not h2 (though that would be interesting to validate!).

I think the performance benefit shouldn’t be measured through WPT, because of our methodology, because it’s not consistent in which protocol is used (as you say), because it only crawls from USA…etc. Though could be interesting to check very common resources (e.g. Google Analytics or Google Fonts or Facebook pixels) that are used by lots of sites, and should be the same, if we have enough data on both h2 and h3 to see you if any difference in TTFB for example?

Other than that Performance is difficult to measure without a protracted A/B test: https://discuss.httparchive.org/t/what-effect-does-http-2-have-on-the-performance-metrics-of-the-average-website-not-on-a-cdn/1907

BTW happy to be a reviewer and/or analyst for this chapter.

[rviscomi]

@rmarx thanks for your interest in authoring this chapter! As the content team lead, you'll be responsible for the scope and direction of the chapter and keeping it on schedule. We automatically monitor the staffing and progress of each chapter based on the state of the initial comment so please keep that updated as you add new contributors and meet each milestone.

We've created a Google Doc for this chapter, which you're encouraged to use to collaborate with the content team on the initial outline, metrics, and ultimately the final draft.

Next steps for this chapter are:

• Due May 31: Complete Milestone 0: Form the content team—you can check this off now since you've already got at least one author, reviewer, and analyst ✨
• Due June 15: Get started on Milestone 1: Plan content by brainstorming some content ideas in the doc (you may need to request edit access)

There's not currently a section coordinator for this chapter, so I'll be periodically checking in with you directly to make sure the chapter is staying on schedule. Reach out here in this issue if you have any questions about the process.

More information about the content team lead and author roles and responsibilities are available for reference in the wiki if needed.

To anyone else interested in contributing to this chapter, please comment below to join the team!

[rmarx]

Hey @rviscomi,

It seems I wasn't entirely clear about my intentions here, for which I apologize.

While I'm plenty interested in being a co-author for one of the smaller subsections in this chapter (specifically HTTP/3), I sadly can't commit the time necessary to be the lead author/coordinator for this chapter (the high quality of the almanac clearly doesn't just appear out of nowhere ;)).

[rviscomi]

Ah ok sorry for the misunderstanding. I've removed your name from the "lead" role but left you as an author.

Is there anyone you'd nominate to be coauthor and chapter lead?

[rmarx]

I think anyone mentioned above would be great. Additionally, maybe @andydavies would be interested this year?

[dtikhonov]

@dtikhonov you expressed interest in authoring this chapter. Still interested?

@rviscomi, yes, I am, but I do not have the time. Thank you.

[rviscomi]

No worries thanks anyway @dtikhonov!

Could you all help spread awareness about the call for contributors for this chapter by retweeting @tunetheweb's tweet or writing your own tweet? To stay on schedule, the milestone for having a complete content team is due May 31 and it'd be a shame not to have the HTTP chapter this year.

[rviscomi]

Reminder for the content team (@dominiclovell @rmarx @ibnesayeed @tunetheweb @MikeBishop) be sure to request edit access to the HTTP chapter doc if you haven't already. The next milestone (complete the chapter outline) is due on June 15 so please start brainstorming content ideas in the doc. Let me know if you've got any questions.

@dominiclovell you still need to accept our invitation to join the Almanac team so that you can keep the contributors/milestones top comment up to date. Go to https://github.com/HTTPArchive to accept it.

[rmarx]

To pick up some of @tunetheweb's comments from above:

I agree you wouldn't want to do "full" high-level performance comparisons (e.g., Web vitals) between H2 and H3 even if possible. I was mainly thinking about low-level behavior that can impact performance like: comparing handshake durations, 0-RTT/resumption usage, connection coalescing, etc. for these you'd really need repeat views over QUIC/H3, which I'm not sure we have (HTTP Archive site says it only does 3 cold loads)?

If we don't have that type of data, you fall back to rather limited stats, like "how do sites use alt-svc" (btw Barry: how would sites that only support H3 be detected by the browser? You always need H1/2 with alt-svc, at least for now) and "after how long/how much data does Chrome switch from H2 to H3 during the first load (if it does)". Those however don't really highlight any of the exciting new capabilities of the protocol and only allow for limited analysis.

For this year's almanac, we might spice this up by looking at e.g., transport parameter values/H3 settings QUIC servers send back to get an idea of the deployment landscape, but for that we'd have to parse the netlogs (again not sure how do-able that is?)

I again want to try and start the discussion of having to upgrade the HTTP Archive's approach to this in the future, or we will never get the necessary data on H3/QUIC, not in the almanac nor HTTP Archive in general. It's probably too late for this year, but this requires some thought imo. CC @pmeenan @tkadlec

[tunetheweb]

We do three "cold start" loads:

• Mobile
• Desktop
• Lighthouse

As they are cold runs I would be very surprised if any of them used HTTP/3 - except maybe for additional resources (e.g. two connections to Google domains for Analytics and Fonts), and so think we are limited in what we can know of the QUIC/H3 connections - particularly for the site.

Additionally, as per our previous discussion on Twitter browsers (and Chrome in particular as that is what we use) aren't exactly great on documenting the heuristics they use to decide when to use HTTP/3 or not. So I think it's going to be very difficult to force HTTP/3 sites to use HTTP/3 and really think we should just use alt-svc to list support, rather than the protocol used for the test.

btw Barry: how would sites that only support H3 be detected by the browser?

I can't imagine sites doing this as, other than the DNS alt-svc version how would any browser know to connect to them over HTTP/3? And how would they support older browsers? Think we're a long way off this being a viable option for sites.

after how long/how much data does Chrome switch from H2 to H3 during the first load (if it does)

Not sure it does, but even if it does, that seems a Chrome specific thing, and liable to change so not sure in the value of that data (even if we could get it) for this chapter?

I again want to try and start the discussion of having to upgrade the HTTP Archive's approach to this in the future

Given the challenges in measuring this accurately in the lab, we may be better looking at field data here, and in particular blink usage data (nothing in there at the moment so Chrome developers would need to add it, but then can measure stuff like this)and Mozilla Telemetary (which seems to have lots of HTTP/3 counters, including HTTP version).

Sample of HTTP/3 data available in Mozilla Telemetry:

[rviscomi]

🛎️ ping @dominiclovell: please see my earlier comment #2162 (comment) about kicking off the chapter planning and some housekeeping requests. Thanks and let me know if you've got any questions/concerns about the process.

[dominiclovell]

Hey @rviscomi. Can you send through the invite again? It doesn't seem to appear. I've pinged Barry and Robin separately for feedback. I have access to the draft doc, so I can update this more over the next week or so, and have the draft completed before the 15th. Thanks.

[rviscomi]

Just resent it. Thanks for the quick reply!

[ibnesayeed]

I have been busy lately, but now catching up. I have requested access to the docs and will provide feedback about the outline as authors put things together.

[rviscomi]

Hey @dominiclovell, the outline is looking great. Are you still working on it? Or if you're satisfied with it could you check off Milestone 1 above?

And I don't have to tell @tunetheweb about the importance of getting any necessary custom metrics implemented on time 😛

[tunetheweb]

Went through the suggested metrics and made some comments.

So far not seeing anything that would require custom metrics, and didn't need any for last two years so think we'll be fine here.

[rviscomi]

@dominiclovell just following up on my last comment. Is there anything we can do to help get the outline finalized?

[dominiclovell]

Hey @rviscomi I've marked the milestone complete above. After getting feedback from everyone I think the outline is in good shape for us to start gathering the metrics. I've also marked a few comments complete between @rmarx and @tunetheweb, after some back and forth. There are 2 still open, that I'll leave for ongoing discussion for now.

@tunetheweb let me know if you're OK with everything drafted, for the gather data phase.

[tunetheweb]

FYI, the slug (used in the chapter URLs and the like) has been changed from http2 to http to reflect the new chapter names.

The 2019 and 2020 HTTP chapters are still called "HTTP/2" since they concentrated on them, even if the URL is just /http now.

This years chapter will be called "HTTP". Might be nice to make a reference to the name change in the chapter, depending how much non-HTTP/2 stuff we cover (I presume a good bit on HTTP/3 at least!).

[tunetheweb]

@dominiclovell / @rmarx , Will try my best to finish out the queries tomorrow and get them run. Had a few other things on my plate but not forgotten about you! Will let you know when done.

[rviscomi]

👋 Hi @dominiclovell @rmarx @tunetheweb, just checking in on the chapter progress. How is the analysis coming along?

[dominiclovell]

Hey @rviscomi, I've reviewed some of Barry's updates. I'll need to sync with Robin, but no concerns at this stage.

[tunetheweb]

@dominiclovell @rmarx @ibnesayeed I've run all the queries and placed the results here:
https://docs.google.com/spreadsheets/d/1pCdpndXTXexSIZLmVc-aUbp5PcHhZ83hbEEfmDyfD0U/edit#gid=2077755325

I've added a few visualisations for some of the stats, but can add more as needs be.

Can you start reviewing the data while we wait for the pull request #2309 to be reviewed by other analysts?

I've also created a web-almanac-http channel on HTTP Archive Slack and can answer any questions there.

[tunetheweb]

Hey @dominiclovell just checking you've seen the message above and are aware the stats are there ready for your review?

[domakamai]

Thanks @tunetheweb. Let me work with @rmarx on the next steps.

[tunetheweb]

Hey @domakamai /@rmarx just checked the doc and see loads of content there. Great stuff!

I’ve not had a chance to read it (it’s late here so will save that for a fresh head tomorrow!) but did see a few comments about figures and graphs. As your analyst, I can work on those over the next few days to help get you want you need.

[rviscomi]

@dominiclovell @rmarx @ibnesayeed @tunetheweb

🎉 This chapter is fully written, reviewed, edited, and ready to be launched on Wednesday! Thank you to all of the contributors who put in the time and effort to make this a great chapter.

When you get 5 minutes, I'd really appreciate if you could fill out our contributor survey to tell us (the project leads) about your experience. It's super helpful to hear what went well or what could be improved for next time. 🙏

Congratulations and thank you all again. I'm excited for this to launch soon!