Improving the subjective speed of the site with the help of browser prompts
I am surprised that this technique was mentioned on Habré only once and in passing - if you believe the search, of course.
I do not leave the feeling that in fact everyone knows about it, but I still tell you.
The bottom line is that the browser can tell which page the user will open next - and he will begin to load it in advance.
This is made easy - you just need to add a couple of meta tags to the head:
')
Now more about the limitations and nuances.
The first thing that comes to mind, of course, is that far from everywhere and not always applicable - it is not always clear where this strange citizen will go next.
But for multi-page articles, for example, will fit just right. Or for a blog entry with links to previous and next posts. Or for the registration funnel - in general, there are also quite a few cases where you can apply.
Secondly, AFAIK only supports Firefox and Chrome with such ears with ears at the moment, and the first one - for many years, which is interesting. Actually, the first rel value is recognized by Firefox, the second by Chrome. There is a difference between them, and it lies in the fact that in Chrome this is implemented much better, in more detail a bit later.
But the prefetch version is already in the current WHATWG version: www.whatwg.org/specs/web-apps/current-work/#link-type-prefetch . This does not mean that WHATWG chose the worst of the two options - the definition of the value of this attribute is very general (“browser should cache the specified content”), and nothing prevents a particular browser from making it work at the Chrome level or even better.
So you can hope that support will appear in other browsers, especially on the WebKit engine (do you understand that in Gecko-based browsers this already exists, but where are they, popular Gecko browsers, except FF?)
Thirdly, it is important to understand that the browser starts loading something only after it has loaded the entire current page - and the FF also takes into account the downloading of files by the browser, and, probably, network activity in other tabs.
However, I believe, Chrome may traditionally be more aggressive in this matter and start shipping at an earlier stage - but I did not hold a candle. If someone can look right in the sorts, it will be interesting to know for sure.
We’ll finish on a major note - in both browsers, these meta tags are absolutely correct when dynamically added. And there may be several.
Now, what is the difference between prefetch in Firefox and prerender in Chrome?
Chrome, meeting the prerender instruction, creates an invisible tab , and starts loading a page in it, with all the scripts (which it even executes), pictures, and so on. If the user actually goes to the predicted address, the current tab is replaced with this invisible one, and he is on the already loaded — or at least the loading — page.
Firefox just loads the html of the specified page, all external resources begin to load only during the transition. I did not find this in the official FAQ on MDN [1], and I did not even find where I initially read it - but field experiments with the 15th version seem to say that this is how it is.
True, it is necessary to make a reservation here - you can indicate in the meta tag not only the addresses of the pages, but also links to css, pictures, you name it. So, by creating new tags, you can force FF to load and more - but this is far from elegance.
However, in the approach of Chrome, you can also find cons, especially if we recall that not everyone has no limit - but I like it more.
Apparently, because I have no limit :-)
I am writing this article in two hubs - and one of them is the corporate blog of the company Surfingbird .
So now how we used it - if not interested, you can skip.
The main mode of using the site is surfing, when (in any case, I formulate) the user switches from one of our recommendations to another. He views them in the form of an iframe, which occupies almost the entire browser window. In the process of putting likes, dislikes, reacts in other ways - and we rearrange his issue on the fly.
So we started by saying that we started requesting the next recommendation not when he clicked on the “Surf” button - which, in fact, is “Next!” - but right away, according to the document ready, and this is already saving milliseconds. 300
And since the answer returns the full url of the next page, we started generating these meta tags with the received url on the fly - and save even more.
The last caveat remains - the user can set preferences while surfing — such as restricting categories, domains, authors of links — and it’s important, of course, to use previously received recommendations only if the settings have not changed. However, this is observed in the vast majority of cases.
Visually, in Chrome, it turns out that if you linger on the current page for a few seconds, the next one opens instantly. The effect is stunning - they were happy like children when they checked.
Make sure that it works, in Chrome, you can here - chrome: // net-internals / # prerender, I will not tell you about FF, unfortunately.
I foresee remarks that it affects the statistics and even, perhaps, violates privacy (not in the case of surfingbird.ru, of course, but in general - imagine that evil people told your browser to load a page with child porn and your ip got into logs), increases traffic, and something else.
On the one hand, some of the questions can be answered that FF sends a special header when prefetching, while Chrome suggests using Page Visibility API, and for evil people there are many other ways to do disgusting things.
On the other - I personally do not consider this a serious problem. The advantages seem to me much more significant.
[1] developer.mozilla.org/en-US/docs/Link_prefetching_FAQ
[2] www.chromium.org/developers/design-documents/prerender
I do not leave the feeling that in fact everyone knows about it, but I still tell you.
The bottom line is that the browser can tell which page the user will open next - and he will begin to load it in advance.
This is made easy - you just need to add a couple of meta tags to the head:
')
<link rel="prefetch" href="NEXT PAGE URI" /> <link rel="prerender" href="NEXT PAGE URI" /> Now more about the limitations and nuances.
The first thing that comes to mind, of course, is that far from everywhere and not always applicable - it is not always clear where this strange citizen will go next.
But for multi-page articles, for example, will fit just right. Or for a blog entry with links to previous and next posts. Or for the registration funnel - in general, there are also quite a few cases where you can apply.
Secondly, AFAIK only supports Firefox and Chrome with such ears with ears at the moment, and the first one - for many years, which is interesting. Actually, the first rel value is recognized by Firefox, the second by Chrome. There is a difference between them, and it lies in the fact that in Chrome this is implemented much better, in more detail a bit later.
But the prefetch version is already in the current WHATWG version: www.whatwg.org/specs/web-apps/current-work/#link-type-prefetch . This does not mean that WHATWG chose the worst of the two options - the definition of the value of this attribute is very general (“browser should cache the specified content”), and nothing prevents a particular browser from making it work at the Chrome level or even better.
So you can hope that support will appear in other browsers, especially on the WebKit engine (do you understand that in Gecko-based browsers this already exists, but where are they, popular Gecko browsers, except FF?)
Thirdly, it is important to understand that the browser starts loading something only after it has loaded the entire current page - and the FF also takes into account the downloading of files by the browser, and, probably, network activity in other tabs.
However, I believe, Chrome may traditionally be more aggressive in this matter and start shipping at an earlier stage - but I did not hold a candle. If someone can look right in the sorts, it will be interesting to know for sure.
We’ll finish on a major note - in both browsers, these meta tags are absolutely correct when dynamically added. And there may be several.
Now, what is the difference between prefetch in Firefox and prerender in Chrome?
Chrome, meeting the prerender instruction, creates an invisible tab , and starts loading a page in it, with all the scripts (which it even executes), pictures, and so on. If the user actually goes to the predicted address, the current tab is replaced with this invisible one, and he is on the already loaded — or at least the loading — page.
Firefox just loads the html of the specified page, all external resources begin to load only during the transition. I did not find this in the official FAQ on MDN [1], and I did not even find where I initially read it - but field experiments with the 15th version seem to say that this is how it is.
True, it is necessary to make a reservation here - you can indicate in the meta tag not only the addresses of the pages, but also links to css, pictures, you name it. So, by creating new tags, you can force FF to load and more - but this is far from elegance.
However, in the approach of Chrome, you can also find cons, especially if we recall that not everyone has no limit - but I like it more.
Apparently, because I have no limit :-)
I am writing this article in two hubs - and one of them is the corporate blog of the company Surfingbird .
So now how we used it - if not interested, you can skip.
The main mode of using the site is surfing, when (in any case, I formulate) the user switches from one of our recommendations to another. He views them in the form of an iframe, which occupies almost the entire browser window. In the process of putting likes, dislikes, reacts in other ways - and we rearrange his issue on the fly.
So we started by saying that we started requesting the next recommendation not when he clicked on the “Surf” button - which, in fact, is “Next!” - but right away, according to the document ready, and this is already saving milliseconds. 300
And since the answer returns the full url of the next page, we started generating these meta tags with the received url on the fly - and save even more.
The last caveat remains - the user can set preferences while surfing — such as restricting categories, domains, authors of links — and it’s important, of course, to use previously received recommendations only if the settings have not changed. However, this is observed in the vast majority of cases.
Visually, in Chrome, it turns out that if you linger on the current page for a few seconds, the next one opens instantly. The effect is stunning - they were happy like children when they checked.
Make sure that it works, in Chrome, you can here - chrome: // net-internals / # prerender, I will not tell you about FF, unfortunately.
I foresee remarks that it affects the statistics and even, perhaps, violates privacy (not in the case of surfingbird.ru, of course, but in general - imagine that evil people told your browser to load a page with child porn and your ip got into logs), increases traffic, and something else.
On the one hand, some of the questions can be answered that FF sends a special header when prefetching, while Chrome suggests using Page Visibility API, and for evil people there are many other ways to do disgusting things.
On the other - I personally do not consider this a serious problem. The advantages seem to me much more significant.
[1] developer.mozilla.org/en-US/docs/Link_prefetching_FAQ
[2] www.chromium.org/developers/design-documents/prerender
Source: https://habr.com/ru/post/151197/
All Articles