Progressbar makes page load appear slower about instantclick

[dieulot]

It seems to me too that the progress bar make thing appear slower (but it’s needed).

Showing the progress bar only after a delay sounds like an interesting thing to explore, I’ll try that.

The progress bar is needed when a page is already visited [1] though, otherwise it would make for a weird inconsistency.

[1] I guess you meant visited instead of loaded, as loading can occur without visiting a page, just by hovering over the link.

[ooxi]

But as soon as the page is loaded (and thus in the browser cache), navigating to it can be done without further delay. So why bother showing a progress bar at all?

I also don't think this would be inconsistent with current browser behaviour. Chrome for example shows progress notifications only if a page takes too long to load (a couple of hundret ms).

[dieulot]

Because the page changes so fast that users sometimes don’t notice it has changed. After “OMG so fast”, this is the second most common piece of feedback I got from users.

The current browser behavior shouldn’t be taken as an example, as it happens only when you’ve already visited a page and you are aware of why it is so fast (you’ve already visited the page). With InstantClick, the user isn’t aware that he has technically visited the page.

[eproxus]

How about adding a configurable delay to show the progress bar (defaults to 50 ms or something)? This way, if you have a normal web page, you'll get the instant feel, and for slow pages you get the bar (a good example is the instantclick.io page itself). If you have a control panel (or similar application) where contents might not change much between "pages", you can configure it to start after 0 ms (if people don't realize the page has changed).

[dieulot]

I think I should find what is right for everybody and not offer an armada of settings.

Good news though, I’ve been reconsidering what I said previously. I now think that, like you said, showing the bar after 50–100 ms is the correct thing to do, as the problem I’ve talked about is I think only a problem for websites who didn’t have InstantClick before, and because it’s not that big of a deal, more of a pleasant surprise.

[eproxus]

True, looking forward to trying out the delayed version. 😄

[ooxi]

👍

[tacone]

I second a configurable delay.

[dieulot]

What I’m planning to do is separate the progress bar from the core code, and make it rely on events. The version distributed on the website will come with the progress bar, but it will be easy to remove or modify.

I’m not planning to give an easy way to modify the delay beyond that, because I don’t see the point. Once I find the correct delay to set, it should work great for pretty much every human on the planet.

[dieulot]

(If it doesn’t, that’ll be an issue to raise.)

[dieulot]

I retract what I said, setting the progress bar to always display (the current behavior) is temporarily useful for an existing site with users who aren’t yet accustomed to pages displaying instantly.

It will be jarring only on the first page loaded with InstantClick for this user though, so I’m still not sure it’s worth giving this option.

[dieulot]

I re-retract. It’s not worth the trouble setting this twice (first always display, then only when the page hasn’t loaded), also going from always displaying the progress bar to displaying it only when the page hasn’t completed loading will be jarring. Bad.

So, no delay parameter planned.

[tacone]

Deal breaker for me.
I wish there was some way to handle it with css transitions delay. Not sure, since the progress bar object is created from scratch.

Maybe just throwing an event would allow customization for those interested.

[dieulot]

Maybe just throwing an event would allow customization for those interested.

Could you give more details on this? Not sure I understand.

What will happen is, the progress bar will be a snippet of code included not in the core code but after the core code. That means it will rely on events, which also means it’ll be easy to swap that progress bar for another one, for those that wish to make their own custom progress indicator.

Were you talking about something else?

[tacone]

No sorry, I thought you did retract that part also. It should be ok then. Thank you.

[rdy4ever]

I know this is 6 years old, but I'm using this right now for a Jekyll project (and I also know about the newer instant.page, but I made it a configurable option, if the site should use istantclick or instant.page, as I prefere instantclick approach better but I do realise the newer version is somehow better, depending on the case).
In order to only show a progress bar if the loading isn't instant, I use the wait event to add a class to #instantclick.

From docs:
wait : The user has clicked on a link, but the page isn’t preloaded yet. Only triggers when the page isn’t displayed instantly.

So, I have:

if (siteSettings.instantClick) {
    InstantClick.on('wait', function() {
        const insta = document.querySelector("#instantclick");
        insta.classList.add("show");
    });

    InstantClick.on('change', function() {
        const insta = document.querySelector("#instantclick");
        insta.classList.remove("show");
    });
}

and

#instantclick {
    display: none;
    &.show {
        display: block;
    }
}