30 thoughts on āAutoptimize: extra functionality?ā
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 š
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.
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.
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. Met vriendelijke groet, Alex
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ā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!
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
Hi Frank, I just learned about quicklink and found this post after poking around for info. So what ever happened, did neither of these ever make it into AO? Itās been 2 years, have either of them improved at all? Thanks
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 š
Hi Frank, I just learned about quicklink and found this post after poking around for info. So what ever happened, did neither of these ever make it into AO? Itās been 2 years, have either of them improved at all?
Thanks
Indeed neither ended up in AO, but instant.pages is integrated in https://wordpress.org/plugins/speed-booster-pack/ which works great with AO, maybe take that out for a spin? š