Not sure what exactly that Google thing does, but that instant page is very easy and logical. I think such think may be included, however I wouldn’t add such a big priority for that.
Thanks for working on AO :)
If it’s running only on the website itself it’s less of a problem. I would be still reluctant, because I then have to chech updates more carefully. The idea of instant page running on the own website does seem promising though.
After looking at the functionality I do like “instant page” way more. If I do understand it correctly it only prefetches when the cursor is a short time above a link. The Google js seems to prefetch everything that’s inside the viewport, which seems a lot more. Off course a lot will be cached after the first prefetch (I do suspect that most pages have quite a lot of links in common (for example a menu bar).) It could give more peak demand to the server.
BTW. I use prefetch on a contained image from a very likely “next page”, but this is automaticaly generated content. It’s not so easy to do and not inside js, because the content of the page in the link is not known to the js. (It is know server side.).
I think it’s a good idea, but I’d leave it off by default or have a disclaimer, just in case. The comments over at Hacker News (https://news.ycombinator.com/item?id=19122727) on instant.page are mostly positive (more so than the Google version that preloads everything), but a concern was brought up that I had thought of, too: Server load. While it’s only going to load a page in the background if you hover over the link for a bit, working in IT tech support, I see a LOT of folks who read with their cursors, moving the mouse cursor slowly over content and links. While moving your mouse away from the link will stop the client-side from making the request, that doesn’t mean the server suddenly is going to stop processing the request, the database isn’t going to stop processing the request, etc… . It may be negligible, but if could be a decent bit of load on hosts that over-provision their stuff (which has been known to happen far too often) and poorly-configured WordPress installs.
TL;DR – I’d lean more towards quicklink but make sure the features necessary are polyfilled.
I’m currently using quicklink – it’s a surprisingly useful feature!! One thing to consider though Frank:
quicklink has dependencies on:
Object.assign
IntersectionObserver
So you’d have to make sure that these are polyfilled (shameless plug:) which I currently do via a nifty little script: https://github.com/willstocks-tech/dynamically-polyfill-features-for-a-script which checks whether the features are natively supported, if they are – load it up. If they’re not, polyfill ’em and then load it up.
I don’t know whether quicklink is providing much benefit. Maybe for heavier sites, it will – but for mine, I don’t notice _that much_ difference in terms of navigation load performance for pages that have been prefetched.
I’m more inclined to lean towards quicklink because it’s respective of user options. For instance, quicklink will only fire if “Data Saver” is disabled on a device. Whereas I believe instant.page does not? I like Chris’ notes here at the end of this article: https://css-tricks.com/instant-page/
> You could argue that it doesn’t do the prefetching as absolutely responsibly as it could. Google’s similar quick link library (which we covered here) does two interesting things in which to attempt to be more responsible with prefetching: 1) wait for requestIdleCallback and 2) respects info from navigator.connection, like a user enabling data-saver mode.
I use instant click (http://instantclick.io) on my site. Not the easiest thing to set up (say: a nightmare) but finally I managed to let it work and the result is simply amazing.
One of the good things about instant click is in the same time also a bad thing: it not only preloads a page when you hoover a link, but will only load resources which were not loaded before (for instance: the scripts of most wp posts are always the same, so the script loads only what is changed, mostly html, pictures, analytic codes,…).
Sounds perfect, but in reality, it caused big head aches. And here comes the good news: the most important tool I used to fix things was autoptimize ;-)
Honestly, I don’t understand everything well, but the ‘also aggregate inline JS’ was a life saver. Unfortunately, I ended with Gb’s of extra files, and instant click loads them while strictly it should not be necessary, but it works and my site feels as fast as Google ;-)
So if you are looking for a way to improve autoptimize, I think you should have a look at this.
I’d never _deeply_ looked into instantclick (instantpage I’ve researched, but not instantclick) – but *wow*… it seems quite invasive and for a “standard WordPress user”, it would involve a fair bit of understanding as to what it’s doing? Not only that, but it’s reliant on being the same across all pages – I know mine isn’t always! Single posts, I enqueue assets only relevant to single posts (so I don’t bloat non-post pages), pages have their own assets too – contact form pages I only enqueue the assets relevant to that page.
Not only that, but replacing all *standard* browser events with its own… OR EVEN JQUERY’S?! That’d require a fair bit of work surely? I know you’re working on lazyloading as part of AO Frank – wouldn’t that mean a fair hefty set of rewrites just to cater for instantclick so that lazyload can still run??
It sounds like InstantClick is designed more for SPAs that have been designed to work with it from the ground up?
Yes, set up was not easy, especially because I had only a vague idea what I was doing (hobby site). But it works, it is only a pity that it seems that the developer walked away leaving you with absolutely no support – not even a decent manual.
Anyway, it was a challenge to do and I’m rewarded with a super fast website ;-)
No decision yet, but;
-> pro quicklink: backing of Google, takes navigator.connection into account
-> contra quicklink; backing of Google ;-) , prefetches a whole lot more (so potential server load issues), not as cross-browser unless polyfilled, but polyfilling makes the solution (slightly) more complex even with Will’s nice solution
I’m contemplating switching over to instant.page for a couple of reasons:
1. Only preloading what is _absolutely_necessary – not a tonne of pages that’ll potentially never be visited (both a waste on device cache/bandwidth + server)
2. Less overhead (debatable, but apparently is the case?)
3. I don’t see instant.page’s lack of navigator.connection respect being an issue, as it’s preloading a page in already about to click on/visit – so I’m not reallllllyyyy actually wasting resources/data?
4. The big G isn’t involved
re (2) and also (3); not entirely true as on mobile there is no mouseover and instant.page instead uses touch events and tries to *guess* the link by looking for the a-tag that is closest to the place of where the touch event happened. so I guess it’ll work better on desktop then on mobile.
Good point Frank! I hadn’t thought of those points
As a side note (I know it’s not drop-in, but this is quite interesting and I don’t think quicklink or instant.page does it this way in terms of page caching), I was reading an article (https://css-tricks.com/a-bit-of-performance/) which links to this post https://www.kizu.ru/a-bit-of-performance/ where the author attacked this sort of thing himself, rather than using instantclick, instant.page or quicklink – instead building his own version and utilising localstorage (and page navigation is pretty darn snappy!). I know it’s not a “simple drop-in” library but worth a look/thought as it’s pretty interesting/a good use of new technologies and saves recreation of page DOM on back/forward (I think)?
I’ll probably postpone adding quicklink/ instant.page until after AO25 Mk; there’s a number of potential issues with both solutions (some of which were discussed in the comments above) which I would like to see either proven irrelevant of fixed first :)
I think it is safe to use instant pages, which is from the same author as instant clicks (which I use on my site).
Extra load is minimal, and you can set a waiting time to preload so it will not start if you just move your mouse over it (at least with instant clicks).
It don’t think it will have any effect on mobiles: with instant Click you still have the benefit of loading only the new resources, but this you will not have with instant pages. Instead I use Fastclick to eliminate the time mobile browsers wait before moving to the next page (waiting time is necessary for double clicks)
After implementing it I had some kind of a luxury problem: html loads almost instant, but pictures not, so I looked for a way to preload the ‘above the fold pictures’ too.
I ended up with ‘base64 images’ (data url’s), so the image is included in the html and will automatically benefit from instant clicks. Did not manage to find a way to only include the above the fold images, so I had to include them all (they are small, so average page size is still < 350 Kb). Works really nice; you not longer see a page loading, but the (for the eye) complete page pops up mostly withing 500 ms after you clicked.
Only one draw back: there is not much left for CDN's to cache this way – Cloudflare dropped to around 4%. Currently playing with their 'cache everything option', so the html with the included pics will be cached again.
Hi Frank, I have been using instant.page and it’s great. Simplicity and causes no problems. I agree it could cause problems for people who have heavy, uncached site. In my case, with pages around 200~400kb and load times of around 300ms, on Nginx servers which can spit out heaps of pages, I see no problems. What I would love is for its JS to be able to be pulled to my server and get served from there, like “CAOS Analytics” plugin does with the Google Analytics JS. Is that how you might do it?
Not sure what exactly that Google thing does, but that instant page is very easy and logical. I think such think may be included, however I wouldn’t add such a big priority for that.
Thanks for working on AO :)
the google thing is very similar :)
I would not activate something from google, but instant page seems very useful.
Even if the JS runs on your own site and does not communicate with Google or any other 3rd party Alain?
Interesting, but do not forget the lazy load ;)
Lazyload is already in 2.5-beta Andrea :)
Frank
If it’s running only on the website itself it’s less of a problem. I would be still reluctant, because I then have to chech updates more carefully. The idea of instant page running on the own website does seem promising though.
Well, the Quicklink JS would not be sourced from Google, but be in the AO-distro itself and only update when AO updates :)
Frank
Thanks
After looking at the functionality I do like “instant page” way more. If I do understand it correctly it only prefetches when the cursor is a short time above a link. The Google js seems to prefetch everything that’s inside the viewport, which seems a lot more. Off course a lot will be cached after the first prefetch (I do suspect that most pages have quite a lot of links in common (for example a menu bar).) It could give more peak demand to the server.
BTW. I use prefetch on a contained image from a very likely “next page”, but this is automaticaly generated content. It’s not so easy to do and not inside js, because the content of the page in the link is not known to the js. (It is know server side.).
Alain
I think it’s a good idea, but I’d leave it off by default or have a disclaimer, just in case. The comments over at Hacker News (https://news.ycombinator.com/item?id=19122727) on instant.page are mostly positive (more so than the Google version that preloads everything), but a concern was brought up that I had thought of, too: Server load. While it’s only going to load a page in the background if you hover over the link for a bit, working in IT tech support, I see a LOT of folks who read with their cursors, moving the mouse cursor slowly over content and links. While moving your mouse away from the link will stop the client-side from making the request, that doesn’t mean the server suddenly is going to stop processing the request, the database isn’t going to stop processing the request, etc… . It may be negligible, but if could be a decent bit of load on hosts that over-provision their stuff (which has been known to happen far too often) and poorly-configured WordPress installs.
great feedback, thanks Jake!
Looks like a cool optional feature, as long as it’s optional and lightweight!
TL;DR – I’d lean more towards quicklink but make sure the features necessary are polyfilled.
I’m currently using quicklink – it’s a surprisingly useful feature!! One thing to consider though Frank:
quicklink has dependencies on:
Object.assign
IntersectionObserver
So you’d have to make sure that these are polyfilled (shameless plug:) which I currently do via a nifty little script: https://github.com/willstocks-tech/dynamically-polyfill-features-for-a-script which checks whether the features are natively supported, if they are – load it up. If they’re not, polyfill ’em and then load it up.
I don’t know whether quicklink is providing much benefit. Maybe for heavier sites, it will – but for mine, I don’t notice _that much_ difference in terms of navigation load performance for pages that have been prefetched.
I’m more inclined to lean towards quicklink because it’s respective of user options. For instance, quicklink will only fire if “Data Saver” is disabled on a device. Whereas I believe instant.page does not? I like Chris’ notes here at the end of this article: https://css-tricks.com/instant-page/
> You could argue that it doesn’t do the prefetching as absolutely responsibly as it could. Google’s similar quick link library (which we covered here) does two interesting things in which to attempt to be more responsible with prefetching: 1) wait for requestIdleCallback and 2) respects info from navigator.connection, like a user enabling data-saver mode.
very interesting Will, thanks!!
I use instant click (http://instantclick.io) on my site. Not the easiest thing to set up (say: a nightmare) but finally I managed to let it work and the result is simply amazing.
One of the good things about instant click is in the same time also a bad thing: it not only preloads a page when you hoover a link, but will only load resources which were not loaded before (for instance: the scripts of most wp posts are always the same, so the script loads only what is changed, mostly html, pictures, analytic codes,…).
Sounds perfect, but in reality, it caused big head aches. And here comes the good news: the most important tool I used to fix things was autoptimize ;-)
Honestly, I don’t understand everything well, but the ‘also aggregate inline JS’ was a life saver. Unfortunately, I ended with Gb’s of extra files, and instant click loads them while strictly it should not be necessary, but it works and my site feels as fast as Google ;-)
So if you are looking for a way to improve autoptimize, I think you should have a look at this.
Met vriendelijke groet,
Alex
interesting, but the caveats at described over at http://instantclick.io/how-it-works make me want to slowly walk away from the idea ;-)
I’d never _deeply_ looked into instantclick (instantpage I’ve researched, but not instantclick) – but *wow*… it seems quite invasive and for a “standard WordPress user”, it would involve a fair bit of understanding as to what it’s doing? Not only that, but it’s reliant on being the same across all pages – I know mine isn’t always! Single posts, I enqueue assets only relevant to single posts (so I don’t bloat non-post pages), pages have their own assets too – contact form pages I only enqueue the assets relevant to that page.
Not only that, but replacing all *standard* browser events with its own… OR EVEN JQUERY’S?! That’d require a fair bit of work surely? I know you’re working on lazyloading as part of AO Frank – wouldn’t that mean a fair hefty set of rewrites just to cater for instantclick so that lazyload can still run??
It sounds like InstantClick is designed more for SPAs that have been designed to work with it from the ground up?
Yes, set up was not easy, especially because I had only a vague idea what I was doing (hobby site). But it works, it is only a pity that it seems that the developer walked away leaving you with absolutely no support – not even a decent manual.
Anyway, it was a challenge to do and I’m rewarded with a super fast website ;-)
No decision yet, but;
-> pro quicklink: backing of Google, takes navigator.connection into account
-> contra quicklink; backing of Google ;-) , prefetches a whole lot more (so potential server load issues), not as cross-browser unless polyfilled, but polyfilling makes the solution (slightly) more complex even with Will’s nice solution
So I’m leaning towards instant.page for now.
Feedback still (and always) welcome :-)
I am for simplicity (instant.page).
I’m contemplating switching over to instant.page for a couple of reasons:
1. Only preloading what is _absolutely_necessary – not a tonne of pages that’ll potentially never be visited (both a waste on device cache/bandwidth + server)
2. Less overhead (debatable, but apparently is the case?)
3. I don’t see instant.page’s lack of navigator.connection respect being an issue, as it’s preloading a page in already about to click on/visit – so I’m not reallllllyyyy actually wasting resources/data?
4. The big G isn’t involved
re (2) and also (3); not entirely true as on mobile there is no mouseover and instant.page instead uses touch events and tries to *guess* the link by looking for the a-tag that is closest to the place of where the touch event happened. so I guess it’ll work better on desktop then on mobile.
Good point Frank! I hadn’t thought of those points
As a side note (I know it’s not drop-in, but this is quite interesting and I don’t think quicklink or instant.page does it this way in terms of page caching), I was reading an article (https://css-tricks.com/a-bit-of-performance/) which links to this post https://www.kizu.ru/a-bit-of-performance/ where the author attacked this sort of thing himself, rather than using instantclick, instant.page or quicklink – instead building his own version and utilising localstorage (and page navigation is pretty darn snappy!). I know it’s not a “simple drop-in” library but worth a look/thought as it’s pretty interesting/a good use of new technologies and saves recreation of page DOM on back/forward (I think)?
Source code: https://github.com/kizu/kizu.ru/blob/source/src/js/pjax.js
IMHO though – instant.page is looking like the best solution at the mo!
Frank I like a lot the idea of preloading links found in the content, Yeah I think it would be great to include this functionality in Autoptimize!
I’ll probably postpone adding quicklink/ instant.page until after AO25 Mk; there’s a number of potential issues with both solutions (some of which were discussed in the comments above) which I would like to see either proven irrelevant of fixed first :)
I think it is safe to use instant pages, which is from the same author as instant clicks (which I use on my site).
Extra load is minimal, and you can set a waiting time to preload so it will not start if you just move your mouse over it (at least with instant clicks).
It don’t think it will have any effect on mobiles: with instant Click you still have the benefit of loading only the new resources, but this you will not have with instant pages. Instead I use Fastclick to eliminate the time mobile browsers wait before moving to the next page (waiting time is necessary for double clicks)
After implementing it I had some kind of a luxury problem: html loads almost instant, but pictures not, so I looked for a way to preload the ‘above the fold pictures’ too.
I ended up with ‘base64 images’ (data url’s), so the image is included in the html and will automatically benefit from instant clicks. Did not manage to find a way to only include the above the fold images, so I had to include them all (they are small, so average page size is still < 350 Kb). Works really nice; you not longer see a page loading, but the (for the eye) complete page pops up mostly withing 500 ms after you clicked.
Only one draw back: there is not much left for CDN's to cache this way – Cloudflare dropped to around 4%. Currently playing with their 'cache everything option', so the html with the included pics will be cached again.
Almost ready ;-)
Hi Frank, I have been using instant.page and it’s great. Simplicity and causes no problems. I agree it could cause problems for people who have heavy, uncached site. In my case, with pages around 200~400kb and load times of around 300ms, on Nginx servers which can spit out heaps of pages, I see no problems. What I would love is for its JS to be able to be pulled to my server and get served from there, like “CAOS Analytics” plugin does with the Google Analytics JS. Is that how you might do it?
Thanks
Tamhas
I’ve decided against adding instant.page and Google Quicklink in AO25, one of them might end up in 2.6 though later this year :)