1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Implement preconnect to reduce latency for modern browsers

Discussion in 'XenForo Suggestions' started by Mouth, Dec 20, 2015.

  1. Mouth

    Mouth Well-Known Member

    The preconnect relation is used to indicate an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high latency costs of establishing a connection.

    To initiate a preconnect, the user agent must run these steps:

    1. Resolve the URL given by the href attribute.
      1. If that is successful, let preconnect URL be the resulting absolute URL, and otherwise abort these steps.
      2. If preconnect URL's scheme is not one of "http" or "https" then abort these steps.
    2. Let origin be preconnect URL's origin.
    3. Let corsAttributeState be the current state of the element's crossorigin content attribute.
    4. Let credentials be a boolean value set to true.
    5. If corsAttributeState is Anonymous and origin is not equal to current Document's origin, set credentials to false.
    6. Attempt to obtain connection with origin and credentials.
    The user agent should attempt to initiate a preconnect and perform the full connection handshake (DNS+TCP for HTTP, and DNS+TCP+TLS for HTTPS origins) whenever possible, but is allowed to elect to perform a partial handshake (DNS only for HTTP, and DNS or DNS+TCP for HTTPS origins), or skip it entirely, due to resource constraints or other reasons.

    The optimal number of connections per origin is dependent on the negotiated protocol, users current connectivity profile, available device resources, global connection limits, and other context specific variables. As a result, the decision for how many connections should be opened is deferred to the user agent.

    Ref: http://w3c.github.io/resource-hints/#preconnect
    matthewalan, Pierce, Teapot and 6 others like this.
  2. Fred.

    Fred. Well-Known Member

  3. PumpinIron

    PumpinIron Active Member

    I second this suggestion!
  4. Arty

    Arty Well-Known Member

    Idea sounds very cool, but what content on forum can benefit from this?

    Loading external scripts/stylesheets is already done instantly when browser reaches them in head section, so preconnect probably won't do any good there.

    What else is there? Dynamic scripts loaded on demand from external sources would benefit most from this, but XenForo doesn't have those.
  5. Fred.

    Fred. Well-Known Member

    It can Preconnect to your CDN and all other external CDN's (Facebook, Font Awesome, jQuery)
  6. Arty

    Arty Well-Known Member

    On this page there are few external scripts:
    jquery from ajax.googleapis.com
    DNS resolution: 0ms
    Connecting: 4ms
    analytics from www.google-analytics.com
    DNS resolution: 0ms
    Connecting: 4ms
    Some avatars from gravatar
    DNS resolution: 0ms
    Connecting: 0ms
    G+ from plus.google.com
    DNS resolution: 0ms
    Connecting: 3ms
    Facebook from connect.facebook.net
    DNS resolution: 0ms
    Connecting: 3ms
    Twitter from platform.twitter.com
    DNS resolution: 0ms
    Connecting: 3ms
    and few other domains that are requested from scripts loaded from other servers, so those aren't coming from forum.

    From external links that are under forum controls, maximum connection delay is 4ms. Those domains are used on many websites, so chances are dns is already cached and that's why it is showing 0ms in my test. Those websites are using cdn, so connection time is very fast regardless of where client is.

    Preconnect will save at most 4ms. Is it really worth hassle?
  7. Fred.

    Fred. Well-Known Member

    Well, it's 5 times 4ms and I'm happy with every ms.
    I guess it's different for everyone, my page has several js and it usually loads in 500 - 600 ms (but I implemented pre-connect where I could)

    Where do I find those stats in GA? :confused:
  8. Arty

    Arty Well-Known Member

    Its not. Those connections are parallel, not sequential.

    Its not loading time, its connection time that is affected by preconnect. Loading time is mostly waiting for server response, preconnect doesn't change that.

    You can find those stats in network graph in browser's developer tools.
  9. Fred.

    Fred. Well-Known Member

    If your on http/2 they are parallel but not everyone is on http/2 yet. With http 1.1 it just adds up. That's how I understand it.

    Yes, connection time is included in the pingdom tests. 500-600 ms total, some things take 74 ms connection time!
    FB,Twitter seems to be fast now. but not always...
  10. Arty

    Arty Well-Known Member

    Actually, I'm partially wrong on that one. Some of those links are scripts that aren't async, so they are blocking load of other parts, which means those few connections do add up.

    Then it might be a good idea. Or make those scripts async.
    http/2 has nothing to do with it. http/1 limits connections to one server, preconnect connects to different servers.
    Fred. likes this.
  11. Fred.

    Fred. Well-Known Member

    Ok, thanks for the explanation. I understand now. Yes, if they would be async it would improve things.
    I can't find those stats in GA, my GA account is probably different...
  12. CyclingTribe

    CyclingTribe Well-Known Member

    Whilst there will be some common domains such as google-analytics.com and ajax.googleapis.com I would expect the rest of the domains will be different for each site.

    I've been using it for a while on my own sites via PAGE_CONTAINER <head>. I first checked for URLs / domains where multiple resources were requested each page load [using webpagetest.org > Domains result data] (no point in a preconnect to fetch a single resource) and then I also added a <xen:if is="!{$visitor.user_id}"> for guests since they are shown Adsense ads which utilises doubleclick.net and googlesyndication.com and other domains. I tested afterwards and checked the waterfall to ensure the preconnect was working and that there was just one DNS lookup for the first requested resource. (y)

    I suppose from an XF perspective, if there are external resources being used as part of the core and preconnect can help shave off a few ms page load, then why not?! :)

Share This Page