PWA, “Ominous Valley” and stable work offline
Last July at Altitude 2016, Alex Russell (Alex Russell) from Fastly told how he sees the future of mobile applications with PWA and service worker in mind, how to ensure reliable operation of the application offline, and how to get around the “sinister valley” in the mobile interface.
"In the team, we know that faster is always better," said Alex. "This circumstance is confirmed by dozens of studies of our team and others."
This pattern is illustrated in Figure 1. It is clearly seen that with increasing load time of a web page:
')
1) the number of hits to the page drops dramatically;
2) the percentage of failures is constantly growing.
Fig. 1. Faster is always better
The bar chart shows the dependence of the number of hits to a web page per second on the load time (this page is also in seconds.
The red graph shows the dependence of the bounce rate as a percentage of the same load time in seconds of a web page.
But it is not always clear what we mean by the word "faster." Of course, we mean faster in relation to the load time of a web page. However, there is not enough data on when the web page actually began to load.
The interactive content of a webpage is, of course, what users need. However, users are finding it harder to get to this content. It should be noted that initially the web network grew in such conditions when the access speed was not great, but at the same time it was not too different for different devices.
Today, mobile networks have a great time waiting for the opening of acceptable options for web pages, despite the rapid increase in the number of mobile devices. Alex noted that "modern software has become much better, but at the same time, networks are not getting better in the same absolute figures."
The Chrome team decided to create a service worker that would provide reliable performance by storing the content in a new API cache. According to Google’s web team, “service worker is a script (script) that the browser runs as a background program separately from the web page. This opens access to such features that do not require a listing of a web page, nor any interaction with the user. ”
The service worker gives web developers the ability to respond to network requests created by web applications while continuing to work even when offline, with full control over program events. More on Habrahabr: "Some of the subtleties of using Service Workers . "
Fig. 2. An example of listing service service is shown on example.com
1. The first part of the listing is the initialization of the service worker sw.js on the first access and the opening of the app.html application, i.e., providing the interface.
2. The second part of the listing is the description of the work of the service worker with the content of the app.html application (download content): request an update over the network using the cached content.
Fig. 3. Enlarged text of listings in figure 2
The service worker allows you to design reliable offline events for a given application. This is achieved by immediately providing the interface (system shell) to which the content is then loaded. Figure 4 shows this process.
Fig. 4. Immediate provision of the system shell, which then loads the content
1. The first picture is an application.
2. The second picture is the system shell.
The first two pictures show the immediate loading of the cached interface on repeated visits.
3. The third picture is content. After the interface is loaded, specific images appear.
Application execution is a JavaScript framework that processes the structure of an application step by step. The result is the following procedure:
1) framework loading;
2) application download;
3) and then loading the data by the application.
Today, a service worker can intercept requests to third-party hosts only if this is permitted by the source interaction policy for this host. Consequently, the only way a third-party host can take advantage of the service worker is to connect to it, starting with the root domain. Of course, even in this case, the visibility of requests for this third-party host is limited by the source interaction policy.
To overcome these limitations, the Chrome team is currently developing a service worker with external requests , which allows third-party hosts to process these requests with their own service worker. In this case, there is full visibility and optimization through sites that use the same service from a third-party host.
With external requests, service workers can subscribe to requests from anywhere to their resources. At the same time, proxy requests “to the Internet” are not allowed: for example, the service worker, recognizing the request to the CDN (Content Delivery Network) for fonts, will direct it to the common client cache, which is also used by other sources.
And now, without external requests, third-party hosts - CDN for fonts, analytical services and advertising networks - can implement this logic only with their own service worker without integration with the service worker deployed by the original participants.
More on Habrahabr: "Some of the subtleties of using Service Workers . "
In addition to reliable performance, it would also be nice to impress your users, and it’s much easier to get their attention in connection events than with the App Store index.
Alex used the PWA (progressive web app) example of the Washington Post.
Fig. 5. Adding the Washington Post icon directly from wapo.com to the home screen
1. The first picture is the Washington Post wapo.com site and below is the button for adding the icon of this site to the ADD TO HOME SCREEN home screen.
2. The second picture is the home screen with the added icon.
3. The third picture is again the Washington Post wapo.com website, opened with an icon.
With the help of PWA (progressive web app) you can provide functionality to users without having to create something multiple. If you're interested in creating your own PWA, then you can use the Washington Post metadata: washingtonpost.com/pwa/manifest.json . The Lighthouse Chrome tools will help verify that you really created some event-application for PWA.
Read more on Habrahabr: "6 impressive web technologies in 2015"
To use the most successful performance optimization methods for creating a PWA or something else, the Chrome team follows the RAIL model. This model consists of 4 principles, according to the number of letters in the title:
1) Response (Respond): 100 ms, i.e. within 100 milliseconds, it is necessary to respond to user actions;
2) Animation: <8 ms, i.e. each frame of the animation should appear on the user's screen in less than 8 milliseconds;
3) Waiting (Idle) work in blocks of 50 ms, that is, you need to group tasks in blocks of no more than 50 milliseconds;
4) Load (Load): 1000 ms (= 1 s) to the first screen, i.e., until the first picture appears on the user's screen, it should not take more than 1 second.
Read more on Habrahabr: “Introducing RAIL: site performance evaluation model”
On ordinary web sites, "a lot of wasted time" waiting in the network. Figure 6 shows an example image of a “long” website loading with HTML code and JavaScript.
Fig. 6. An exemplary picture of a “long” loading site with HTML code and JavaScript
The vertical axis is the load percentage (from 0 to 100%).
1. First, the initial request to the site starts.
2. After a while, download the HTML code.
3. Then there is a “long” waiting time.
4. Before the end of the wait time, the download of the JavaScript code begins.
5. After the waiting time, the picture finally starts loading.
The last two steps are parsing and executing JavaScript code.
Today, applications can render server-side JavaScript. When you run such an application, as shown in Figure 6, basic HTML appears immediately, then JavaScript is loaded, and only then can you really use the site. This "long" period of inability to interact with the site and is referred to by Paul Lewis of Google as "Ominous Valley."
Figure 7 shows again Figure 6 with the “Sinister Valley” marked on it.
Fig. 7. Figure 6 with the gray shaded “Sinister Valley”
What we really want to get from the site is the ability of the application to use “all bits on the screen” when the picture appears immediately after the site loads. Figure 8 shows how to eliminate the “Ominous Valley” effect, i.e., a modification of Figure 6 with such a download move that we need.
Fig. 8. Elimination of the "Sinister Valley"
The vertical axis is the load percentage (from 0 to 100%).
1. First, the initial request to the site starts, as in Figure 6.
2. After a while, download the HTML code.
3. And then immediately on the blocks the picture starts to load. The picture is loaded in blocks, so its loading, shaded in yellow, has a stepped appearance.
“Interactivity is something that really excites users,” Alex pointed out. "You do not like the Sinister Valley, where you do not trust the user interface."
To demonstrate the perfect page load, Alex showed the site shop.polymer-project.org .
Downloading these blocks is even easier with HTTP / 2. Using the server-side HTTP / 2 push method, you can in advance parallel “push” additional resources to the client, sending transitive functional dependencies for top-level content as soon as the right moment approaches.
Fig. 9. Scheme for receiving index.html and sending responses with link = preload via HTTP / 2-compatible server part “as soon as possible”
1. HTTP request headers to get index.html.
2. HTTP response headers for sending responses with link = preload.
As soon as the initial response starts and is sent to the browser, you can immediately group the resources as needed by the client. Figure 10 shows this process.
Fig. 10. Start the initial response and send it to the browser, followed by grouping resources.
For example, the components shown above can be sent as soon as you receive an initial response. In this case, the components are not merged into one file, duplicating each other, which may lead to data loss or the appearance of unnecessary.
You can use lazy (or delayed) loading and create an alternative route with a selective update.
To avoid the Sinister Valley when structuring and using PWA, the Polymer team developed a PRPL model as a guide to action. This model consists of 4 steps:
1) push through (Push) resources for the initial route;
2) provide (Render) the initial route as soon as possible;
3) pre-cache (Pre-cache) code in order to leave routes;
4) lazy load (Lazy load) and the creation of the following routes on demand.
Alex advised everyone to familiarize themselves with the Polymer App Toolbox in order to simply try, and also provided a list of resources (see below) to further study the service worker and PWA: “I can't wait to wait until we start building a web network much faster.”
Now the service worker is a programmable proxy inside the browser.
"In the team, we know that faster is always better," said Alex. "This circumstance is confirmed by dozens of studies of our team and others."
This pattern is illustrated in Figure 1. It is clearly seen that with increasing load time of a web page:
')
1) the number of hits to the page drops dramatically;
2) the percentage of failures is constantly growing.
Fig. 1. Faster is always better
The bar chart shows the dependence of the number of hits to a web page per second on the load time (this page is also in seconds.
The red graph shows the dependence of the bounce rate as a percentage of the same load time in seconds of a web page.
What is "faster"
But it is not always clear what we mean by the word "faster." Of course, we mean faster in relation to the load time of a web page. However, there is not enough data on when the web page actually began to load.
The interactive content of a webpage is, of course, what users need. However, users are finding it harder to get to this content. It should be noted that initially the web network grew in such conditions when the access speed was not great, but at the same time it was not too different for different devices.
Today, mobile networks have a great time waiting for the opening of acceptable options for web pages, despite the rapid increase in the number of mobile devices. Alex noted that "modern software has become much better, but at the same time, networks are not getting better in the same absolute figures."
service worker
The Chrome team decided to create a service worker that would provide reliable performance by storing the content in a new API cache. According to Google’s web team, “service worker is a script (script) that the browser runs as a background program separately from the web page. This opens access to such features that do not require a listing of a web page, nor any interaction with the user. ”
The service worker gives web developers the ability to respond to network requests created by web applications while continuing to work even when offline, with full control over program events. More on Habrahabr: "Some of the subtleties of using Service Workers . "
Site example.com. The first time users visit example.com, the service worker starts. With the service worker you deal with each subsequent request. This allows you to choose how to create reliable offline events. Figure 2 shows an example of a listing of service worker. Figure 3 shows the enlarged text of the listings.
Fig. 2. An example of listing service service is shown on example.com
1. The first part of the listing is the initialization of the service worker sw.js on the first access and the opening of the app.html application, i.e., providing the interface.
2. The second part of the listing is the description of the work of the service worker with the content of the app.html application (download content): request an update over the network using the cached content.
Fig. 3. Enlarged text of listings in figure 2
Offline design
The service worker allows you to design reliable offline events for a given application. This is achieved by immediately providing the interface (system shell) to which the content is then loaded. Figure 4 shows this process.
Fig. 4. Immediate provision of the system shell, which then loads the content
1. The first picture is an application.
2. The second picture is the system shell.
The first two pictures show the immediate loading of the cached interface on repeated visits.
3. The third picture is content. After the interface is loaded, specific images appear.
Application execution is a JavaScript framework that processes the structure of an application step by step. The result is the following procedure:
1) framework loading;
2) application download;
3) and then loading the data by the application.
What awaits us tomorrow: service worker with external requests
Today, a service worker can intercept requests to third-party hosts only if this is permitted by the source interaction policy for this host. Consequently, the only way a third-party host can take advantage of the service worker is to connect to it, starting with the root domain. Of course, even in this case, the visibility of requests for this third-party host is limited by the source interaction policy.
To overcome these limitations, the Chrome team is currently developing a service worker with external requests , which allows third-party hosts to process these requests with their own service worker. In this case, there is full visibility and optimization through sites that use the same service from a third-party host.
With external requests, service workers can subscribe to requests from anywhere to their resources. At the same time, proxy requests “to the Internet” are not allowed: for example, the service worker, recognizing the request to the CDN (Content Delivery Network) for fonts, will direct it to the common client cache, which is also used by other sources.
And now, without external requests, third-party hosts - CDN for fonts, analytical services and advertising networks - can implement this logic only with their own service worker without integration with the service worker deployed by the original participants.
More on Habrahabr: "Some of the subtleties of using Service Workers . "
How to make life better for users with PWA
In addition to reliable performance, it would also be nice to impress your users, and it’s much easier to get their attention in connection events than with the App Store index.
Alex used the PWA (progressive web app) example of the Washington Post.
Site wapo.com. Right from wapo.com, mobile users can add the Washington Post icon to their home screens, creating a quick link to bypass the App Store. This process is illustrated in Figure 5.
Fig. 5. Adding the Washington Post icon directly from wapo.com to the home screen
1. The first picture is the Washington Post wapo.com site and below is the button for adding the icon of this site to the ADD TO HOME SCREEN home screen.
2. The second picture is the home screen with the added icon.
3. The third picture is again the Washington Post wapo.com website, opened with an icon.
With the help of PWA (progressive web app) you can provide functionality to users without having to create something multiple. If you're interested in creating your own PWA, then you can use the Washington Post metadata: washingtonpost.com/pwa/manifest.json . The Lighthouse Chrome tools will help verify that you really created some event-application for PWA.
Read more on Habrahabr: "6 impressive web technologies in 2015"
Less time for interactivity for better performance.
To use the most successful performance optimization methods for creating a PWA or something else, the Chrome team follows the RAIL model. This model consists of 4 principles, according to the number of letters in the title:
1) Response (Respond): 100 ms, i.e. within 100 milliseconds, it is necessary to respond to user actions;
2) Animation: <8 ms, i.e. each frame of the animation should appear on the user's screen in less than 8 milliseconds;
3) Waiting (Idle) work in blocks of 50 ms, that is, you need to group tasks in blocks of no more than 50 milliseconds;
4) Load (Load): 1000 ms (= 1 s) to the first screen, i.e., until the first picture appears on the user's screen, it should not take more than 1 second.
Read more on Habrahabr: “Introducing RAIL: site performance evaluation model”
Empty Waiting
On ordinary web sites, "a lot of wasted time" waiting in the network. Figure 6 shows an example image of a “long” website loading with HTML code and JavaScript.
Fig. 6. An exemplary picture of a “long” loading site with HTML code and JavaScript
The vertical axis is the load percentage (from 0 to 100%).
1. First, the initial request to the site starts.
2. After a while, download the HTML code.
3. Then there is a “long” waiting time.
4. Before the end of the wait time, the download of the JavaScript code begins.
5. After the waiting time, the picture finally starts loading.
The last two steps are parsing and executing JavaScript code.
Today, applications can render server-side JavaScript. When you run such an application, as shown in Figure 6, basic HTML appears immediately, then JavaScript is loaded, and only then can you really use the site. This "long" period of inability to interact with the site and is referred to by Paul Lewis of Google as "Ominous Valley."
The effect of the “Sinister Valley” is a hypothesis according to which a robot or other object that looks or acts approximately like a human (but not exactly like the real one) causes hostility and disgust among observers. Read more on wikipedia
Figure 7 shows again Figure 6 with the “Sinister Valley” marked on it.
Fig. 7. Figure 6 with the gray shaded “Sinister Valley”
What we really want to get from the site is the ability of the application to use “all bits on the screen” when the picture appears immediately after the site loads. Figure 8 shows how to eliminate the “Ominous Valley” effect, i.e., a modification of Figure 6 with such a download move that we need.
Fig. 8. Elimination of the "Sinister Valley"
The vertical axis is the load percentage (from 0 to 100%).
1. First, the initial request to the site starts, as in Figure 6.
2. After a while, download the HTML code.
3. And then immediately on the blocks the picture starts to load. The picture is loaded in blocks, so its loading, shaded in yellow, has a stepped appearance.
Interactivity
“Interactivity is something that really excites users,” Alex pointed out. "You do not like the Sinister Valley, where you do not trust the user interface."
To demonstrate the perfect page load, Alex showed the site shop.polymer-project.org .
Site shop.polymer-project.org. As expected, the site page loads quickly and fully interactive. The total download duration is long, but it is “broken into blocks,” so the site remains manageable all the time. These same blocks are loaded as needed, creating a comfortable experience using the site and eliminating the "Ominous Valley".
Downloading these blocks is even easier with HTTP / 2. Using the server-side HTTP / 2 push method, you can in advance parallel “push” additional resources to the client, sending transitive functional dependencies for top-level content as soon as the right moment approaches.
Functional dependency is a concept underlying many issues related to relational databases, including, in particular, their design. Mathematically, it represents a binary relation between sets of attributes of a given relation and is, in fact, a one-to-many connection. Their use is due to the fact that they allow us to solve many problems formally and strictly. A transitive functional dependency is a logical consequence of two other dependencies, a transitive chain. Read more in Wikipedia and Habrahabr: "Resolving conflicts in transitive dependencies - Good, Bad, Evil . "
Work with index.html. For example, if you get index.html, you can start sending responses with link = preload via HTTP / 2 "as soon as possible." Figure 9 shows the listings for this process.
Fig. 9. Scheme for receiving index.html and sending responses with link = preload via HTTP / 2-compatible server part “as soon as possible”
1. HTTP request headers to get index.html.
2. HTTP response headers for sending responses with link = preload.
As soon as the initial response starts and is sent to the browser, you can immediately group the resources as needed by the client. Figure 10 shows this process.
Fig. 10. Start the initial response and send it to the browser, followed by grouping resources.
For example, the components shown above can be sent as soon as you receive an initial response. In this case, the components are not merged into one file, duplicating each other, which may lead to data loss or the appearance of unnecessary.
Lazy download and selective update
You can use lazy (or delayed) loading and create an alternative route with a selective update.
Lazy loading is refusing to download additional data when it is not necessary. More on Habrahabr: "Increase the speed of loading the site using lazy-load images" , Wikipedia , the article "Lazy Load (Lazy loading) . "
Selective update is a trick that a Polymer team has come up with. This technology makes components appear only when they are really needed. When the user decides to go to another section, the necessary objects that were already in the document are initialized due to context switching.
To avoid the Sinister Valley when structuring and using PWA, the Polymer team developed a PRPL model as a guide to action. This model consists of 4 steps:
1) push through (Push) resources for the initial route;
2) provide (Render) the initial route as soon as possible;
3) pre-cache (Pre-cache) code in order to leave routes;
4) lazy load (Lazy load) and the creation of the following routes on demand.
Alex advised everyone to familiarize themselves with the Polymer App Toolbox in order to simply try, and also provided a list of resources (see below) to further study the service worker and PWA: “I can't wait to wait until we start building a web network much faster.”
Resources
Source: https://habr.com/ru/post/325788/
All Articles