Slashdot Mirror


Chrome Now Reloads Pages 28% Faster (techcrunch.com)

Google has announced that it has worked with Facebook and Mozilla to make page reloads in Chrome for desktop and mobile significantly faster. According to Google's data, reloading sites with the latest version of Chrome should now be about 28 percent faster. From a report: Typically, when you reload a page, the browser ends up making hundreds of network requests just to see if the images and other resources it cached the first time you went to a site are still valid. As Google engineer Takashi Toyoshima notes in today's announcement, users typically reload pages because they either look broken or because the content looks like it should have been updated (think old-school live blogs). He argues that when browser developers first added this feature, it was mostly because broken pages were common. Today, users mostly reload pages because the content of a site seems stale.

124 comments

  1. Umm, no... usually the page is broken. by zephvark · · Score: 3, Informative

    I reload pages because they are broken, generally due to an excess of advertising. Yes, I could filter out advertising but, I often get paid for having it there. Not that I look at it.

    1. Re:Umm, no... usually the page is broken. by gnick · · Score: 5, Funny

      I reload the page to see if I've gotten any replies to my /. posts since my last refresh.

      I know how sad that is.

      --
      He's getting rather old, but he's a good mouse.
    2. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 1

      You pretty much have to look at it since most advertising is a virus, popping up with a new tab fullscreened saying your computer has been taken over.

      They can't pay me enough money to not block ads.

    3. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      Chrome sucks, a spy tool for into-chimps at google

    4. Re:Umm, no... usually the page is broken. by arth1 · · Score: 3, Interesting

      I reload pages because they are broken, generally due to an excess of advertising.

      Yes, broken javascript in an ad is probably the #1 reason why I reload pages. At least I have a chance to get a different ad (which may also be broken, in a different way).

      The #2 reason is brain dead javascript code that doesn't account for things occurring out of order due to dropped packets and retransmits. Which is becoming more of a problem as internet provider drop more packets for content providers that don't pay the bridge troll.

    5. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 1

      I mostly see broken pages when some bad JS shits the bed. Pages are developed like applications and they fall over badly when one of their "modules" stops working or returns an unexpected result.

      Try blocking social media sites and some unrelated sites just die because they expect their social media widgets/connectors to work.

    6. Re: Umm, no... usually the page is broken. by Anonymous Coward · · Score: 1

      Now with 28% faster spyware.

    7. Re:Umm, no... usually the page is broken. by sycodon · · Score: 5, Funny

      I reload the page because the pornhub video froze up.

      --
      When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
    8. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0, Funny

      The fact you watch porn means you are misogynist objectifier of women. Check your fucking privilege!

    9. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      how do you get paid for having ads up?

      Are you refreshing your own site that much to impact ad views? ... that isn't quite allowed in your TOS...

    10. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 1

      But it's man on donkey porn...

    11. Re:Umm, no... usually the page is broken. by AmiMoJo · · Score: 1

      My friends think I'm popular because I set up a custom notification sound for Slashdot reply notification emails.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    12. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      If you haven't optimized your browsing experience for porn, you've got your priorities wrong.

    13. Re:Umm, no... usually the page is broken. by johanw · · Score: 0

      Just grab them by the pussy.

    14. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      I use no-script *A LOT*. I reload because I broke the site usually by running that.

    15. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      I just checked ... my privilege is just fine, thank you.

    16. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 1

      My privilege is huge.

      And growing bigger the more I think about your privilege.

    17. Re:Umm, no... usually the page is broken. by sycodon · · Score: 1

      I'm watching THEIR fucking privileged.

      --
      When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
    18. Re:Umm, no... usually the page is broken. by mspohr · · Score: 1

      I've found that the Mercury Reader extension effectively removes ads and defeats the "Please unblock ads on our special site" message.

      --
      I don't read your sig. Why are you reading mine?
    19. Re: Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      Rotflmao

    20. Re:Umm, no... usually the page is broken. by antdude · · Score: 1

      Um, /. can notify you of new replies.

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    21. Re:Umm, no... usually the page is broken. by hackwrench · · Score: 1
    22. Re: Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      A sand n1gger fucking a poor donkey? Thats terrible abuse of animals.

    23. Re:Umm, no... usually the page is broken. by Anonymous Coward · · Score: 0

      I've seen scripts where an element is blocked by the proxy due to security policy, and they happily keep repeating the request as fast as the browser/CPU will let them.

    24. Re:Umm, no... usually the page is broken. by allo · · Score: 1

      Who needs to watch porn obviously does not have a fucking-privilege.

  2. Confusing summary. by Anonymous Coward · · Score: 0

    I feel like I read a book and somebody ripped out the last several chapters.

    1. Re:Confusing summary. by unrtst · · Score: 2

      I feel like I read a book and somebody ripped out the last several chapters.

      Don't feel too bad. You won't find those in the article either. Here's the only sentence you missed:

      The team simplified Chrome’s reload behavior and it now only validates the main resource.

      IE. it used to reload 100's of page elements (eg. checking the etag of each), and now it only checks the main page.

      I occasionally find I need to do a SHIFT+Reload (or CTRL+SHIFT+R) to force reload of all elements. With this new "only reload main resource" feature, I sure hope they add a something similar to reproduce the old behavior because a full reload is MUCH more overhead than the current reloads, or provide an option to use the old behavior (hahaha, yeah right! modern app *adding* a setting/option!).

  3. Not all pages by Anonymous Coward · · Score: 4, Informative

    Chrome now reloads Facebook pages up to 28% faster. The rest of the web won't see the benefit.

    1. Re:Not all pages by freeze128 · · Score: 4, Funny

      In other news, Chrome now uses 12% more RAM.

    2. Re: Not all pages by Anonymous Coward · · Score: 0

      Don't forget Mozilla.org!

    3. Re:Not all pages by arth1 · · Score: 2

      In other news, Chrome now uses 12% more RAM.

      In other words, going from 90% to 102%?

    4. Re: Not all pages by Anonymous Coward · · Score: 0

      hey it's moz:// now.

    5. Re: Not all pages by viperidaenz · · Score: 1

      moz://a

    6. Re: Not all pages by fahrbot-bot · · Score: 1

      moz://a

      Hmm... I tried that, but Firefox reported:

      (i) The address wasn’t understood

      Firefox doesn’t know how to open this address, because one of the following protocols (moz) isn’t associated with any program or is not allowed in this context.

      • You might need to install other software to open this address.

      [ Try Again ]

      --
      It must have been something you assimilated. . . .
    7. Re: Not all pages by Anonymous Coward · · Score: 1

      Your inability to math has given me a tumor. Thanks. Just fucking thanks.

    8. Re: Not all pages by Anonymous Coward · · Score: 0

      There's actually a proposal (which will probably result in a Working Group, with weekly collaboration sessions for 6 months, at least two in-person meetings of all concerned parties, there's so much navel gazing at Mozilla it isn't funny anymore) that moz:// should be registered as a protocol handler, and that going to moz://a should bring up one of the about: pages. I imagine after a couple of years, the Working Group will decide it's too confusing, or it "dilutes the brand" or something.

    9. Re:Not all pages by swillden · · Score: 1

      Chrome now reloads Facebook pages up to 28% faster. The rest of the web won't see the benefit.

      That's not what the article says. What it says is:

      Facebook, just like other pages, says its pages now reload 28 percent faster, too

      As for how this feat is accomplished (would have been nice if that was in the summary), what now happens is that when you hit "reload" the browser only reloads the main page. It obviously has to load any resources requested by the new version of the page that weren't requested by the previous version, but it doesn't reload resources that were already loaded for the previous version.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:Not all pages by Anonymous Coward · · Score: 0

      That's because Facebook pages take more than 28% longer to load in the first place.

    11. Re:Not all pages by gravewax · · Score: 1

      So basically if the reason for you reloading was because of porked resources on the page then Chrome now just ignores your request for a reload.

    12. Re:Not all pages by Anonymous Coward · · Score: 0

      I've never seen Chrome use anywhere near 28.8GB of RAM...

      Perhaps you should look at upgrading both your computer and math skills.

    13. Re:Not all pages by arth1 · · Score: 1

      Why would I want to upgrade?

      % free -h
                    total used free shared buff/cache available
      Mem: 503M 130M 22M 72K 350M 358M
      Swap: 2.9G 51M 2.9G

    14. Re: Not all pages by Anonymous Coward · · Score: 0

      This is all the navel-gazing I saw: https://bugzilla.mozilla.org/show_bug.cgi?id=moz%3A%2F%2Fa

      Seems perfectly reasonable to have a little fun with this to me, but then what do I know? I guess it would be better to not let them have any fun, and just put up with our snarking in a joyless existence chained to desks.

    15. Re: Not all pages by allo · · Score: 1

      try about:mozilla

    16. Re: Not all pages by fahrbot-bot · · Score: 1

      try about:mozilla

      I know.. I was just commenting on how ridiculous the new name is. :-)

      --
      It must have been something you assimilated. . . .
  4. Efficiency by doom · · Score: 1

    Hm perhaps we could use similar techniques to avoid making those hundreds of network connections in the first place...

    1. Re:Efficiency by jellomizer · · Score: 2

      That isn't how http works. Send the data and disconnect.
      We should have a better protocol that deals with Web 2.0 content. But the protocol wouldn't be http

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re:Efficiency by doom · · Score: 1

      What I'm getting at is the solution to Web 2.0 content might be Web 1.0 content.

      Or technical tricks to emulate Web 1.0 content.

      (I bet google has the chops to come up with a really killer ad blocker.)

    3. Re:Efficiency by tepples · · Score: 2

      HTTP has supported keep-alive and pipelining since 1.1, the first to make support for name-based virtual hosts mandatory.

    4. Re:Efficiency by Anonymous Coward · · Score: 1

      Depends how you classify HTTP, but the protocol already exists. HTTP/2 has been around for a while and is gaining traction: https://http2.github.io/faq/

      I was sceptical at first (binary? WTF?) but it's actually pretty good.

    5. Re:Efficiency by Anonymous Coward · · Score: 1

      (I bet google has the chops to come up with a really killer ad blocker.)

      Yeah, but one of the earlier ways they went evil was to buy doubleclick.net.

    6. Re:Efficiency by ilsaloving · · Score: 1

      If todays average website wasn't a steaming shitshow, then it wouldn't be necessary.

      But they are, so we do. *shrug*

    7. Re:Efficiency by epyT-R · · Score: 1

      ..but then providers wouldn't have control over every aspect of use.. That's a big no no these days. Being able to load an old version to restore functionality? That's piracy! Not selling useage data to advertisers (or the state)? That's leaving money on the table!

    8. Re:Efficiency by viperidaenz · · Score: 1

      HTTP 1.0? probably not
      HTTP 1.1? Yeah, you can keep the connection open and send requests before the response comes back
      HTTP 2.0? Yes.

    9. Re:Efficiency by KingMotley · · Score: 1

      We could even call it HTTP/2.0. Or I guess that is what we called it.

    10. Re:Efficiency by unrtst · · Score: 1

      Neither of those solve the issue of checking the status of 100's of elements. They help, but each check still needs to be done, and they can't be done completely parallel (sane connection count limits on servers limit that, and so browsers only do N parallel requests, each keepalive'd).

      They have simply decided not to check any of those other elements. Ignoring 100's of elements for a 28% speedup seems like bad math to me. They're only reloading 1 in 100's of elements, so that should be a 100x speedup (10000% speedup?)... that might be worth it, but not for just 28% faster.

    11. Re:Efficiency by Anonymous Coward · · Score: 0

      Doing them in parallel is bad. Doing them async concurrently is good. Parallel is bad is bad because the many connections create a multiplier against TCP "slow start" which has exponential growth. Instead of growing at a rate of 2^x, you grow at a rate of n2^x. You also have the issue of burst rates for established connection. Most network stacks do not have packet pacing yet. If you have a TCP window of 20 packets and a 1Gb connection, you will burst 20 packet at 1Gb/s. If you have 100 connections opened and they all try to do the same thing at the same time, now you have 2,000 packets be bursted.

      You really want as few connections as possible and to async-multiplex requests and responses over each connection. Enter HTTP2. I think they added the kitchen sink, but we really need some of its basic new features.

    12. Re:Efficiency by unrtst · · Score: 1

      This thread keeps flying off on tangents!

      doom said, "Hm perhaps we could use similar techniques to avoid making those hundreds of network connections in the first place..." ... I don't really know what he's getting at here. I took it as a joke - don't get all the advertisments and crap to begin with, but maybe he meant HTTP2 style with one TCP connections and multiplexed requests.
      jellomizer stated that HTTP is, "Send the data and disconnect"
      tepples pointed out that, "HTTP has supported keep-alive and pipelining since 1.1"
      I noted that, "Neither of those solve the issue of checking the status of 100's of elements. They help ... but can't be done completely parallel ..."
      You said, "Doing them in parallel is bad. Doing them async concurrently is good." yada yada HTTP2.

      Under HTTP2, using a classic style reload of a page, there would still be 100's of requests sent - they'd just be multiplexed over the same TCP connection.
      Today, with keepalives and pipelining, the browser would open several connections, using them in parallel but sending requests in each in series. While HTTP2 may be slightly faster (though it will lose out on the benefit of talking to multiple load balanced servers), it's not going to solve the 100's of requests problem either. That problem is simply that there are 100's of requests.

  5. Butt out, Google. by Anonymous Coward · · Score: 1

    I reload pages for a variety of reasons depending on what I am doing. I already have to drop into dev tools and chose from a variety of reload "flavors" to get some tasks done. If they must persist in deciding for me what I really want to do based on what other people "typically" want to do, at least make the option to express my actual goal more easy to access.

    Or, you know, GTFO with your over-engineered "solutions".

    1. Re:Butt out, Google. by sunking2 · · Score: 0, Troll

      Write your own web browser then.

    2. Re:Butt out, Google. by Anonymous Coward · · Score: 0

      No.

    3. Re:Butt out, Google. by thegarbz · · Score: 1

      If they must persist in deciding for me

      They're not deciding for you. They are giving *you* the option, and deciding for everyone else.

    4. Re:Butt out, Google. by Anonymous Coward · · Score: 0

      If they must persist in deciding for me

      They're not deciding for you. They are giving *you* the option, and deciding for everyone else.

      I don't want the "option". I want consistent, predictable behavior from one of the core features of web browsing. 28% faster page reloads is meaningless if I have to spend time fiddling around with (unwanted) options.

  6. Actual Summary by Anonymous Coward · · Score: 3, Informative

    Because it'd be awful if the summary actually summarized what was being done. From the article:

    To overcome this issue, the team simplified Chrome’s reload behavior and it now only validates the main resource. Facebook, just like other pages, says its pages now reload 28 percent faster, too, so the next time you want to check if your friends finally posted new pictures of their cute corgis to Facebook (and you are using the web app instead of the native FB app), you’ll now get the answer faster.

  7. TLDR by Anonymous Coward · · Score: 5, Informative

    One liner description of the change...
    They made refresh 28% faster by having it no longer refresh.

    1. Re:TLDR by Anonymous Coward · · Score: 0

      One liner description of the change...
      They made refresh 28% faster by having it no longer refresh.

      And they only got 28% faster?

      Lame.

    2. Re:TLDR by Anonymous Coward · · Score: 0

      It makes sense. If servers can mark which resources are static and which dynamic, and send a SHA hash so the browser can figure what is broken (probably the browser knows what is broken already based on network errors, but a hash would confirm for sure), a lot of the page does not need to be reloaded.

      Desktop browsers have been smarter about this for some time. Pressing Reload will reload the HTML, and fetch any resources that are not cached, but Shift-Reload will force everything to be refreshed. Mobile browsers suffer from lack of an easy Shift key, so I guess they decided to play safe and do a complete reload every time.

    3. Re:TLDR by Anonymous Coward · · Score: 0

      basically this.

      "now only validates the main resource"

      DUH. skipping all the extra crud would speed up a page load. what's also why we run adblockers.

      ____

      HOWEVER.. lacking an actual reference link in TFA @ techcrunch to a google and/or mozilla and/or facebook "announcement", or even a blog post, regarding the collaboration between them and the improvements that resulted from it.. I CALL BULLSHIT on the whole thing.

  8. Faster than what? by Anonymous Coward · · Score: 0

    the first version of the browser? The last before the change? The slowest version ever?

  9. Ctrl-F5 by gQuigs · · Score: 2

    Guess it makes Ctrl-F5 even more useful...

    1. Re:Ctrl-F5 by Anonymous Coward · · Score: 0

      Guess it makes Ctrl-F5 even more useful...

      I have a new Ma Book pro you insensitive clod.

      They replaced the F-keys for a touch bar.

    2. Re:Ctrl-F5 by Anonymous Coward · · Score: 0

      They replaced the F-keys for a touch bar.

      Which still has an F5 key, you ignorant clog.

    3. Re:Ctrl-F5 by umafuckit · · Score: 1

      Ctrl-F5 doesn't refresh the cache on a Mac. That's "Cmd (Apple) + Shift + R”

    4. Re:Ctrl-F5 by xxxJonBoyxxx · · Score: 1

      >> I have a new Ma Book pro you insensitive clod. They replaced the F-keys for a touch bar.

      And the "C" key, too?

    5. Re:Ctrl-F5 by swillden · · Score: 1

      Ctrl-F5 doesn't refresh the cache on a Mac. That's "Cmd (Apple) + Shift + R”

      Or "Cmd (Apple) + R".

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  10. So wait... by dgatwood · · Score: 1

    I'm hoping this article is either wrong or incomplete. Otherwise, won't this mean a significant increase in breakages? Suppose the main resource relies on two resources, one of which is in the cache, the other of which isn't. Those two resources implicitly depend on one another in some way (e.g. a new version of JavaScript code might require a new version of CSS, or else rendering would be wrong and vice-versa). If the browser validates only the main resource, then unless the URLs for the resources changed, there's now a mismatch. Worse, there's no way for the user to fix it, because reloading doesn't revalidate any of the other resources.

    It seems like revalidation of all subresources should happen if any of the following are true:

    • Any resource other than the main resource was loaded directly (as opposed to from the cache)
    • The list of subresources referenced by the main resource changed (adding, removing, or changing dependencies).

    Then again, I've had so much trouble with CloudFlare caching that I've started putting version numbers in every JS and CSS filename, and I use a server-side include to let me bump that version number site-wide every time I touch something in a backwards-incompatible way, so if other folks use the same approach, then maybe this doesn't matter?

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

    1. Re:So wait... by tepples · · Score: 1

      I've had so much trouble with CloudFlare caching that I've started putting version numbers in every JS and CSS filename

      Such a versioned URL scheme has in fact been the best practice for several years now, as it lets you use far-future Expires: dates to reduce bandwidth use by return visitors.

    2. Re: So wait... by loufoque · · Score: 1

      Just give new versions of your content unique names, and problem solved.

  11. Broken behaviour by Anonymous Coward · · Score: 0

    I'm on Chrome beta. This new design seems broken. I am looking at a page with some broken image links (the links are fine; the browser timed out on loading them). I have hit refresh several times and this new behavior just leaves them broken. Way to go Google!

    1. Re: Broken behaviour by loufoque · · Score: 1

      Web 2.0 stuff only works if you have a reliable low-latency high-bandwidth internet connection.
      Funny that they designed this shit for mobile...

  12. Won't this break things? by lucasnate1 · · Score: 2

    From what I understand, this changes reload behavior so that reload doesn't completely reload a page. Won't this break the reload behavior when testing a page you're developing and/or when browsing pages that glitched temporarily? Would we end up with a "hold shift during reload" that all tech people will use instead?

    1. Re:Won't this break things? by Anonymous Coward · · Score: 1

      Given how many problems I've encountered with aggressive or incorrect caching in Chrome (seriously, there are won't fix bugs listed because they interpret the RFCs differently to everyone else), I'm not sure how this differs from the current shitty behaviour? Awesome: more hacks and workarounds to get things to reload correctly because Chrome's developers crave speed over usability or RTFRFC.

      Y'know what speeds pages up massively? Blocking all the ads, tracking scripts, and other crap that gets downloaded. Faster load times, less CPU and memory usage, and a much more pleasant browsing experience.

    2. Re:Won't this break things? by viperidaenz · · Score: 2

      If you're doing web development, try opening the web development tools and turning off the browser cache. Press F12. On Chrome it's a checkbox called "Disable cache" under the "Network" tab. IE has a "Always refresh from server" option on their network page too.

  13. But... but... but... by QuietLagoon · · Score: 1

    Will the advertisers on the page see the additional hit?

  14. Seems like someone is reading a OS book... by Anonymous Coward · · Score: 1

    First a scheduler and now caching. What OS feature should come next?

    1. Re:Seems like someone is reading a OS book... by number6x · · Score: 1

      The next version of chrome will contains a complete implementation of emacs, which qualifies as an operating system.

      Although the emacs operating system needs a better editor.

    2. Re:Seems like someone is reading a OS book... by Anonymous Coward · · Score: 0

      systemd

  15. Year-on-year spying on user is also up 28% by Anonymous Coward · · Score: 0

    just change to Firefox or Vivaldi. When each webpage does 28x cross-site scripting and is dependent on one or two dozen external servers to respond, those 28% or your 1gbit fiber upgrade won't matter anyway.

  16. What does it have to do with Mozilla? by xfizik · · Score: 2

    So Mozilla helped Google make Chrome faster? It's not clear what Mozilla's role and benefit in all of this...

    1. Re:What does it have to do with Mozilla? by Anonymous Coward · · Score: 0

      So Mozilla helped Google make Chrome faster? It's not clear what Mozilla's role and benefit in all of this...

      Yet, it is the most coherent move that Mozilla has made in recent memory.

    2. Re:What does it have to do with Mozilla? by viperidaenz · · Score: 1

      Their tag line is "Internet for people, not profit"
      I wasn't aware it was "Lets shun the other browser makers and continue to fuck up Firefox"

    3. Re:What does it have to do with Mozilla? by Anonymous Coward · · Score: 2, Informative

      There's actual information at this link, as opposed to the glorified Chrome ad that was submitted: https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook

    4. Re:What does it have to do with Mozilla? by AmiMoJo · · Score: 1

      Firefox seems to have been doing this for a while. When I refresh a page in FF it doesn't usually reload big images, just the main HTML.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:What does it have to do with Mozilla? by Anonymous Coward · · Score: 0

      You can make it even faster with this:

      https://addons.mozilla.org/en-US/firefox/addon/load-from-cache/

      I use it to enhance privacy - it stops FF from even checking to see if the cached object has been superseded. No phoning home at all. I've had surprisingly few cases of stuff not updating, and holding shift while clicking reload fixes those.

    6. Re:What does it have to do with Mozilla? by Anonymous Coward · · Score: 0

      Can you copypaste? I've blocked facebook on the router level.

      (It's about those ubiquitous 'share this on facebook' spy buttons.)

    7. Re:What does it have to do with Mozilla? by Anonymous Coward · · Score: 0

      Here you go, the short version is that Facebook noticed the problem and spend time with the browser vendors:

      Over the past two years Facebook has been working with browser vendors to improve browser caching. As a result of this work, both Chrome and Firefox recently launched features that make their caches significantly more efficient both for us and for the entire web. These changes have helped reduce static resource requests to our servers by 60% and as a result have dramatically improved page load times. (A static resource is a file our server reads from disk and then just serves it without running any extra code.) In this post, we'll detail the work we did with Chrome and Firefox to get this result — but let's start with a a bit of context and definitions that help explain the problem that needed to get solved. Up first, revalidation.
      Every revalidation means another request

      As you navigate the web you often reuse the same resources — things like logos or JavaScript code that are reused across pages. It's wasteful if browsers download these resources over and over again.

      To stop unnecessary downloads, HTTP servers can specify an expiration time and a validator for each request that can indicate to a browser that it doesn't need to download until later. An expiration time tells the browser how long it can re-use the latest response and is sent using the Cache-Control header. A validator is a way to allow the browser to continue to re-use the response even after the expiration time. It allows the browser to check with the server if a resource is still valid and re-use the response. Validators are sent via Last-Modified or Etag headers.

      Here's an example resource that expires in an hour and has a last-modified validator.

      $ curl https://example.com/foo.png
      > GET /foo.png

      In this example, for the next hour, a browser which received this response can re-use it without contacting example.com. After that the browser must revalidate the resource by sending a conditional request to check if the image is still up to date:

      $ curl https://example.com/foo.png -H 'if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT'
      > GET /foo.png
      > if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT

      If the image was not modified

      A not modified (304) response is sent if the resource has not been modified. This has benefits over downloading the whole resource again, as much less data needs to be transferred, but it doesn't eliminate the latency of the browser talking to the server. Every time a not-modified response is sent, the browser already had the correct resource. We want to avoid these wasted revalidation by allowing the client to cache for longer.
      Signaling no download needed over the long term

      Revalidation raises a difficult question: How long should your expiration times be? If you send expiration times of one hour, browsers will have to talk to your server to check if your resources have been modified every hour. Many resources like logos or even JavaScript code change rarely; every hour is overdoing it in those cases. On the other hand, if your expiration times are long, browsers will serve the resource from cache potentially showing users out of date resources.

      To solve this problem, Facebook uses the concept of content addressed URLs. Rather than our URLs describing a logical resources (“logo.png,” “library.js”) our URLs are a hash of our content. Every time we release our site, we take each static resource and hash it. We maintain a database that stores those hashes and maps them to their contents. When serving a resource rather than serving it by name, we create a URL that has the hash. For example, if the hash of logo.png i

  17. SlowChrome by Anonymous Coward · · Score: 0

    Does it still take 10 million years to just open Chrome?

  18. Verified by SuperKendall · · Score: 1

    I can confirm that doing nothing at all on a Facebook page takes 72% of your time.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  19. Not this again by WaffleMonster · · Score: 2

    Engineer A: Lets re-interpret intent to make it faster
    Engineer B: Lets re-interpret intent to make it current
    GOTO A

    The history of HTTP cache headers are filled with this same contention between different people trying to reinterpret the meaning of words to further their narrow agendas.

    This crap always ends with everyone having a headache without solving anything.

    If you want to make reload better try adding mechanisms to explicitly signal intent so it can explicitly be acted on rather than hacking shit to make it work better for *you* because you can.

    1. Re:Not this again by DamonHD · · Score: 1

      I don't think that that's entirely fair.

      Sometimes, only through extensive use in a huge variety of use cases, does it become clear that the previously-thought-simple 'cache for a bit' needs rather more nuance...

      Can this be cached only if public?

      What if a different language was requested the second time?

      What if different content encodings are acceptable to my next cache user?

      Can I continue to show a slightly stale copy for a while rather than failing completely, and if so how long?

      Can I see if the meaning of this page is unchanged and show it from cache, even if some unimportant aspects have changed (such as ads)?

      These are all real cases, and I've sweated over the code and HTTP headers to get them right, and it can make a real difference to perceived response and actual resources consumed.

      Rgds

      Damon

      --
      http://m.earth.org.uk/
    2. Re:Not this again by Anonymous Coward · · Score: 0

      To add to this caching is a total mess. https saw to that. So now you can not use a decent proxy server to cache things unless you create a global cert and put it everywhere.

      Then to add the spec only lets you make 2 requests per server at a time. So you haves sites serving dynamic pages just so they can inline a.server.com and b.server.com so they can speed up loading and get 'free load balancing'. The cache sees objects from each server as totally unique. So you end up downloading things twice or more many times. When it could be served from cache. They would be better to revamp the caching controls like you point out and building in a way for the browser to assist in load balancing. Some sort of tag that says 'a.server.com' and 'b.server.com' are the same thing. Then maybe a way of saying to the browser when you see 'server.com' use 'a.server.com and b.server.com but evenly please'. So instead of pages that look static they are *all* dynamic to serve up what is static content from multiple servers that are all the same thing. Yet the browser has to play dumb and pretend that it is not the same.

  20. Here's an idea to cut down on requests by viperidaenz · · Score: 3, Interesting

    Add the ability to put an ETag in the HTML document along side the resources, so the browser doesn't have to make a conditional "if-none-match" request to check if it is stale.

    <img href="blah" etag="12345" />

    1. Re:Here's an idea to cut down on requests by Anonymous Coward · · Score: 1

      <img href="blah?v=12345" />

      done.

    2. Re:Here's an idea to cut down on requests by Anonymous Coward · · Score: 0

      Or how about displaying the page with the cached content and then checking for updates in the background and replacing stuff as it comes back? Also check the stuff that's currently visible first.

  21. Awesome! by jetten · · Score: 1

    Great now I get to the 6 minute long "Waiting for cache" message 28% faster!

  22. Nice but.. by Neuronwelder · · Score: 1

    Can you read 28% faster??

  23. that it has worked with Facebook by frovingslosh · · Score: 1

    I'm not a Facebook member. I never will be. Yet when I load pages from almost anywhere on the web I can detect background traffic to Facebook (unless I explicitly block traffic to Facebook in my HOSTS file). Facebook has absolutely no right to know what I'm doing on sites as diverse as my local TV station, Slashdot and Linux support sites, yet that traffic is considerable and can't help but affect my Internet performance. I bet they could have made Chrome work even faster if they blocked traffic to Facebook completely or at least gave users the option to not send information to Facebook.

    --
    I'm an American. I love this country and the freedoms that we used to have.
    1. Re:that it has worked with Facebook by TranquilVoid · · Score: 1

      Facebook has absolutely no right to know what I'm doing on sites

      I'm sure you know this, but what's happening is that these sites you visit have an agreement with Facebook, and write/use code to share this information. They certainly have a right to do this (not that I like it, and in fact use an Adblock filter to strip Facebook from all non-Facebook sites).

  24. Hosts files make any browser TONS faster by Anonymous Coward · · Score: 0

    See subject: 2 ways (adblocking + hardcoded favorites). For best possible hosts file APK Hosts File Engine 9.0++ SR-5 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/

    Ads & malware rob speed, security & privacy

    Hosts add speed (hardcodes/adblocks), security (bad sites/poisoned dns), reliability (dns down), & anonymity (dns requestlogs/trackers) natively

    Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus + less security bugs/complexity

    APK

    P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/

    1. Re:Hosts files make any browser TONS faster by Ash-Fox · · Score: 1

      Cease and desist these criminal activities, APK. You already know you are in violation of the Computer Fraud and Abuse Act and your persistence in this is involving us in your criminal acitivies along with damaging Slashdot as they constantly make the lameness filter more overbearing to deal with your posts.

      --
      Change is certain; progress is not obligatory.
    2. Re:Hosts files make any browser TONS faster by bioteq · · Score: 1

      My God, I cannot wait until the day we all read on Slashdot (no doubt, it will be posted on the front page, I assure you!)

      "Alex, the one known as the "Super Fag" APK, has been found dead today in his home from an apparent intestines puncture. It would seem Mr APK was forcing what is known as a 'fake horse cock' up his rectum, which resulted in his colon and intestines being perforated and, ultimately, causing him to bleed out. He shall be missed greatly in this world as is known as "THE BEST SOFTWARE WRITER EVER" due to his AMAZING invention KNOWN AS THE HOST FILE. Who will ever take up his mantle now?

      More on this horrific story at 11!"

      I'll have you all now though, be careful using his "WaReZ" that he's pushing. Be sure to step through some IDA or something else, first. You'll be shocked when you find out what his software is doing behind the scene. Talk about 'soul'd out! (as he says)'

    3. Re:Hosts files make any browser TONS faster by Anonymous Coward · · Score: 0

      See my subject: Can't accept you'll never be able to have wares hosted & recommended by malwarebytes as I have?

      Can't accept you're what my subject says you are (a jealous "ne'er-do-well" with insufficient skills to write code as good as I do??

      (Truth hurts, doesn't it, loser???)

      FACTS: Malwarebytes Steven Burn verified my code as SAFE + it's clean by 57++ antiviruses loser https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/

      APK

      P.S.=> You're a pitiful little trolling FAKE NAME nobody loser online as all you have is your FAKE LIFE (since you KNOW you're nothing but a stupid loser nobody & always WILL be, lol)... apk

    4. Re:Hosts files make any browser TONS faster by bioteq · · Score: 1

      I don't care what malwarebytes said or some retarded online virus scanner. I've seen your code and I've seen what you're doing. You may want to come clean, or I'll start releasing it.

      And I'm not trolling you. I also have quite a nice life, Thank you very much. I, unlike you, don't have to spam Slashdot all day like you to feel 'wanted' (Hint: No one likes you.)

      You put people down when you start to feel inadequate. Your mental illness is so blatantly obvious that it hurts. Why don't you try posting as a real account for once, loser. Or did mommy not breastfeed you enough?

    5. Re:Hosts files make any browser TONS faster by bioteq · · Score: 1

      P.s. Fake name? Says the little fat retard hiding behind the AC name.

      Pitiful attempt, Alex.

      My name is Mike. I have no need to hide my name. I actually have a set of balls that work, unlike you.

  25. Fastest & most efficient adblocker? by Anonymous Coward · · Score: 0

    Hosts files (what you have natively already as part of the IP stack). For best possible hosts file APK Hosts File Engine 9.0++ SR-5 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/

    Ads & malware rob speed, security & privacy

    Hosts add speed (hardcodes/adblocks), security (bad sites/poisoned dns), reliability (dns down), & anonymity (dns requestlogs/trackers) natively

    Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus + less security bugs/complexity

    APK

    P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/

    1. Re:Fastest & most efficient adblocker? by Ash-Fox · · Score: 1

      Cease and desist these criminal activities, APK. You already know you are in violation of the Computer Fraud and Abuse Act and your persistence in this is involving us in your criminal acitivies along with damaging Slashdot as they constantly make the lameness filter more overbearing to deal with your spam.

      --
      Change is certain; progress is not obligatory.
  26. Link to Technical Specifics by Anonymous Coward · · Score: 0
    Chrome team:
    https://blog.chromium.org/2017...

    Sadly, there weren't many technical details there. Facebook however had an excellent writeup:
    https://code.facebook.com/post...

    There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply

    This seems like a reasonable change. Now I can sleep better without having to worry about a million calls tomorrow about "your web-based product no longer works in Chrome".

  27. Re:Out of memory by hackwrench · · Score: 1

    https://support.microsoft.com/...
    Out of memory problems are because Microsoft is stupid. I don't know what Microsoft should really be doing but using the information at that link helped lots.

  28. 28% faster than what, exactly? by Anonymous Coward · · Score: 0

    28% faster than the previous release? 28% faster than 5 releases ago? 28% faster than what they expected? 28% faster than an an artist trying to draw the page by hand?

  29. LOL - being on topic w/ hosts that work? by Anonymous Coward · · Score: 0

    See my subject Ash-Fox: You WISH you could be such a 'criminal' being on topic (you're not) w/ a program that helps as mine does!

    * :)

    APK

    P.S.=> Take your meds, loony bird... apk

  30. LOL - being on topic w/ hosts that work? by Anonymous Coward · · Score: 0

    See my subject Ash-Fox: You WISH you could be such a 'criminal' being on topic (you're not) w/ a program that helps as mine does!

    * :)

    APK

    P.S.=> Take your meds, mr. loony bird... apk

  31. RoTfLmAo (got a 'rise' outta you w/ truth) by Anonymous Coward · · Score: 0

    See subject: Sure "you've seen my code" (only 1 who has is Steven Burn of Malwarebytes who felt it's good enough to host & recommend above others like it (he rated hostsman as good but it doesn't do all mine does (hardcoded favorites where you spend most time online, resolving FASTER from local system RAM, faster than remote OR EVEN dns on a network (no network traversal @ all is why) + mine's NATIVE 64-bit, hostsman isn't!)).

    * Hohohoho... you can't even SHOW US ANY OF YOUR OWN!

    By the way - those antivirus scanners that show my ware's clean? They're more reliable than YOUR bullshit by FAR!

    APK

    P.S.=> You tried putting ME down w/ lies 1st stupid & you're just a "ne'er-do-well" that OBVIOUSLY JEALOUS that the highly esteemed likes of Malwarebytes folks host + recommend my work! I've got far more impressive stuff I've done in computing than that but even THIS program's more than YOU can ever, EVER do (& you know it)... apk

  32. Dear "Jealous Mike": I use my initials &? by Anonymous Coward · · Score: 0

    See subject: My names in my work (most here & online DO know my FULL name & accomplishments (you'll never be that well known... why? YOU CAN'T ACCOMPLISH SQUAT is why, but you SURE TALK A LOT OF "BLOWHARD HOT AIR" lies though, lol!)).

    * You're welcome to prove otherwise & show you've got YOUR code, all yours (not 'opensores' plagiarism), doing as well as even this freeware of mine has (Malwarebytes' hosts & recommends my work - do they YOUR 'non-existent vaporware'? Oh, HELL no, lol...))

    By the way: I'm 6' 2" & 210 lbs. even @ 52 & a former 1st string NCAA lettering athlete for a national power in the sport of Lacrosse too (not fat @ all, but it's just more "jealous mike" (lol) lies from you is all!)

    bioteq's your REAL NAME liar? BS... it's a FAKE NAME for your FAKE LIE OF A LIFE (& you know it).

    APK

    P.S.=> Some 'balls', lol - I see you SAY you have my sourcecode? Mr. Steven Burn of Malwarebytes has SEEN my code AND verified it as safe (it's extremely WELL written, as I've been in the art & science of computing doing well in commerial software, tradeshows, publications in this field etc. for ages... have you "Jealous Mike"? Oh, HELL no, lol!)... apk

  33. firefox by Lehk228 · · Score: 1

    so they have been doing a shift-refresh for every refresh?

    --
    Snowden and Manning are heroes.
  34. And Facebook seems to be an a*hole for browsers by allo · · Score: 1

    The original article quotes a facebook article, which speaks about reducing requests by using cache with long expire headers.

    Their approach: expire header for one year, filename with a content hash.
    This means, facebook spams your browser cache with data, which will never be accessed again after they changed it, just to reduce the number of "if-modified" requests.