45 comments

[ 0.24 ms ] story [ 97.1 ms ] thread
What does this offer over native preloading?

https://css-tricks.com/prefetching-preloading-prebrowsing/

Edit: It would appear that only Chrome and Opera currently support it: http://caniuse.com/#feat=link-rel-preload

(comment deleted)
For now, we don't have support to it. We just do loading pages in background and we control the history ;) In the future, I'd like to improve to use native preloading :)
For now, we don't have support to it. We just do loading pages in background and we control the history ;) In the future, I'd like to improve to use native preloading :)
Would SiteAccelerator not be a better name since this speedsup site loads due to preloading of pages, but does nothing to the current page (well beside adding extra javascript to it).
The biggest flaw of this solution is that it will fetch pages that might changed by the time the user click the link. This solution is good for website that doesn't change often or for more static website.
Don't know much about web development but in most cases isn't that exactly the scenario you usually aren't worried about being slow?

Not that someone couldn't make a slow static page but in general aren't static pages going to load pretty fast anyway?

I believe Turbolinks addresses this concern by displaying the stale page from the cache while requesting the latest version. Not sure if this library uses the same approach.
How is this different than InstantClick (http://instantclick.io/)?
InstantClick advantage: it adds the feature of downloading the content on hover lowering latency

PageAccelerator advantage: smaller file size, 2.2kb minified as opposed to 5.9kb for InstantClick

people should just use historyAPI directly
Have you checked out pjax? I believe it does the same thing.

The biggest problem I've had trying to use stuff like this is that the page load events don't fire. And many pages run lots of JavaScript in these events.

It looks like the author specifically mentions pjax as a similar project.

  pageAccelerator is a very light version of turbolinks and pjax (our minify file has 2.2KB!).
It seems as though it's meant to be a lighter weight version.
pjax is mentioned in the README, they say the advantage to this is that it has a smaller file size.
Why not https://github.com/turbolinks/turbolinks?

Say what you want about previous versions of Turbolinks, but the latest version works really well and has support for native web views.

If you want a single-page app feel to your website, build it as a single page app from the beginning. Bolting something like turbolinks on top of an existing website will probably give you more headaches than it's worth. You can't escape the fact that the app suddenly has state and you need to deal with it (and then why not do so from the get-go?).
For content sites that don't deal with a bunch of state, this could be a nice addition to make navigation feel faster without compromising SEO and without introducing a complicated build solution for server-side rendering.
While AMP is great, it doesn't serve the same purpose and is only designed to work for specific types of content and not an entire site.
Err not so google is prompting me to add amp pages to a site (major travel brand) which is out the initial use case
From the readme

"pageAccelerator is a very light version of turbolinks and pjax (our minify file has 2.2KB!)"

I always get worried when someone uses a lib that's 2.2kb vs 55kb (turbolinks) just to save size...when the two do the same thing. what are the 53kb doing? nothing?
Possibly handling a bunch of edge cases, possibly bundling in a bunch of dependencies for dev convenience (which recursively do the same), probably some of both.
Usually it has a lot more options most don't use, or are handling edge cases most don't care about.
Perhaps I'm understanding this incorrectly, but what happens if you have a destructive link that deletes something?
The official answer is "Links shouldn't ever create or delete things". Of course, in practice, lots of links do create and delete things, and that this type of preloading would be a really bad idea on those sites.
Search engines have the same problem. The solution is simply to not use HTTP GET for destructive links - use PUT or POST instead.
Google had an accellerator in their browser toolbar like 10 years ago which prefetched pages like that. It didn't end well with poorly built webapps with 'delete' links.
You make it a http POST as per the standard.
Your you do it with POST / PUT ;) If you would like to do it using a link, you simply add data-pageAccelerator="false"
I love this technique. It's how I built this image gallery for my daughter's website https://www.zadieheimlich.com/easter-2016/

Didn't use PageAccelerator or Instantclick or Turbolinks. It's just jQuery. Here is the source https://github.com/kingkool68/zadieheimlich/blob/master/js/p...

I like this way over a client-side JavaScript framework app approach because... 1) It fails gracefully if JavaScript is unavailable 2) I can keep most of the logic on the server side since the JavaScript is only fetching an HTML page and parsing for content 3) It's fast :)

In my browser (OSX, Firefox 48), there is this horrible flash every time I switch pictures. IMO, the perceived speed is completely outweighed by this flickering and it makes the website/web app feel flaky.
RIP server log file, analytics and clients' metered connections
I have the same concern: is there a way not to screw analytics?
Why? This only loads the page on click when it would have been loaded anyway.
There are few more. Senna.js Barba.js...

Tried all of them and Senna.js wins. Not the best docs but damn that thing is so fast with that cashing. They are working on service worker preloading stuff like that. And you can go pretty deep. Also seems most durable and maintained of the ones i tried.

Pjax hasnt been updated for years for example.