I had an interesting bug combining InstantClick with Clicky.com (a GA stats tracking alternative).
Clicky dynamically adds a JS file to the header so it's asynchronous. It does the same every few minutes to poll and indicate someone's still on the page.
When used with InstantClick, the first tracking request worked fine. But when I clicked - the first AND second Clicky tracking request were sent. Another click meant 3 new requests were sent.
It puzzled me for a minute, before I realized. Clicky's JS didn't have InstantClicks' data-no-instant attribute, so all previous tracking scripts were being re-loaded with every click.
The fix is to push the tracking requests to Clicky manually via InstantClick's on change callback. Then I used JQuery to add the data-no-instant attr to all the clicky script tags in the head:
InstantClick.on('change', function() {
clicky.log(location.pathname+location.search, document.title, 'pageview');
// now stop any clicky scripts from being re-requested each time the page is insta-reloaded, to stop wasted tracking requests
jQuery("head script[src*='clicky.com']:not([data-no-instant])").attr('data-no-instant', true);
});
The same might happen with Google Analytics if you're using it asynchronously, but I've not tried that.
Hope this helps someone if they see the same weirdness.
Interesting to see the differences between InstaClick and Pjax.
InstantClick
- InstantClick is a little easier to implement, with nothing required server-side
- InstantClick works to reduce latency by prefetching page content on hover.
- InstantClick always replaces the body's outerHTML
- InstantClick provides a YouTube style loading progress bar
Pjax[1]
- You specify specifically which page element is replaced (using the ID)
- You set up your app to return only the required page fragment on ajax calls
- No loading bar is included, but can easily be added
- Content is not prefetched on hover
I think I still prefer the pjax approach because it sends less data over the wire. However, would be interesting to see a hybrid of the two approaches.
Also worth noting that both essentially turn your site into a single-page app that updates the browser URL bar using pushState. Both approaches also degrade nicely.
Not sure how it works now but shouldn't Apple/Google just disable that delay if your viewport is already set to device-width? It's not like you're going to double-tap to zoom in any further.
You're thinking of fastclick. This is different, it's page prefetching so that you start loading the page before the UI event that would normally start loading it happens.
When Youtube started to do this "custom progressbar", now my Chrome history is inconsistent, when I type something and open the related history item, a completely different web-page comes. Please, if you are intending to do this, do it correct, don't break the expected behaviour of a browser.
FastClick removes the 300/450 ms delay and makes your click trigger right after touchend, InstantClick makes use of this delay (plus the delay between touchstart and touchend) to preload the page.
Yeah, for a website with 2 seconds or more load time, instantclick will probably only help remove 100-200ms. Still worth it, but not a huge improvement. There will be lower hanging fruit.
Where this library shines is if you already have a decent, fast-ish website with ~500ms load times. This can bridge that final gap and make it look like the whole site is loading in a flash. Amazing to see in practice. It's more the fact that the page layout can be computed before the page changes. it makes a huge difference in perception.
Clicky dynamically adds a JS file to the header so it's asynchronous. It does the same every few minutes to poll and indicate someone's still on the page.
When used with InstantClick, the first tracking request worked fine. But when I clicked - the first AND second Clicky tracking request were sent. Another click meant 3 new requests were sent.
It puzzled me for a minute, before I realized. Clicky's JS didn't have InstantClicks' data-no-instant attribute, so all previous tracking scripts were being re-loaded with every click.
The fix is to push the tracking requests to Clicky manually via InstantClick's on change callback. Then I used JQuery to add the data-no-instant attr to all the clicky script tags in the head:
The same might happen with Google Analytics if you're using it asynchronously, but I've not tried that.Hope this helps someone if they see the same weirdness.