fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-23 21:02:09 +00:00
Code Issues Projects Releases Wiki Activity

Compare commits

base: fmaury:a4812c72c967d2998adecc8ff4f09747685724e5
Branches Tags
fmaury:master
fmaury:draft-searchengines
...
compare: fmaury:13a443559734f8cf5a86b9d518c82a7ae12d5817
Branches Tags
fmaury:master
fmaury:draft-searchengines

3 commits
a4812c72c9 ... 13a4435597

Author SHA1 Message Date
Rohan Kumar
13a4435597
Correction around TCP window size 
Distinguish between the data in the first round-trip and the data in the
first packet; they are not the same.
 2022-09-12 10:22:03 -07:00
Rohan Kumar
6d034c180d
typo 2022-09-12 10:21:18 -07:00
Rohan Kumar
f23d8faa3d
New note: water use infographic 2022-09-12 10:14:03 -07:00
3 changed files with 29 additions and 6 deletions
Show stats Expand all files Collapse all files

19
content/notes/re-water-usage-infographic.md Normal file
View file

@ -0,0 +1,19 @@
---
title: "Re: water usage infographic"
date: 2022-09-12T10:14:03-07:00
replyURI: "https://akkos.fritu.re/notice/ANUcbQMnRMMTgaE9fU"
replyTitle: "The amount of water other food need to produce 1kg of food"
replyType: "SocialMediaPosting"
replyAuthor: "Fristi"
replyAuthorURI: "https://comfitu.re/"
---
I have mixed feelings about infographics that reduce ecological footprints to single scalar non-fungible values.
Infographics like these should have a second metric for "average rainfall in areas producing required ingredients", since water isn't fungible. Chocolate wouldn't look as bad then.
And a third metric for fuel required to import the food and ingredients during production. Chocolate would look bad again, since it's typically produced far away from where cacao grows. Maybe this should be generated based on a viewer's approximate location, to better account for shipping.
Also, this infographic ignores serving size by measuring the same mass of all these different foods. I'm not sure who buys equal masses of chocolate and rice.
([Original infographic source](https://www.tromsite.com/books/#flipbook-df_6707/34))

8
content/posts/website-best-practices.gmi
View file

@ -244,9 +244,9 @@ A supplementary metric to use alongside download size is round trips. Estimate t
Understanding round-trips requires understanding your server's approach to congestion control.
Historically, TCP congestion control approaches typically set an initial window size to ten TCP packets and grew this value with each round-trip. Under most setups, this meant that the first round-trip could include 1460 bytes. The following round-trip could deliver under three kilobytes.⁷
Historically, TCP congestion control approaches typically set an initial window size to ten TCP packets and grew this value with each round-trip. Under most setups, this meant that the first round-trip could include 14.6 kilobytes. The following round-trip could deliver under thirty kilobytes.⁷ Try to ensure that all non-markup blocking resources and your document's "<head>" fit within this 14.6 kilobyte budget.
Nowadays, servers typically employ BBR-based congestion control. It allows for regular "spikes" in window size, but the initial window size is still small.
Nowadays, servers employ BBR-based congestion control. It allows for regular "spikes" in window size, but the initial window size is still small.
=> https://labs.apnic.net/presentations/store/2019-09-05-bbr.pdf "TCP and BBR" slides from APNiC (PDF)
@ -254,7 +254,9 @@ HTTP/3 uses QUIC instead of TCP, which makes things a bit different; the importa
### The golden kilobyte
Assume that your first impression must fit in the first kilobyte. Make good use of this golden kilobyte; most or all of it will likely be taken up by HTTP headers.⁹ Ideally, the first kilobyte transferred should inform the client of all blocking resources required, possibly using preload directives; all of these resources can then begin downloading over the same multiplexed HTTP/2 connection before the current round-trip finishes! Note that this works best if you took my earlier advice to avoid third-party content.
One of the benefits of HTTP/2 and HTTP/3 is multiplexing: multiple resources can download over a single connection. Try to initiate downloads for blocking resources as soon as possible.
A TCP packet is 1460 bytes. Your first TCP packet will be partly taken up by a stapled TLS certificate, leaving you with under one kilobyte to work with. Make good use of this golden kilobyte; most or all of it will likely be taken up by HTTP headers.⁹ Ideally, the first kilobyte transferred should inform the client of all blocking resources required, possibly using preload directives; all of these resources can then begin downloading over the same multiplexed HTTP/2 connection before the current round-trip finishes! Note that this works best if you took my earlier advice to avoid third-party content.
Apply these strategies in moderation. Including extra preload directives in your document markup might not help as much as you think, since their impact on page size could negate minor improvements. Micro-optimizations have diminishing returns; past a certain point, your effort is better spent elsewhere.

8
content/posts/website-best-practices.md
View file

@ -267,15 +267,17 @@ A supplementary metric to use alongside download size is round trips. Estimate t
Understanding round-trips requires understanding your server's approach to congestion control.
Historically, TCP congestion control approaches typically set an initial window size to ten TCP packets and grew this value with each round-trip. Under most setups, this meant that the first round-trip could include 1460 bytes. The following round-trip could deliver under three kilobytes.[^6]
Historically, TCP congestion control approaches typically set an initial window size to ten TCP packets and grew this value with each round-trip. Under most setups, this meant that the first round-trip could include 14.6 kilobytes. The following round-trip could deliver under thirty kilobytes.[^6] Try to ensure that all non-markup blocking resources and your document's `<head>` fit within this 14.6 kilobyte budget.
Nowadays, servers typically employ BBR-based congestion control. It allows for regular "spikes" in window size, but the initial window size is still small. Find more details in the slides from <span class="h-cite" itemprop="citation" itemscope="" itemtype="https://schema.org/PresentationDigitalDocument"> <cite class="p-name" itemprop="name headline" ><a class="u-url" itemprop="url" href="https://labs.apnic.net/presentations/store/2019-09-05-bbr.pdf">TCP and BBR</a></cite> (<span itemprop="encodingFormat">application/<wbr />pdf</span>) by {{<indieweb-person first-name="Geoff" last-name="Huston" itemprop="author" url="https://www.potaroo.net/" org="APNiC" org-url="https://www.apnic.net/">}}</span>.
Nowadays, servers employ BBR-based congestion control. It allows for regular "spikes" in window size, but the initial window size is still small. Find more details in the slides from <span class="h-cite" itemprop="citation" itemscope="" itemtype="https://schema.org/PresentationDigitalDocument"> <cite class="p-name" itemprop="name headline" ><a class="u-url" itemprop="url" href="https://labs.apnic.net/presentations/store/2019-09-05-bbr.pdf">TCP and BBR</a></cite> (<span itemprop="encodingFormat">application/<wbr />pdf</span>) by {{<indieweb-person first-name="Geoff" last-name="Huston" itemprop="author" url="https://www.potaroo.net/" org="APNiC" org-url="https://www.apnic.net/">}}</span>.
HTTP/3 uses QUIC instead of TCP, which makes things a bit different; the important thing to remember is that _user agents should be aware of all blocking resources **before** finishing the earliest possible round-trip._
### The golden kilobyte
Assume that your first impression must fit in the first kilobyte.[^7] Make good use of this golden kilobyte; most or all of it will likely be taken up by HTTP headers.[^8] Ideally, the first kilobyte transferred should inform the client of all blocking resources required, possibly using preload directives; all of these resources can then begin downloading over the same multiplexed HTTP/2 connection before the current round-trip finishes! Note that this works best if you took [my advice to avoid third-party content](#third-party-content).
One of the benefits of HTTP/2 and HTTP/3 is multiplexing: multiple resources can download over a single connection. Try to initiate downloads for blocking resources as soon as possible.
A TCP packet is 1460 bytes. Your first TCP packet will be partly taken up by a stapled TLS certificate, leaving you with under one kilobyte to work with.[^7] Make good use of this golden kilobyte; most or all of it will likely be taken up by HTTP headers.[^8] Ideally, the first kilobyte transferred should inform the client of all blocking resources required, possibly using preload directives; all of these resources can then begin downloading over the same multiplexed HTTP/2 connection before the current round-trip finishes! Note that this works best if you took [my advice to avoid third-party content](#third-party-content).
Apply these strategies in moderation. Including extra preload directives in your document markup might not help as much as you think, since their impact on page size could negate minor improvements. Micro-optimizations have diminishing returns; past a certain point, your effort is better spent elsewhere.