Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Cuts Chrome Page Load Times In Half w/ SPDY

Posted by CmdrTaco on from the well-that-seems-optimistic dept.

An anonymous reader writes "It appears as if Google has quietly implemented the SPDY HTTP replacements in Chrome (well, we knew that), and its websites. All its websites were recently updated with SPDY features that address some of the HTTP latency issues. The result? Google says the pageload times were cut about in half. SPDY will be open source, so there is some hope that other browser manufacturers will add SPDY as well."

44 of 310 comments (clear)

  1. My SPDY sense is tingling by DarkOx · · Score: 3, Funny

    :-)

    --
    Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
  2. Use in HTTP Servers by jonescb · · Score: 2

    When can we expect the SPDY protocol to be implemented in HTTP servers like Apache or Nginx? Does anything need to be done? The summary only talks about adding support to the client portions.

    1. Re:Use in HTTP Servers by S77IM · · Score: 4, Informative

      http://code.google.com/p/mod-spdy/

      --
      Student: Is it true that the foundation of the universe is paradox?
      Master: Well, yes and no.
  3. Have no page load problems by fermion · · Score: 4, Interesting

    My pages load plenty fast. What I notice is that when the page goes to google analytics that load process stops while waiting for the server. There was a time when pages would load partial content, and then go for the ads. Now, many pull the ads and analytics first. This would be good if the ad servers were fast, but the seem to be getting slower. Since google serves so many ads, it seems within it's power to make the web faster by making the ads faster. Perhaps, like MS, they want the web slow for all other browser, so Chrome seems so much faster.

    --
    "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    1. Re:Have no page load problems by sockonafish · · Score: 2

      That's just bad code. The author of the page should at the very least be putting the call to Google Analytics below the footer. Preferably, they'd make it a callback to document.ready().

    2. Re:Have no page load problems by Dhalka226 · · Score: 3, Insightful

      Some people choose not to block ads.

    3. Re:Have no page load problems by gpuk · · Score: 3, Informative

      Normally, DNS lookups *are* locally cached by default....... if you're on Windows, try running ipconfig /displaydns

      The problem might be with your upstream resolver(s). If you use your ISPs resolvers, maybe they are are overloaded? Or if you are using a non-ISP upstream cache, maybe it's sparsely populated? Either of these would make initial lookups slow.

      You could give Google's public resolvers a try and see if they improve your lookup times: 8.8.8.8 and 8.8.4.4

    4. Re:Have no page load problems by omglolbah · · Score: 2

      Win7 already does this. The DNS Client service performs caching of queries.

    5. Re:Have no page load problems by AndrewBuck · · Score: 2

      I have noticed the same thing in my house. Our DNS server that we get from Qwest can take as much as 10-15 seconds to resolve DNS queries sometimes (this is not all the time but when it happens its a major pain). I have dnsmasq running on my Ubuntu box (which will use OpenDNS to resolve cache misses instead of the Qwest DNS server). This makes cache misses faster than they would have been anyway, and cache hits take 0ms. I have switched over all of the computers in the house (both Windows and Linux boxes) to resolve through this machine here and that works very nicely. An added benefit is that if I want to change from OpenDNS to something else I only have to change it in one place now. I definitely recommend doing this.

      As the parent post mentions, websites don't change IP often enough for this to be a problem and therefore it makes sense to cache DNS for at least some length of time. DNSMasq seems to honor the keepalive times in the results it gets from upstream. Does anyone here know if there is a way to tell it to keep all entries for at least some length of time (e.g. 1 day) before considering the info stale? This would not only speed up lookups but would further reduce load on the upstream DNS server.

      -Buck

    6. Re:Have no page load problems by Runaway1956 · · Score: 2

      google "namebench". It's a google code project. I think current version is 1.3.1 Download it, run it, and be amazed. You can speed those DNS lookups significantly if you only know which servers to use. Don't expect it to be a ten second operation, though. Plan on spending ten minutes, minumum, with it. More reasonably, give it thirty minutes. Use namebench's recommendation, or modify it as you see fit. My own latency with the default ISP server was out of this world. In fact, I couldn't find a slower server anywhere around me. Maybe if I chose a server in Djibouti, I could have found a slower one.

      When you've finished playing with namebench - install your own DNS cache, like squid. Then, you'll have the fastest possible lookup for repeated queries on your own hardware, plus a fast lookup when you don't have it cached. It doesn't get any better than that!

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
    7. Re:Have no page load problems by caluml · · Score: 2
      Doesn't everyone do this?

      sudo echo 127.0.0.2 google-analytics.com www.google-analytics.com >> /etc/hosts

      My rule is that if a script from an external site slows down my page loading long enough that I can see it saying "Waiting for ..." in the status bar, then that site gets added to my hosts file.

      I'm 120 miles away from my powered off laptop, otherwise I'd post you the worst offenders here.

      --
      Get your own free personal location tracker
    8. Re:Have no page load problems by jfengel · · Score: 2

      We choose not to block polite ads, that don't slow the system down or distract. I don't want sympathy; I want technology that makes polite advertising feasible so that web sites I like can support themselves without having to charge me.

  4. Detailed info on SPDY by NevarMore · · Score: 5, Informative

    http://www.chromium.org/spdy/spdy-whitepaper

    1. Re:Detailed info on SPDY by Carewolf · · Score: 2

      1. SPDY uses 1 TCP-connection, instead of many. Which makes it faster. The time to establisch a new TCP-connection is a lot of overhead when you visit a webpage which has many small elements on it. It also has a big advantage when using HTTPS. Again because you just use the one TCP-connection (no extra SSL-connections to establish):

      This is what is called pipelining in HTTP 1.1. It is not required by HTTP, but even 10 years ago when I last checked only Microsoft didn't support it. They do add the ability to send multiple elements in parallel, instead of sequential, but since it is all send from one server and limited by bandwidth, that doesn't actually add anything speedwise over standard HTTP (though it might be needed for their server push implementation).

  5. Re:Embrace, Extend, ? by bmo · · Score: 4, Insightful

    No, because the Microsoft way to embrace, extend, extinguish was to keep the "how to extend" part to itself and secret, like what they did with Kerberos.

    This is open sauced. You are free to implement it in your own stuff.

    You would have known that if you read the article.

    --
    BMO

  6. Re:Most obvious use by justmike2000 · · Score: 2

    So it will refresh itself twice as fast!

  7. Comment removed by account_deleted · · Score: 3, Informative

    Comment removed based on user account deletion

  8. "will be open source" by cpscotti · · Score: 2

    Whenever someone starts a project with that in mind: it means shit!
    Why wasn't it open source from the start?

    Look what happened to symbian...
    (Well, maybe I should rtfa but I'm already killing precious time by reading slashdot so that wouldn't be nice..)

  9. Re:Embrace, Extend, ? by reilwin · · Score: 2

    This is open sauced.

    And it's a damn good sauce too!

  10. Re:And this... by M.+Baranczak · · Score: 2

    They're releasing the implementation under a BSD license. And unlike that other giant software company back in the old days, they don't have an overwhelming market share, so they can't just ram new standards down everyone's throats. If they make it incompatible, then nobody will use it. So it looks pretty good so far.

  11. thank you, finally by hesaigo999ca · · Score: 3, Informative

    Finally a story for us geeks that want geek stories....I guess cmdtaco is slowly waking up....

  12. Wait a Minute by ZamesC · · Score: 2

    Let's say, for example, that Microsoft had: 1) Taken an existing web standard and made proprietary changes to it (promising to make the changes open-source, "in the future"), and 2) Implemented those changes in IE and MSN/Bing/Live.Com making those sites faster when using IE. Wouldn't everyone here being screaming "Anti-trust" and demanding an SEC investigation?

    1. Re:Wait a Minute by John+Hasler · · Score: 2

      No. Not everyone. Somebody would be saying "If Google had done that you wouldn't be complaining".

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    2. Re:Wait a Minute by TheSunborn · · Score: 2

      That would not at all be what Google did. Google have published full documentation of the current version of the spdy protocol. (Its linked on the announcement page, and looks like something which will be given to w3c once its done.

      It is however still a draft because the protocol is not finished yet.

  13. Re:And this... by Zocalo · · Score: 3, Interesting

    SPDY is (according to Google) going to be released as open source, so I'm hopeful that it's development will be more akin to Mozilla's tack with its "Do Not Track" header - add support to your own browser, then throw it out there and see if the market is interested. IE9 already supports the "Do Not Track" header and there is also signs of some interest from websites too, so that's looking good.

    What would be even better though, especially given that SPDY is really an extension to HTTP akin to using GZ compressed data, is if Google were also to write up and submit an RFC or whatever mechanism it is that W3 uses to get HTTP extensions added to the standard, such as it is. SPDY seems very much like a win for both content providers and content consumers to me, so once the details are out there I'd like to think that we'd see fairly rapid adoption by the browsers over the next several months, followed by backend support from Apache, IIS et al with their next major releases.

    --
    UNIX? They're not even circumcised! Savages!
  14. SPDY means what? by erroneus · · Score: 2, Funny

    I am thinking Google did not learn the lesson from the SCSI acronym. Initially, the creator of SCSI wanted it to be pronounced "Sexy" and we ended up saying "Skuzzy." Obviously, Google wants this to be pronounced as "Speedy" but I can easily see this becoming "Spoddy."

    And I have looked around a bit... I still can see where SPDY is defined anywhere as to what the letters mean? I can imagine a lot of meanings... except for the Y. (Standard Protocol no aDopted Yet)?

  15. Re:Let's get this out of the way by CharlyFoxtrot · · Score: 3, Insightful

    I'll take a stab at it :

    Everything is sent through an encrypted channel making it difficult to filter out ads before they hit the client (like with privoxy for example.)
    No cashing ("Since we're proposing to do almost everything over an encrypted channel, we're making caching either difficult or impossible." -Protocol Draft) means you'll be served "fresh" ads every time.

    So it looks like this would be good news for Google's core business.

    --
    If all else fails, immortality can always be assured by spectacular error.
  16. SPDY - server push by ThePhilips · · Score: 4, Insightful

    My favorite part of the SPDY is server push: now advertisers can clog my internet channel and hog the browser with ads long before the AdBlock kicks in. Or a hacked site would host malware and load it onto potential victims harddrives in parallel to normal surfing. Imagination is the only limit - of how it can go wrong.

    For the security reasons, I think SPDY is a bad thing.

    And I'm personally not bothered with 1-2s loading times.

    P.S. The Chrome guys instead would have invested more times in the bookmarks, to make them useful. They could start by integrating Chrome with the Google Bookmarks.

    --
    All hope abandon ye who enter here.
    1. Re:SPDY - server push by pavon · · Score: 3, Interesting

      Yeah, and by their own testing, the push features only resulted in an additional -1% to +3% improvement (yes it made things slightly slower in one case). The additional complexity added by those features is not justified by their benefits. They should just drop them.

    2. Re:SPDY - server push by ThePhilips · · Score: 4, Informative

      I'm not sure there's really a security issue here. From the spec, all its doing is letting the server send back multiple items in response to a request for one item. So if you request X, and the server knows you're going to need Y too, it can send both at once.

      If server "knows" that I "need" 2MB of flash ads to see the 40K html page, it would send them to me. IOW browser is out of control what server sends, browser can only discard the content which has wasted my bandwidth and isn't going to be displayed.

      It's not like the server can connect to you out of nowhere and start firing stuff at you. And since a server can already send malicious content back in response to a request, the security aspect isn't really worse then it already is.

      With HTTP, there is no way server can send me something my browser didn't asked for. It can send something bad *instead* of what my browser asked - but only once and with user visible effect. With SPDY, server can send me loads of junk *silently*, still appearing to be serving legit content.

      For static content, it is even worse: first time I visit the page it is cached and then a cached copy used. With SPDY, bandwidth is going to be always wasted for transferring the static content. Yes, I need it to display the page - but no, I have already local cached copy.

      --
      All hope abandon ye who enter here.
  17. SPDY clarifications by mbelshe · · Score: 5, Informative

    Thanks for all the kind words on SPDY; I wish the magazine authors would ask before putting their own results in the titles!

    Regarding standards, we're still experimenting (sorry that protocol changes take so long!). You can't build a new protocol without measuring, and we're doing just that - measuring very carefully.

    Note that we aren't ignoring the standards bodies. We have presented this information to the IETF, and we got a lot of great feedback during the process. When the protocol is ready for a RFC, we'll submit one - but it's not ready yet.

    Here are the IETF presentations on SPDY:
          http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf
    and
          https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf

    I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201

    We love help- if you're passionate about protocols and want to lend implementation help, please hop onto spdy-dev@google.com Several independent implementations have already cropped up and the feedback continues to be really great.

    1. Re:SPDY clarifications by 0xABADC0DA · · Score: 3, Interesting

      Since we've got it direct from the horse's mouth -

      - Why server push? Nobody seems to think it's a good idea and it makes things more complicated for everybody involved, including proxies. What is the rationale for this feature.

      - Why did you name it "SPDY" to show "how compression can help improve speed" when SSL already supports compression?

      - In the performance measurements in the whitepaper, what HTTP client did you use and what multiple connection multiplexing method was used if any? How were the results for HTTP obtained? For instance the whitepaper says an HTTP client using 4 connections per domain "would take roughly 5 RTs" to fetch 20 resources, implying theory math. Were situations like 10 small requests finishing in the time it takes to transfer 1 large request taken into account? (ie in practice multiple requests can be made without increasing total page load time)

      - The main supposed benefit seems to be requesting more than one resource at once. Then a request could stall the connection while being processed (ie doubleclick ad) and hold up everything after it, so then you add multiplexing, priorities, canceling requests, and all that complication. Why not just send a list of resources and have the server respond back in whatever order they are available? This provides the same bandwidth and latency with superior fault handling (if the connection closes the browser has only one resource partially transferred instead of several).

      - The FAQ kind of reluctantly admits that HTTP pipelining basically has the same benefits in theory as SPDY except if a resource takes a while and holds up the remaining ones. So what benefit would SPDY have over just fixing pipelining so that the server can respond in whatever order it chooses? The only real problem with HTTP tunneling is fixed-order and bad implementations (ie IIS), correct?

      Barring really good explanations it looks to me like SPDY is just very complicated and increases speed basically as a side-effect of solving other imaginary problems.

    2. Re:SPDY clarifications by fwarren · · Score: 2

      The one thing I appreciate, is your not selling this as "Chrome makes the web faster" the way Microsoft did back in the 90's. By creating their own extensions, and trying to sell everybody on how much better IE5 with IIS was then Netscape with Apache.

      You have added it to chrome and to google sites. Some may notice a speed difference, some may not. Meanwhile the protocol, such as it is, is free to use and implement without anyone having to reverse engineer it. Which is a pretty decent earnest money down to convince folks that the final protocol will be open, well documented, a standard, AND you are not going to try to keep moving ahead and adding to it at a clip no-one else can keep up with. AKA Embrace, Extend and Extinguish as some others have done.

      --
      vi + /etc over regedit any day of the week.
    3. Re:SPDY clarifications by grmoc · · Score: 2

      I'm one of the other people who works on SPDY.

      server push: We have some debates about this internally, but it seems the market is deciding that push is important-- e.g. image inlining into the HTML. Server push allows you to accomplish the same, but gives the benefit of having them known as individual resources by a single name, and thus cacheable. I believe it may be particularly beneficial for people on high-rtt devices like mobile. If you look at data just about anywhere, you can see that RTT is the real killer. 100ms RTTs are fairly normal for mobile devices. I'd much rather have the server push that data to me rather than having to wait 100ms between each round of requests-- it can make literally seconds of difference for complex pages.

      Why "SPDY": The name we first chose would have made money for the lawyers... and so we picked another.

      performance measurement: In the whitepaper, as per my recollection, Chrome was the client for all of the measurements that we did.

      "supposed" benefit+pipelining: HTTPs fault handling is terrible, actually. When you're sending a request and you don't receive the response, you don't know if the request was processed or not. This is particularly fun for non-idempotent transactions like say.. charging your credit card. SPDY includes mechanisms for telling the client (assuming the connection wasn't broken) that the server rejected the request, and thus disambiguating the situation. In such cases, the client knows that it is safe to retry. In any case, you're talking about doing http-pipelining plus response reordering.
      How would you handle the following scenario: User opens video in one tab, creates another in which he or she looks up the Dow Jones index for the day. The video is still being displayed in the other tab. You have a head-of-line blocking issue. How do you deal with it? Canceling the video request is a poor choice-- the user likely will come back to it later. Waiting for the video to finish is a poor choice-- the user probably wants to see the Dow right now instead of 15 minutes later. Opening a new connection incurs additional cost in the network (NAT), on the servers and worse yet, incurs the latency penalty of a new connection setup plus whatever other protocols you're negotiating. I don't want to wait 2 RTTs before I get my content. I'm impatient. I want it now! :)

      I'd suggest taking the open sourced code that we've provided and implementing your solution. You can then run the same battery of tests against your solution that we've done (in the lab) for SPDY. Data is extremely convincing when collected properly. If your solution worked better, then we'd have a basis for re-analysis.

  18. Setting off warning bells by 140Mandak262Jamuna · · Score: 2

    As part of the "Let's make the web faster" initiative, we are experimenting with alternative protocols to help reduce the latency of web pages.

    This smells very close to the "embrace extend and extinguish" technique of Microsoft. Unless Google follows it by keeping the technology open, work on getting it certified into the next version of the standards, this would become the first step in Google becoming the next Microsoft.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  19. BAD by improfane · · Score: 2, Insightful

    I cannot be the only person to think this is not a good thing. So now we'll have sites that have to run both technologies with regular HTTP/TCP as fallback and we fragment the web browser ecosystem even more.

    Thanks Google. As much as I want HTTP to be faster, I think this way is a bit degrading to the web... There was no standards process. It will probably now be rushed as a standard.

    Basically its a fake way of making Google look faster, so you either adopt Google's tech to get ahead. It reeks of a Microsoft strategic move to me. Can't optimize the browser? Change the browser and make an incompatible change! Well done...

    --
    Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
    1. Re:BAD by mbelshe · · Score: 5, Informative

      Actually, you should read the spec as to how it is implemented. The TLS/NPN mechanism for switching to SPDY has no "fallback".

      And there is no intent to rush - heck - we've been working on it for over a year. You think that's rushed? If you're an engineer, I hope you'll appreciate that protocol changes are hard. You can't use pure lab data (although we started out with lab data, of course). Now we need real world data to really figure it out. We changed it in a way which *nobody noticed* for about 4 months. So, I don't think we hurt the web at all, but we are accomplishing the goals of learning how to build a better protocol.

      Seriously, if you have a better way to figure out new protocols, we'd love to hear them at spdy-dev@google.com, and if you want to lend a hand implementing, that is even better!

    2. Re:BAD by kaiser423 · · Score: 2

      Amdahl's Argument -- always optimize the slowest part first.

      Browsers and javascript have come ridiculously far in the last couple of years. It would seem taht they're no longer the bottleneck, but now the protocol is. I actually doubt that you can squeeze that much more performance gains out of the browser at this point. I have no problem with now optimizing the protocol as long as the results of that process are open.

    3. Re:BAD by real+gumby · · Score: 2

      I cannot be the only person to think this is not a good thing. [...] As much as I want HTTP to be faster, I think this way is a bit degrading to the web... There was no standards process. It will probably now be rushed as a standard

      Actually, this is an example of how standardisation should work. They thought about a good way to fix a problem (including consideration of past problems); chose an approach that was upwardly compatible and harmless to older clients; released a working implementation and source code.

      How could anyone do better? This is the classic path to "rough consensus and running code".

      There are plenty of criticisms appropriate to SPDY and Google in general, but how they have proceeded in this case is not one of them.

  20. Re:And this... by Lennie · · Score: 2

    Actually there are people working on submitting to the IETF as a RFC, it takes time.

    It just uses an extra header to get it started/switch to the SPDY-protocol. Not only that, but the extension for HTTP to make the switch is already gone through most of the IETF-process.

    I wouldn't be surprised if the biggest hold up is actually websockets. Because the new 'HTML5' websockets where found to be insecure, atleast in combination with transparant caching proxies that didn't implement HTTP properly. Java and Flash are just as 'insecure' or actually it is these proxies which can be fooled in caching the wrong information (think kind of like phising).

    The last 'spec' of websockets was implemented atleast Opera and the Firefox-developers but as these problems exist, the websocket protocol is disabled in their browsers.

    --
    New things are always on the horizon
  21. Re:Embrace, Extend, ? by Lennie · · Score: 2

    Actually the article is wrong about this, the code is open source (Chrome or alteast Chromium which it is based on is an open source project after all) and their are drafts for the RFC.

    --
    New things are always on the horizon
  22. Re:And this... by AmberBlackCat · · Score: 3, Insightful

    With Honeycomb, doesn't Google have a history of saying things will be released as open source, and then not releasing the source?

  23. Interesting, but somewhat developer-hostile by Millennium · · Score: 2

    This is an interesting wrapper around MIME, but it is not HTTP in any way. Honestly, it's more like an "embrace-and-extend" in the Microsoft sense. It is backward-incompatible in ways that are inconsistent with its stated philosophy of bandwidth savings (and in ways which break the most basic HTTP semantics), and it throws gratuitous binary into the wrapper while using FUD to justify its presence (notably the specter of "security problems"). This is sad, because it actually does contain some much-needed improvements to HTTP, such as TLS-only, compression-by-default, and header compression. But it's not an extension, because that implies backward-compatibility: it's a replacement, and one with certain other design decisions that are questionable at best.

    Some questions in particular:

    1) Why break the request-line and status-line? This is the major compatibility-killer, and it adds to the bandwidth consumed by the protocol in ways directly counter to the concept of saving bandwidth. To call requests and responses "virtually unchanged" from HTTP is disingenuous when the most basic syntactic requirements for both of these things is completely different: they are in fact completely different, not virtually unchanged: what you've unchanged is MIME.
    2) Why binary for the wrappers? The specter of security issues via incorrect parsing is true as far as it goes, but by no means insurmountable, and the bandwidth savings are minimal at best. In exchange, the spec becomes considerably harder to debug (and thus to implement) and to extend further as needed by future requirements.

  24. Mod Parent down by kc8jhs · · Score: 2

    It is incompatible with all other websites and all other browsers - it only works with the combination of Chrome+Google's own websites.

    This is flat out wrong. Just this morning I used Chrome to connect to a test server that was running a node.js implementation of SPDY. I verified the connection using chrome://net-internals. It worked well.

    There is nothing in chrome that prevents this from working on other domains/websites.

    There is nothing stopping anyone from implementing their own server.

    End of FUD.