Mouseover Prefetch?

A friend called me randomly on Sunday to tell me a story. He said that a schoolkid had invented a system for cars which automatically started applying the brakes if you took your foot off the accelerator really quickly, implying that you were about to do an emergency stop. Because the brakes were now applied faster, a speedup of the time it takes to transfer your foot from one pedal to the other, this change saved 50 yards of stopping distance at 70mph. And I agreed it was a great idea, and I wished I’d thought of it first :-)

But then he said: why can’t we do the same thing with web browsers? When someone’s mouse mouses over a link, why can’t we start to prefetch it – either DNS prefetch (if we don’t automatically DNS prefetch all links on load; the docs aren’t quite clear on the policy) or even main HTML page prefetch? This would save the amount of time between the mouse coming over the link, and us registering the click (which is at mouseup, not mousedown). I know I pause over links, so the speedup could be significant.

Now I know prefetching which is not explicitly requested by the page (e.g. using <link> tags) has had issues in the past. But FasterFox still seems to do it, so it can’t break all that much of the web. (He says, naïvely.) Is the problem solely one of bandwidth? Or can some web apps break in this case, if we prefetch a link the user doesn’t actually end up requesting? And are those apps just badly coded? Would this idea fly?

22 thoughts on “Mouseover Prefetch?

  1. You’d possibly break a lot of one-click file hosters and similar services when doing http prefetching, depending on how this is implemented.
    Many return links that are valid exactly once. This is usually done by adding some hash/magic-value to the link or using cookies which get deleted again upon access of the “protected” resource. The former is far more widespread (at least when it comes to one-click hosters).

    I don’t think that DNS prefetching would hurt, however.

  2. I do not believe that web sites would appreciate their bandwidth being wasted on what amounts to someone highlighting links before they decide which link they actually want to click.

    Of course this does not apply to a user that knows where he/she wants to go from the start. Prefetching as far as I am concerned is a waste of memory which is something MoFo can not get right in Fx as it is.

    Mozilla needs to get back to the basics and lose all of this expirmenting nonsense. Considering I can not even use Fx v3 series for online banking I am one step away from dropping Fx entirely.

    Tb is such a mess that I already dropped it for Outlook which just plain works.
    Even Opera’s email is lite on resources and works.

  3. I’ve thought about this before. It initially seems like an easy win, but I think there are quite a lot of potential problems when you look deeper. What if I just move the cursor to the side so that it’s not covering the text I want to read, but it just happens to land over a banner ad that starts downloading a large page? It’s edging me closer to my bandwidth cap and adding to the RAM footprint, as well as potentially fetching some cookies etc. that I’d rather not have. DNS prefetching seems fine though, but as you say, not sure if this is happening already or not.

  4. BMW (and probably others) already have an available braking system as described. It doesn’t automatically apply the brakes, but apparently just pretensions the brakes when you jump off the accelerator. I’m not sure I would want my vehicle to slam on the breaks if I take my foot off the gas a little too quickly!

  5. FasterFox did it, but it generated a huge amount of hatred in the process (and hasn’t been officially updated for Firefox 3, so I imagine the number of people using it has fallen a lot).

    It sounds like Firefox would be doing a lot of work (after some people doing a lot of coding work) for a small gain. With a 3 year old computer and 8Mb broadband, there are already a lot of times when Firefox is being limited by my CPU and/or hard drive speed (taking 40 seconds to load, for one thing), so I would think that there are improvements that would be easier to make and give greater benefits.

    I’m not entirely sure, but my impression from the bug comments (linked from the blog post that is linked from that document) is that, except when using https, DNS prefetch is now done for all the links.

  6. You do not want to prefetch HTTP.

    Do you remember Google’s Web accelerator, from 2-4 years ago? It prefetched links. It got a very bad reputation.

    The simplified version of the problem: there are web apps that had “Delete” links. Google web accelerator prefetched all the “Delete” links, and people became very sad when their databases became empty as a result of GWA pre-clicking all the “Delete” links.

    Becoming a little more detailed, yes, you and I know that the HTTP spec says that “GET” requests MUST NOT change server state. Therefore GWA should in theory be safe if it only prefetches GET requests, never POST requests. The problem is… people violate the spec. They write custom in-house pages where GET requests change server state.

    If Firefox pre-fetched HTTP pages, you know that someone will use it with an in-house web app, and your prefetch code will delete all their customer records, and who is going to get the bad rep?

    Firefox will.

  7. Doing DNS prefetch in that situation might be ok.

    Prefetching the link content would in fact break apps. For example, the “log out” action tends to be a link (quick survey shows that Zimbra, Bugzilla, Amazon, all of my banks, all have it as a link).

    While in theory the HTTP spec says that GET SHOULD NOT carry out actions “which may have an unexpected significance to themselves or others”, in practice even well-coded apps only assume idempotence for them (see the logout links above). And poorly-coded web apps will have links that delete database records, etc. That might even be idempotent, but really not in the spirit of the RFC…. The logout thing might even be in the spirit of the RFC.

  8. Let me come from a bit security-paranoid point of view. Given fast internet speeds of today, a win of less than a second in browsing time does not justify a potential laundry list of issues that such change will bring. At the top of my list is privacy. Right now, unless I click on a link, that link is not visited and no cookies/visit history are generated. If automatic link prefetching would come into existence in FF, there should be a way to disable it.

    In general, all background “automagic” makes a web application non-obvious for the end user, and at the same time brings up a question of trust and company perception.

  9. Some sites definitely break – my bank’s site for starters, since that seems to be quite heavy on session state, and can’t handle multiple windows/tabs, never mind something like this. And like others said, in some cases, prefetching is outright dangerous…

    Besides, I can imagine this having serious impact on server load…

  10. I think everyone pretty much hit the issue right on the head. While there’s a performance gain, it’s also a major hit on websites between bandwidth and capacity costs. I’m not sure if it’s a good citizen behavior. This may not sound like much of an issue on a small scale but with high traffic websites these seemingly small changes can have vast and sudden changes to your web server farm’s load.

  11. Because, you know, people never move the mouse randomly over the page? How about hovering over a link in order to see the URL and/or title attribute?

    On a related note, I remember the first time Opera introduced mouse gestures. I would spend a lot of time clicking “No”. As in, “No, I did not perform a mouse gesture intentionally, and I don’t want you to enable mouse gestures.” Thankfully, they changed that behavior quickly.

    Software should never, ever second-guess the user.

  12. I don’t think the bandwidth impact would be that bad, because you usually click a link once you’ve hovered it. But I agree, if it breaks web apps, that’s very bad.

    However, we should check and see whether we can do DNS prefetching in this case, if we don’t already. We already have the code for that, so it shouldn’t be a big change.

    Gerv

  13. I’d like to see some statistics on how long do people hover over a link before clicking it. And how many links do they mouse over (longer than a given time) that they do not click in the end. If someone made an extension for collecting this data, I’d definitely try it, simply out of curiosity.

  14. There are many examples of such braking systems, quite a lot of them end up causing more problems than they save. One car company invented a system where if you braked sharply, and a few other factors were involved, then it would do an emergency stop for you. It ended up causing more accidents than it stopped.

  15. I’m pretty sure that Google Chrome does DNS prefetching, though I’m not sure of the exact heuristics they use to decide when to do it or not.

  16. I don’t think the bandwidth impact would be that bad, because you usually click a link once you’ve hovered it. But I agree, if it breaks web apps, that’s very bad.

    Lots of people seem to read online content while moving their cursor… wouldn’t this be somewhat problematic loading url’s embedded into text?

    The other issue is analytics. If your prefetching your falsely inflating many sites analytics. This can be worked around with more advanced JS based methods, but you ruin that baseline of JS disabled and non-webkit mobile users.

  17. The problem is HTTP GET idempotency semantics are not always followed. Many websites will include a Delete (delete) hyperlink which performs a GET request.

    Now, these websites with idempotency issues are either intranet sites or are hidden behind user authentication mechanisms. Both of these prevent search engine robots from navigating the hyperlink and causing damage.

  18. Unless something’s changed recently, DNS prefetching is already performed on links as the page is rendered (no need to hover over the link). It’s also performed on images and external scripts/stylesheets (which does apparently improve performance because the concurrent connection limits often mean that such things can’t be downloaded immediately).

    Google Chrome also does DNS prefetching (implemented before it was added to Mozilla) but their implementation works slightly differently.

    As for prefetching complete pages, I think it would Break the Web due to non-idempotent GET links.

    Even if everyone followed the HTTP specs, I imagine bandwidth would be an issue. I’m not sure if it’s true that “you usually click a link once you’ve hovered it”. Even if it is, you would probably want to avoid prefetching links that the cursor passes over just momentarily, which would probably mean only prefetching links that are hovered over for at least a minimum amount of time. However, that may mean that by the time you’ve already decided to prefetch, the link has already been clicked (or will be within a few milliseconds, eliminating most of the benefit).

    It would certainly be interesting to investigate though. You’d want to do studies to determine answers to questions like: What proportion of hovered links are clicked? How long do users hover over links before clicking? If they hover over a link for longer, are they more likely to click? Do these factors apply equally across all link types (text versus image etc.)? Are the savings worth it in any case?

    Finally, as an employee of an Internet advertising company, I should probably stress that widespread prefetching would play havoc with our clickthrough statistics!

  19. So long as links are marked as explicitly prefetch-able, then this would be fantastic. In any other case, absolutely not.

  20. I think I actually click on about 5% of the links my mouse pointer passes over, and if I hover for a longer period of time, I suspect the percentage goes down; in most cases, if I wanted to click, I’d have done it in the first half a second or so.

    Combined with what happens to Firefox’s responsiveness when it’s retrieving several pages at once, I am pretty sure this would be a net performance loss. It’s a neat idea on the surface, but I don’t think it will stand up to real-world conditions very well.

  21. I’ve already done what you suggest — it’s on userscripts.org. It works with a shift key + mouseover or 5 mouseovers to load into a hidden iframe. It is a “targeted” prefetch. Depending on the page contents, it saves some time.

    Doesn’t work well if every mouseover prefetches, and it isn’t that fast on a DSL line. But every now and then it comes in handy.