This is a clever trick (using mousedown to trigger a click), but breaks drag & dropping links, drag & dropping links to new tabs.
and there is also a thing I tend to do: If I notice I pressed the mouse button down on the wrong link, I move the cursor away from that link and let the button go up on the correct or in free space, so the browser doesn't navigate (not sure how common this behaviour is, though)
It's extremely common. It is unclear to me if the mousedown event just kicks off preloading of the page, or actually forces you to navigate to the page. If it's the latter, you are breaking decades of mouse ux changing a click from a mousedown followed by mouseup.
Dragging sidebar links worked fine for me all but once in Safari. Not sure how to tell whether it's actually being used, but I don't notice any problems.
[Edit: I was using a blocker that was blocking it. Now I've used it and can tell it's working, and I still don't notice any problems using it in Safari.]
+1 I do those as well. Never really thought about how common it could be, but it is pretty natural for me to drag the mouse and let it up somewhere else to prevent incorrect navigation.
It’s common enough to be damn inconvenient if the ability just suddenly disappears.
If it happens on all sites at the same time it’s one thing. If it happens on just your site I will just feel like your site is icky (and I might not even know why).
On Twitter just accidentally clicking down on the mouse anywhere, I have to move my mouse outside of the browser window before releasing it because anywhere else is likely to have side effects.
Fasterfox (the now disappeared addon, not the currently available theme of the same name) did that. And yes, it wasted bandwidth (for site owners as well).
In case of prefetching, that's a header <link> functionality: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe.... Most implementations use it for static content like images or CSS. There's also DNS prefetching, which depends more on the browser.
What you might mean is "prerendering", i.e. silently downloading another page in the background. This feature is not yet supported in Firefox, but heavily used by Google and in Chrome. IIRC, earlier Firefox versions actually supported this through addons, but these addons did not know the page and pre-loaded every link they could find on the page. This resulted in an enormous amount of background traffic, essentially wasted due to only one link being the "next" link. Therefore, using the preload/prefetch/prerender link attributes should be left to the site owner.
With Firefox 76.0.1, when I click a link, then click "back", the page thinks I'm still holding down on the thing I clicked, and have it in a drag&drop state. Then I have to click somewhere else to release it.
This would be odd behaviour of any website for me personally, in some areas data is still precious and limited. Also I'm wired to think that only clicking website would open resources for that website, sometimes I just hover the link to check where that link leads to.
Hope it doesn't come to email, for me I don't load remote content but not sure how to play in tracking over there.
>it triggers the page load when the user starts pressing their mouse
This breaks the standard GUI interaction model. Buttons are typically triggered on mouse-up events, not mouse-down, and there's probably good reasons for that.
Any client-side hacks that attempt to improve the perceived page speed are somehow bound to break something. If there really is a simple way, it's already been implemented at the browser level, for all websites. Link prefetching is already a thing. Do you want fast pages? Make your server-side rendering fast.
> Do you want fast pages? Make your server-side rendering fast
Yeah.. imagine being so thirsty for page load efficiency that you ignore all the bloat of JavaScript and poor server-side rendering but instead directly skip to breaking the standardized GUI/UX
Sorry if my comment came in kinda offensive, it's a general stance I was criticizing, not your project in particular! Your offer is based on an existing demand, so who should feel addressed are those who use solutions like yours.
There’s a joke about two bankers walking down wallstreet. One says to the other: “my gosh look, there’s a 100$ bill on the ground”. The other without looking down turns to him and says: “Impossible! iIf there was 100$ on the ground someone would have picked it up!”
Yep. This convention also enables the cancellation of a click, which can be useful if you realise your error mid-click.
Another piece of software egregious for violating this UI convention is Adobe Reader. I remember upgrading to, IIRC v9? and finding that all buttons in it had been changed to actuate on mouse-down, and wondering what the christ the developers were thinking. Perhaps they thought it made their software seem more "responsive".
But note that keyboard things operate on key down. Software operating on key up has caused me surprisingly much grief. I can think of two systems I interact with, off the top of my head, that trigger things on Escape key up, which is badly wrong in that I often do Alt down → Tab press → no wait, I do want to be here → Escape press → Alt up, and so the browser which didn’t see the Escape down (because it didn’t belong to it) does see the Escape up, and improperly cancels what I was in the middle of or similar. This is so annoying.
There are some big brand names listed in the "Trusted By" section, but it's unclear to me where they use instant.page. I clicked a few of the links and was unable to find an instant.page script tag anywhere.
I think that adding a link tag with the prefetch attrib on hover is fine, but the page navigation on "mousedown" feature (even so it has to be enabled) is the opposite of what kind o
Great, now sites can implement clicking in some confusing, subtly broken way? File this with sites that implement their own broken inertial scrolling, their own broken scrollbars, and their own broken pop-up menus.
I've experimented with instant.page and other similar scripts and it's almost shocking how fast page loading becomes when you are used to a (slight) page loading delay. There are a couple of drawbacks that one has to be aware of - bandwidth, altered ui behavior - but for some use cases where performance is needed and the bandwidth usage is minor, preloading scripts can be very useful.
>InstantClick provides the smoothest experience possible, while still not requiring as much work as a framework (who give lesser results)
It's not the job of a framework to make such optimizations. But within any framework, you could trivially implement something similar. You could be quite aggressive and fetch + cache on hover.
I contemplated using the instant.page techniques a while back, and took version 1.2.2 and stripped it to its bones, removing configurability that I’m never going to use, and golfed it down to 981 bytes/532 gzipped (873/456 sans license comment).
No way would I go past 1.2.2, though, because all it does is introduce more configurability that I don’t want, complications, bugs and misfeatures. (I call triggering load on mouse down catastrophically wrong, 100% dealbreaker with prejudice.)
Here’s the ECMAScript Module (I call it a module so I can skip an IIFE without polluting globals) that I ended up with, in case anyone’s interested. It uses uncommon tricks like reusing variables for different purposes to save a couple of bytes, which will tend to make JITs unhappy, but the JIT would turn up its nose at this lightly-called functionality anyway.
/*! instant.page v1.2.2, (C) 2019 Alexandre Dieulot, https://instant.page/license, shrunk by Chris Morgan */var e,t,a,r=document,n=r.createElement("link"),s=n.relList,o=()=>{e=n.removeAttribute("href")},i=e=>{e.relatedTarget&&e.target.closest("a")==e.relatedTarget.closest("a")||(t?(clearTimeout(t),t=0):o())},c=t=>!(!t||!t.href)&&(e!=(t=t.href)&&((t=new URL(t)).origin==location.origin&&(!t.hash||t.pathname+t.search!=location.pathname+location.search)));!(s&&s.supports&&s.supports(n.rel="prefetch"))||(s=navigator.connection)&&s.saveData||(r.head.appendChild(n),r.addEventListener("touchstart",t=>{a=performance.now(),c(s=t.target.closest("a"))&&(s.addEventListener("touchcancel",o,{passive:!0}),s.addEventListener("touchend",o,{passive:!0}),n.href=e=s.href)},s={capture:!0,passive:!0}),r.addEventListener("mouseover",r=>{performance.now()-a<1100||c(s=r.target.closest("a"))&&(s.addEventListener("mouseout",i,{passive:!0}),e=s.href,t=setTimeout(()=>{n.href=s.href,t=0},65))},s))
I have the golfed-but-not-uglified code too, but I won’t share it here at this time. It’s more fun this way.
(No warranty whatsoever, don’t think I’ve even run the code.)
What's old is new again. I remember using this technique a good 10 years ago to speed up perceived page load on an intranet.
IIRC back in the day, google used a similar trick, where it would preload the first few search results to make them load from cache in the 90% of the cases when a user clicked on them
If the hover request is waiting on a 5mb page (god forbid) and it doesn't complete before the navigation starts, then will the browser use any of the pre-fetched data? Or will it have been wasted?
58 comments
[ 3.6 ms ] story [ 121 ms ] threadThe two other use cases you mention aren’t common at all though.
[Edit: I was using a blocker that was blocking it. Now I've used it and can tell it's working, and I still don't notice any problems using it in Safari.]
> Safari 13.0 has support for <link rel="prefetch"> but it’s disabled by default. Hopefully it will be enabled in September 2020 in Safari 14.0.
Try enabling that setting or using another browser (I used Firefox) to see the effect it has.
If it happens on all sites at the same time it’s one thing. If it happens on just your site I will just feel like your site is icky (and I might not even know why).
based on which data? Drag-dropping links to other applications is quite useful.
We'll, lets hope most users of this do indeed load it from your domain, so my scriptblocker will stop it.
I do this a lot as well.
What you might mean is "prerendering", i.e. silently downloading another page in the background. This feature is not yet supported in Firefox, but heavily used by Google and in Chrome. IIRC, earlier Firefox versions actually supported this through addons, but these addons did not know the page and pre-loaded every link they could find on the page. This resulted in an enormous amount of background traffic, essentially wasted due to only one link being the "next" link. Therefore, using the preload/prefetch/prerender link attributes should be left to the site owner.
Here's a good resource on preload (same page), prefetch (next page) and preconnect (other source domains): https://www.machmetrics.com/speed-blog/guide-to-browser-hint...
Edit: as Arkanosis mentioned in a related comment, the refered to addon was called Fasterfox: http://fasterfox.mozdev.org/faq.html#What_is_prefetching
Hope it doesn't come to email, for me I don't load remote content but not sure how to play in tracking over there.
This breaks the standard GUI interaction model. Buttons are typically triggered on mouse-up events, not mouse-down, and there's probably good reasons for that.
Any client-side hacks that attempt to improve the perceived page speed are somehow bound to break something. If there really is a simple way, it's already been implemented at the browser level, for all websites. Link prefetching is already a thing. Do you want fast pages? Make your server-side rendering fast.
Yeah.. imagine being so thirsty for page load efficiency that you ignore all the bloat of JavaScript and poor server-side rendering but instead directly skip to breaking the standardized GUI/UX
So you can drag the link somewhere else. Like to the desktop or a text editor or a terminal window.
Another piece of software egregious for violating this UI convention is Adobe Reader. I remember upgrading to, IIRC v9? and finding that all buttons in it had been changed to actuate on mouse-down, and wondering what the christ the developers were thinking. Perhaps they thought it made their software seem more "responsive".
More recent additions to the fleet include: https://www.bmwusa.com/ https://css-tricks.com/ https://www.juul.com/
https://news.ycombinator.com/item?id=19122727
It's not the job of a framework to make such optimizations. But within any framework, you could trivially implement something similar. You could be quite aggressive and fetch + cache on hover.
No way would I go past 1.2.2, though, because all it does is introduce more configurability that I don’t want, complications, bugs and misfeatures. (I call triggering load on mouse down catastrophically wrong, 100% dealbreaker with prejudice.)
Here’s the ECMAScript Module (I call it a module so I can skip an IIFE without polluting globals) that I ended up with, in case anyone’s interested. It uses uncommon tricks like reusing variables for different purposes to save a couple of bytes, which will tend to make JITs unhappy, but the JIT would turn up its nose at this lightly-called functionality anyway.
I have the golfed-but-not-uglified code too, but I won’t share it here at this time. It’s more fun this way.(No warranty whatsoever, don’t think I’ve even run the code.)
IIRC back in the day, google used a similar trick, where it would preload the first few search results to make them load from cache in the 90% of the cases when a user clicked on them