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
    M

    Mike Belshe

    belshe.com · Personal blog · on HN since 2010

    Mike Belshe, a co-creator of SPDY, writes about web protocols, latency, SSL and browser performance.

    Visit blogHN submissions
    NetworkingWeb DevelopmentSystems & Performance
    What HN says

    HN cites his 'More Bandwidth Doesn't Matter (Much)' post on latency and his rebuttal to Microsoft's SPDY proposal; one commenter questions SPDY's mobile benchmarks.

    Stats for nerds
    24HN people shared it
    16linked in comments
    208story points
    Jul 2013last shared
    2010people per year2013

    Top posts on HN

    1. 1
      SPDY of the Future Might Blow Your Mind Today
      2 people · 97 points · first shared 2011 · 27 comments on HN
    2. 2
      Followup to “Not as SPDY as You Thought”
      2 people · 43 points · first shared 2012 · 5 comments on HN
    3. 3
      Comments on Microsoft's SPDY Proposal
      5 people · 18 points · first shared 2012 · 1 comments on HN
    4. 4
      The Web only Works Thanks to Reload… (and why the mobile web fails)
      2 people · 18 points · first shared 2012 · 8 comments on HN
    5. 5
      Rethinking SSL for Mobile Apps
      3 people · 11 points · first shared 2012 · 4 comments on HN
    6. 6
      SSL: It’s a Matter of Life and Death
      1 person · 11 points · first shared 2011 · 2 comments on HN
    7. 7
      IPv6 Will Slow You Down (DNS) « Mike's Lookout
      1 person · 3 points · first shared 2011 · Discussion on HN
    8. 8
      Google Chrome - Velocity 2011 (talk by mikebelshe)
      1 person · 2 points · first shared 2011 · Discussion on HN
    9. 9
      No Political Efficiency since 1913
      1 person · 2 points · first shared 2010 · Discussion on HN
    10. 10
      Speeding up Google Chrome presentation at Velocity 2010
      2 people · 1 points · first shared 2010 · Discussion on HN

    What HN people wrote when they linked it

    • projctMar 2012

      It seems to work fine here (iPhone 4, iOS 5.1), and I've not had a problem with g+ on 4.3.x or 5.0.[01], AT&T and various Wi-Fi networks...

      Is it really endlessly redirecting or perhaps timing out and trying to reload? I had that happen once when latency was extreme, on one occasion.

      EDIT: here is the text for those who are having trouble.

      Host resolution accounts for a significant portion of the networking component of page load time. As such, Chromium developers are always looking to optimize it. Here I present the current considerations of host resolution in Chromium, and look forward to the IPv4+IPv6 dual stack world and what that entails for browsers (and what Chromium is doing about it). I finish off with a presentation of some of the latest data we're operating on.

      Currently, Chromium uses getaddrinfo() to ask the OS to resolve a host. This is a cross-platform, blocking API that abstracts the complicated host resolution. There are a number of advantages to using this API:
      * Correctness - it handles all the complicated rules of hostname lookup correctly. It understands /etc/hosts, non-DNS namespaces like NetBIOS/WINS, etc. Re-implementing this behavior would be difficult.
      * OS Caching - we get to share the OS host cache with other applications. Note that this doesn't exist by default on Linux systems.
      * Less code - Having to maintain code sucks. It leads to code/binary bloat and endless bugs for corner cases and OS-specific issues. And it takes engineering…

    • ddeckJul 2013

      > I remember the Chrome timer code of years ago was careful to only adjust the interval when needed. From reading other bugs it looks like today's behavior is an accidental regression and will likely be fixed (until the next time it regresses).

      Indeed, although it seems the current behavior has been oustanding for some time:

      https://code.google.com/p/chromium/issues/detail?id=153139

      The original justification for lowering the resolution is an interesting read:

      At one point during our development, we were about to give up on using the high resolution timers, because they just seemed too scary. But then we discovered something. Using WinDbg to monitor Chrome, we discovered that every major multi-media browser plugin was already using this API. And this included Flash, Windows Media Player, and even QuickTime. Once we discovered this, we stopped worrying about Chrome's use of the API. After all – what percentage of the time is Flash open when your browser is open? I don't have an exact number, but it's a lot. And since this API effects the system globally, most browsers are already running in this mode.[1]

      [1] http://www.belshe.com/2010/06/04/chrome-cranking-up-the-clock/

    • onecreativenerdJul 2010

      You might be right. I considered that, but it doesn't have as much of an impact factor on the user, which is really important for getting the word out about performance (why the site exists in the first place).

      I probably doesn't matter too much as long as you have a ~3Mbps connection or higher (see Mike Belshe's "Effective Bandwidth of HTTP" graph on http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/) because the TCP transmission rate can't ramp up high enough on each object to saturate the connection. It's possible, however that the objects will interact with each other by causing differing queueing latency and possibly loss in the bottleneck router and by changing the order of scheduler events on the client OS. Also, it may be better subject the two pages to the same network conditions (at least in the last mile) while they're loading, esp. on mobile.

    • 0xABADC0DAMay 2012

      https://developers.google.com/speed/articles/spdy-for-mobile

      - doesn't include DNS lookup times

      - doesn't include packet loss

      - doesn't compare to pipelining

      First two mean the claimed speedup isn't measuring the whole real time. Third is just amazing... the stock Android browser even uses pipelining. Basically pipelining gives the same benefits as Spdy and they really, really don't want to admit this.

      http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy-proposal/

      This is what I'm talking about... every one of Microsoft's changes he identifies as b-h is a positive change. That he can't see it I guess is a testament to being young and inexperienced.

    • gmurphyJul 2010

      This is why Chrome has built-in silent autoupdate - the vast majority of our users are on the a new version within a week of releasing it.

      See graphs:
      http://www.belshe.com/test/velocity2010/#slide38.0

      The shallow curve is our development and beta channel users, the steep part of the curve is when we release a stable version. Previous slides show known update rates for other browsers.

    • albertzeyerJul 2010

      Here is the graph. The site sucks pretty bad (seems to require a very high resolution and has disabled scrollbars).

      http://www.belshe.com/test/velocity2010/chrome_version_migration.png
      http://www.belshe.com/test/velocity2010/firefox_version_migration.png
      http://www.belshe.com/test/velocity2010/ie_version_migration.png

    Related

    Guy Podjarnyguypo.com25 people

    Not as SPDY as You Thought

    Guy Podjarny
    Personal · last shared 2015
    Cloudflare Blogblog.cloudflare.com2.9k people

    We Stood Up to a Patent Troll and Won

    Cloudflare Blog
    Company · last shared 2026
    Bluesky Blogblueskyweb.xyz82 people

    A self-authenticating social protocol

    Bluesky Blog
    Company · last shared 2024
    Troy Hunttroyhunt.com681 people

    Thanks FedEx, this is why we keep getting phished

    Troy Hunt
    Personal · last shared 2026
    Aphyraphyr.com551 people

    Hexing the technical interview (2017)

    Aphyr
    Personal · last shared 2026
    Ilya Grigorikigvita.com177 people

    Chrome DevTools could do that?

    Ilya Grigorik
    Personal · last shared 2026
    Mike Hearnblog.plan99.net86 people

    It’s time to kill the web app

    Mike Hearn
    Personal · last shared 2026
    Patrick McManusbitsup.blogspot.com32 people

    Google fixes nearly decade-old Linux kernel TCP bug

    Patrick McManus
    Personal · last shared 2020