Safari trying to pre-load URLs?

Discussion in 'OS X Mavericks (10.9)' started by lylebot, May 21, 2014.

  1. lylebot macrumors newbie

    Joined:
    May 21, 2014
    #1
    This is something I never would have noticed, except that I'm doing some web development and saw strange behavior in my logs that seemingly has no other explanation.

    Safari auto-completes URLs being typed into the address bar---this is obvious. Less obviously, it seems that immediately upon suggesting an auto-completion, it starts loading that URL from the remote host. It doesn't actually show me anything in the browser until I hit return, but according to my logs on the remote host, it is definitely hitting the remote host with the exact URL it suggested to me.

    Can anyone verify that this is the case? Or is it possibly a bug on my end?
     
  2. GGJstudios macrumors Westmere

    GGJstudios

    Joined:
    May 16, 2008
    #2
    Safari > Preferences > Privacy > Smart search field: > Do not preload Top Hit in the background (check this)
     
  3. lylebot thread starter macrumors newbie

    Joined:
    May 21, 2014
    #3
    Thanks a lot!

    I have to say I'm a bit surprised that is the default behavior! In my case it could put quite a bit of extra (and totally unnecessary) load on my server.
     
  4. scaredpoet macrumors 604

    scaredpoet

    Joined:
    Apr 6, 2007
    #4
    FWIW, it's not that surprising considering Chrome and Firefox do this to some extent as well. IE 9 doesn't, though it does pre-fetch DNS entries for a slight performance increase.

    Link prefetching is a standard being proposed by the Mozilla Foundation:

    http://en.wikipedia.org/wiki/Link_prefetching

    As for how much load this puts on a server: for the most part, most modern web servers and their hosting ISPs are long past the point where every byte counts as much, unless you're on a VERY old server and on a VERY old hosting plan. A Terabyte of monthly transfer can be had for $5 a month, along with a competent virtual server to go with it. Even the functional equivalent of a recent-vintage iPhone can handle the load without breaking a sweat.
     
  5. lylebot thread starter macrumors newbie

    Joined:
    May 21, 2014
    #5
    I'm sure this is true in general. In the particular application I'm developing, every URL request starts background processes that do quite a bit of intranet and disk I/O on the server. I'm just a dude doing research at a university, so I can't afford dedicated hardware for this. On the plus side, that means I also don't have a lot of users, so it won't be a frequent thing. I'd just like to avoid tons of unnecessary server-side I/O if possible, and I was surprised to see that my testing was causing so much more than I anticipated.
     
  6. leventozler macrumors 6502

    Joined:
    Feb 18, 2009
  7. lylebot thread starter macrumors newbie

    Joined:
    May 21, 2014
    #7
    Yeah, in my research on this problem I have not come across a term that matches what Safari is actually doing. Neither "prefetching" nor "preloading" captures it, at least according to the technical definitions.

    To be totally clear: Safari is sending requests for URLs that I am not going to visit. It doesn't show me the results of these requests. It's requesting them solely because they are the top hit in auto-complete.

    This doesn't seem to match the idea of "preloading" (which, if I'm not mistaken, involves loading page resources such as CSS, JS, and images that are not immediately needed for rendering the page) nor "prefetching" (which apparently has to do with the page author giving the browser hints).
     
  8. leventozler macrumors 6502

    Joined:
    Feb 18, 2009
    #8
    Prefetching gets a single document or resource. Preloading (also called prerendering) gets the document & resources, executes the javascript etc.

    Safari does preloading just like Chrome, it also requests images on the page. (I haven't tested javascript execution)

    BTW, Chrome used to preload the first result in Google SERPs too.
     

Share This Page