Skip to content
HomeVideosBooksBlogs
AllTop postsTopics
Podcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K
    I

    Insouciant

    insouciant.org · Personal blog · on HN since 2012

    Insouciant is the blog of Will Chan, a Chromium developer, covering web performance, HTTP/2, SPDY, TCP congestion and browser networking.

    Visit blogHN submissions
    NetworkingWeb DevelopmentSystems & Performance
    What HN says

    HN commenters cite it as a good explanation of HTTP pipelining and congestion from many TCP connections, and use it in HTTP/2 and QUIC debates.

    Stats for nerds
    20HN people shared it
    13linked in comments
    284story points
    Jul 2017last shared
    2012people per year2017

    Top posts on HN

    1. 1
      Back to SF After the U.S. Digital Service
      1 person · 164 points · first shared 2015 · 160 comments on HN
    2. 2
      SSL Performance Case Study
      2 people · 52 points · first shared 2012 · 1 comments on HN
    3. 3
      HTTP/2 Considerations and Tradeoffs
      4 people · 43 points · first shared 2014 · 3 comments on HN
    4. 4
      Network Congestion and Web Browsing
      4 people · 9 points · first shared 2013 · Discussion on HN
    5. 5
      Prioritization Only Works When There's Pending Data to Prioritize (2014)
      3 people · 7 points · first shared 2015 · Discussion on HN
    6. 6
      Status of HTTP pipelining in Chromium
      4 people · 3 points · first shared 2013 · Discussion on HN
    7. 7
      Connection Management in Chromium
      2 people · 2 points · first shared 2013 · Discussion on HN
    8. 8
      LocalStorage DB size and load times in Chrome
      1 person · 2 points · first shared 2013 · Discussion on HN
    9. 9
      GMail web performance optimisation actually slower.
      1 person · 2 points · first shared 2013 · Discussion on HN
    10. 10
      Prioritization is critical to spdy
      1 person · first shared 2013

    What HN people wrote when they linked it

    • rektideMay 2013

      At least if you're going to dive into the transport layer, pick a capability that hasn't been added and then unceremoniously backed out-
      https://insouciant.org/tech/status-of-http-pipelining-in-chromium/

      SPDY begins to offer some very appealing alternatives where when sending a document the transport can push all of the individual dependent documents. It really does fix things, begins pushing all the data at once, in a glorious resource-oriented fashion. That said, I would also enjoy a spec that does resource-description of subresources so we can send linked data around without having to have every piece of data be an endpoint.

      That said, the immediate follow on question arises- now that we're sending sub-resources, can we get the most important agent to understand and grok our sub-resources- can the browser follow our subresourcing and those subresources to their canonical URLs, and serve those subresources if it's seen them inside another document? There are two questions- first, is your spec good enough to enable that facility where addressing can be well known- here, in this Json Resource Description spec presented yes, via URI templates, very good- and second, does the browser bother to inspect the JSON it sees? No? Well, I'm not super bothered by this academic interest not being materialized, knowing at least in principle the specs make it possible.

    • akalinJul 2013

      I didn't have to look hard to find bug reports for pipelining. An example is https://bugs.launchpad.net/ubuntu/+source/apt/+bug/948461 for Amazon's S3. I'd be interested if the problem is still reproducible now. Also, one of the comments mentions Squid 2.0.2 as being buggy.

      Also, see https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ for a link to Firefox's blacklist of buggy servers (and a good discussion of pipelining in Chromium).

      Most of the improvements in SPDY are latency improvements, so if you're downloading sites with netcat and then viewing them in a browser, I'm pretty sure the overhead of that would dwarf anything SPDY would save. That having been said, there's ample evidence of SPDY improving things. From http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines-for-firefox.html :

      "Also see telemetry for TRANSACTION_WAIT_TIME_HTTP and TRANSACTON_WAIT_TIME_HTTP_PIPELINES - you'll see that pipelines do marginally reduce queuing time, but not by a heck of a lot in practice. (~65% of transactions are sent within 50ms using straight HTTP, ~75% with pipelining enabled).... Check out TRANSACTON_WAIT_TIME_SPDY and you'll see that 93% of all transactions wait less than 1ms in the queue!"

    • acdhaSep 2015

      That would apply but it's somewhat odd to see the tone of surprise for something which has been widely mentioned as an optimization-turned-antipattern for SPDY or HTTP/2 since at least 2012 or so. I believe at least Chrome has also optimized so addresses which share the same IP (or SSL cert?) will be collapsed into the same existing connection rather than opening new ones.

      Opening all of those connections is also something of an anti-pattern even for HTTPS depending on how much data you're exchanging relative to the SSL handshake cost – see e.g.:

      https://insouciant.org/tech/network-congestion-and-web-browsing/#Google_Kitten_Search

    • morecoffeeJul 2017

      While I agree QUIC is a better long term solution[1], saying TCP ordering affects HTTP/2 is misleading. It is true, but it is quite easy to avoid bad behavior by using TCP_NOTSENT_LOWAT (also created by Google), to avoid HoL blocking. For example, SPDY had a similar problem which was ameliorated by only sending when the water mark is low enough:

      https://insouciant.org/tech/prioritization-only-works-when-theres-pending-data-to-prioritize/

      [1] https://news.ycombinator.com/item?id=12282898

    • justinschuhJan 2013

      This was on HN eight months ago, when the post was actually made. And the takeaway is pretty clear, you probably won't see a benefit in using SPDY in front of a site optimized in ways that don't take advantage of SPDY's strengths. If you want to see big improvements with SPDY (like Google does) then you need to adjust how you're serving your resources. Resource prioritization is a perfect example of this: https://insouciant.org/tech/prioritization-is-critical-to-spdy/

    • hobohackerDec 2012

      I see, so your main point really is that you don't think the new features proposed in HTTP/2.0 are worth the change in wire representation.

      Prioritization:
      Generally speaking, documents (HTML) > script/stylesheets (JS&CSS) > subresources (e.g. images).
      https://insouciant.org/tech/resource-prioritization-in-chromium/
      https://insouciant.org/tech/throttling-subresources-before-first-paint/

    Related

    Patrick McManusbitsup.blogspot.com32 people

    Google fixes nearly decade-old Linux kernel TCP bug

    Patrick McManus
    Personal · last shared 2020
    Interconnectedinterconnected.blog22 people

    Why Is Facebook Not in the Cloud Business?

    Interconnected
    Personal · last shared 2026
    Mike Belshebelshe.com24 people

    SPDY of the Future Might Blow Your Mind Today

    Mike Belshe
    Personal · last shared 2013
    Nolan Lawsonnolanlawson.com133 people

    Safari is the new IE

    Nolan Lawson
    Personal · last shared 2026
    Cilium Blogcilium.io47 people

    eBPF – The Future of Networking and Security

    Cilium Blog
    Company · last shared 2026
    swyxswyx.io120 people

    AWS is playing chess, Cloudflare is playing Go

    swyx
    Personal · last shared 2026
    Cloudflare Blogblog.cloudflare.com2.9k people

    We Stood Up to a Patent Troll and Won

    Cloudflare Blog
    Company · last shared 2026
    APNIC Blogblog.apnic.net253 people

    Internet protocols are changing

    APNIC Blog
    Company · last shared 2026