Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
Regards, -Kudu.
Thanks for sharing! This could be really interesting on mobile. We have already been experimenting with touch events rather than traditional events and there is ajax page loading in our mobile alpha https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=alpha (click a link or perform a search to see - modern browsers only)
Preloading on hover or a similar type of predictive preload might be an awesome idea! :) Help us build it?! On 8 Feb 2014 11:13, "Kudu" kudu@riseup.net wrote:
Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
Regards, -Kudu.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Indeed, mobile is traditionally the land of terrible latency, so that's a great place to concentrate effort. :)
On touchscreen devices of course we don't have hover events as such, but we could do predictive preloading on touchstart, then trigger the load action on touchend.
False positives that are actually starts of pans or zooms might be a concern, but if we're only loading the metadata & lead section in that background request that might not be a big deal.
-- brion
On Sat, Feb 8, 2014 at 11:52 AM, Jon Robson jdlrobson@gmail.com wrote:
Thanks for sharing! This could be really interesting on mobile. We have already been experimenting with touch events rather than traditional events and there is ajax page loading in our mobile alpha https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=alpha (click a link or perform a search to see - modern browsers only)
Preloading on hover or a similar type of predictive preload might be an awesome idea! :) Help us build it?! On 8 Feb 2014 11:13, "Kudu" kudu@riseup.net wrote:
Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
Regards, -Kudu.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Sounds great. Would it possible to do this in such a way that we can detect in our logs how many page views were requested because of this, and how many were not shown after all, to keep out stats sane?
Erik
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Brion Vibber Sent: Saturday, February 08, 2014 22:07 To: Wikimedia developers Subject: Re: [Wikitech-l] InstantClick
Indeed, mobile is traditionally the land of terrible latency, so that's a great place to concentrate effort. :)
On touchscreen devices of course we don't have hover events as such, but we could do predictive preloading on touchstart, then trigger the load action on touchend.
False positives that are actually starts of pans or zooms might be a concern, but if we're only loading the metadata & lead section in that background request that might not be a big deal.
-- brion
On Sat, Feb 8, 2014 at 11:52 AM, Jon Robson jdlrobson@gmail.com wrote:
Thanks for sharing! This could be really interesting on mobile. We have already been experimenting with touch events rather than traditional events and there is ajax page loading in our mobile alpha https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=alpha (click a link or perform a search to see - modern browsers only)
Preloading on hover or a similar type of predictive preload might be an awesome idea! :) Help us build it?! On 8 Feb 2014 11:13, "Kudu" kudu@riseup.net wrote:
Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
Regards, -Kudu.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
How much bandwidth would this cost the users? If a mobile user is paying by how much they download, this could well mean they're paying for things loaded in the background - things that they may never even touch.
On 08/02/14 19:52, Jon Robson wrote:
Thanks for sharing! This could be really interesting on mobile. We have already been experimenting with touch events rather than traditional events and there is ajax page loading in our mobile alpha https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=alpha (click a link or perform a search to see - modern browsers only)
Preloading on hover or a similar type of predictive preload might be an awesome idea! :) Help us build it?! On 8 Feb 2014 11:13, "Kudu" kudu@riseup.net wrote:
Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
Regards, -Kudu.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile users don’t have hover effects, and thus can only use this on click, which is how things get loaded anyway.
On Feb 8, 2014, at 6:43 PM, Isarra Yos zhorishna@gmail.com wrote:
How much bandwidth would this cost the users? If a mobile user is paying by how much they download, this could well mean they're paying for things loaded in the background - things that they may never even touch.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Not true.
As Brion pointed out there is ontouchstart.
Technically they do have hover events btw - they get triggered on a touch. On 8 Feb 2014 21:04, "Brandon Harris" bharris@wikimedia.org wrote:
Mobile users don't have hover effects, and thus can only use this
on click, which is how things get loaded anyway.
On Feb 8, 2014, at 6:43 PM, Isarra Yos zhorishna@gmail.com wrote:
How much bandwidth would this cost the users? If a mobile user is
paying by how much they download, this could well mean they're paying for things loaded in the background - things that they may never even touch.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 09/02/14 06:13, Kudu wrote:
Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
I think Google Web Accelerator used to do this. Interesting to see old ideas become new again.
function mouseout() { ... p.xhr.abort() ... }
A scary concept, considering the way our system handles client-side aborts. After a configurable delay, recommended to be 50-100ms, the XHR request starts, then it is aborted if the cursor moves out of the link. Moving the cursor through a dense list of links to large pages, like say a talk page archive list, could be quite expensive for the server.
Maybe if there was a limit on the number of prefetch requests per page view, it would be less scary. And potentially less expensive for roaming mobile users.
-- Tim Starling
Hi,
Today, I heard about a JavaScript library called InstantClick (http://instantclick.io/). Basically, it's based on the principle that latency is responsible for a lot of the Web's slowness. It also considers that there are about 250ms between hovering over and clicking on a link. Therefore, it starts pre-loading the page on hover, and then switches to it via AJAX when the user clicks the link. It can also do this on mousedown only, which causes no additional server load and still provides a performance boost, according to its website, similarly to Rails' turbolinks functionality.
Is there any chance this could work on MediaWiki?
Regards, -Kudu.
This is pretty neat. Some a/b tests on mobile would help us understand just how much extra data this would cause people to consume vs. how much time it saves them.
On desktop, I bet a combination of this with something like cursor proximity based events [1] would be interesting to look into.
[1] https://github.com/padolsey/jquery.fn/tree/master/proximity-event
wikitech-l@lists.wikimedia.org