Notice:
This post is older than 5 years – the content might be outdated.
Last month the Chrome Dev Summit took place in Mountain View, California. On two days engineers of the Chrome team were talking about their work and the current state of the web. This article is a short summary of the event’s most important news.
Darin Fisher, the VP of Chrome, opened the conference by talking about the past, present and future of the web. The web becomes more and more important, he says—Especially the mobile web. Data which had been collected over a certain period of time shows how relevant the mobile web already is:
| Native Apps | Web Apps |
| ~25 apps used per month | 100+ sites navigated to per month |
| 3.3 million users per month | 8.9 million users per month |
| 2x more growth in traffic than native apps |
Putting these numbers into relation clearly shows that applications of the mobile web have more users in one month, more visits and a two times bigger growth in traffic than native apps. Hence the web is critical to everyone’s mobile strategy and should be treated accordingly.
Apart from the mobile web, Chrome still tries to improve on the web in general. Obviously Chrome isn’t the only browser out there, so the Chrome team is focusing on web standards to enhance the web for everyone.
Also features that had been previously introduced in Chrome are used more frequently. For instance, web app launches initiated by clicking an icon on a device’s home screen grew by 79%.
The whole event can be divided into three main topics: Progressive Web Apps, Accessibility/Diversity and Performance/DevTools.
Progressive Web Apps
The term ‘Progressive Web App’ describes the method of improving web apps step by step. The idea is all about using new capabilities as much as possible. At the same time a Progressive Web App also supports older browsers by leaving new features out, in case they don’t exist on that specific version.
To provide new capabilities the Chrome team shipped Service Workers, Push Notifications and the ability to add web apps directly to the home screen. All these features have been announced last year. They provide a good start for moving from native to web by offering completely new possibilities. At the same time advantages of web apps over native apps are clear:
- Every app can be shared through an URL
- Users don’t have to install apps and grant them permissions
- Discovering new apps via the web is very easy
- Users only have to add the app to their home screen, no store needed
In other areas, web apps are now en par with native apps:
- A notification that pops up after a site has been visited several times makes adding the app to the home screen easy
- Developers can use Web Manifest to provide metadata such as icons, colors or a description
With support for Service Workers, Chrome enables developers in making their web apps load instantly.
Service Workers are processes that can be registered and run in the background and serve as a proxy. This way content can be cached easily and can then be reused in situations where the user might not be connected to the network. To make it easy to use Service Workers, the following libraries are provided:
Push Notifications from the Web
Sending push notifications is another feature that has been enabled through Service Workers and can be used in Chrome right away. This standard helps engaging users by sending them relevant notifications. It’s important not to send too many notifications as this could harm user experience. The workflow is simple:
- Web server has new information and notifies the push service (e.g. Google Cloud Messaging)
- Push service sends notification to the target device
- Service worker’s push event gets triggered, where the final notification is created
- Push notification appears on the user’s screen
An engineer of Facebook also shared their experience with push notifications. He mentioned that using push notifications clearly drives visits. But it’s important to take care of some things. Developers should not ask for permission immediately. It is better to ask where it matters, so the user can understand what they are subscribing for. This leads to higher subscription rates and a better user experience. Users should also have the possibility to unsubscribe via the web app, itself otherwise they may feel forced into receiving notifications. Configuring the click on push notifications correctly allows developers to refocus the web app instead of opening a new tab. Chrome will provide custom actions within notifications soon, e.g. for unsubscribing with one click.
Asking for permission too early is not just a problem that comes with push notifications, it’s a problem in general. Users won’t grant permission as long as they don’t know what it’s good for. That’s why the opt-in rates are rather low. Only 6% give access to their location, mostly because sites are asking for it too early. The same holds true for notifications, where the opt-in rate is about 17%. To fix this, developers should ask for permission right before needing it. The Permission API supported in Chrome helps achieving this. Another good way of doing it is to tell the users what the app can do with a certain feature to motivate them to grant a permission.
Connecting the Web to the Real World
Chrome has also made an attempt to connect the real world with the web. By implementing Web Bluetooth, which isn’t a standard yet, Chrome is able to connect the web with physical devices. The concept is simple: Devices can be discovered through the browser. At the same time devices are broadcasting the URLs to their web apps, so that the user can access the respective web app just by clicking on it. This makes interactions with the physical world very easy, for instance someone could implement this technology into bus stops giving people the ability to get timetables directly onto their phones. On mobile devices developers can make use of the platinum-bluetooth component of Polymer, which allows them to discover nearby bluetooth devices. Although Web Bluetooth is still experimental, it’s already available on Chrome’s Dev Channel.
If you are looking for support building a ‘Progressive Web App’, Polymer offers some components. There is a collection of elements called App Layout, which already provides guidelines and templates to structure your app. It’s especially recommended for implementing responsiveness. Note that App Layout is still experimental. Polymer offers several other components to make use of new features. Another component is called platinum-sw-elements which is built on top of sw-toolbox and helps adding offline capability. To include push notifications in your app, the platinum-push-messaging component can be used. Overall Polymer is 36% smaller and 4 times faster than it has been before.
It’ also important to make the web more secure. Developers should migrate to HTTPS if possible, otherwise someone could for instance inject ads into your site and turn user experience into a usability nightmare. But that’s not the only reason: HTTPS also helps securing sensitive data like passwords. Accordingly, Chrome offers a couple of features, which allow to find and understand misconfigurations regarding HTTPS.
Accessibility & Diversity
Many developers don’t realize that emerging markets like India differ from developed markets. Connectivity can be limited, devices have lower performance or screen sizes may be smaller. 2G might be widely used, therefore developers should try to reduce data usage. Another good reason to keep the amount of transferred data small is that data can be expensive for people earning a low wage. Chrome’s DevTools can be used to simulate different networks so that developers are able to easily find out how their app is going to perform under limited connectivity. Simulating different screen sizes under Chrome is possible as well.
A topic often left behind is accessibility. Developers need to understand that some people might have to use a computer in a way that most people can’t even imagine. The blind often use a screen reader to access the content of an app whereas other people aren’t able to use a mouse or a keyboard. That’s why it is important to not just think of the regular user. Make your web app accessible for everyone.
Often browsers offer built-in features that provide accessibility that you can take advantage of. Use the Accessibility Developer Tools from Google’s Accessibility team to audit your app. Its results show, which rules have been violated by your app and help finding issues. During development it’s recommended to use a checklist to assure certain functionalities in regards of accessibility.
Performance & DevTools
Performance should be user-centric, because making the user happy is what matters. Following this thought engineers at Google came up with a performance model called RAIL. This model describes what time certain things are supposed take and distinguishes four categories. These categories are:
Response < 100 ms
Animation < 16.67 ms
Idle < 50 ms
Load < 1 s
Let’s start with the first category ‘Response’. Within 100 ms users should get a response to their input. For instance, you can show an hourglass just to let the user know that you already started processing their input. The second category is called ‘Animation’. Every animation should run at 60 frames per second, which means that every frame has a lifetime of 16.67 ms tops.
Another category is called ‘Idle’ and has a recommendation of 50 ms as a maximum for doing deferred work. By doing this, developers can ensure that the app still responds under 100 ms. If more time consuming tasks are executed, the recommendation for ‘Response’ is then probably hard to satisfy.
The last category and the most obvious one is ‘Load’. Loading the whole app shouldn’t take longer than one second, otherwise you might lose the user’s attention. There is no need for loading everything within a second. Just make sure your app looks complete after one second and the user gets more than a blank page. Non critical elements can be loaded afterwards.
Chrome’s engineers also have been working on their JavaScript engine V8. They started to release an update every 6 weeks to deliver improvements in caching, heuristics and ECMAScript adaptions quickly. In the past year the team has been working on a new optimizing compiler to make V8 even more performant. In addition garbage collection has been improved as well. This clearly shows how important the performance of V8 is. To offer newer features of JavaScript, support for ECMAScript 2015 has been further improved.
For the future the team is focusing especially on optimizing frameworks. As frameworks become more and more important the team wants to reduce loading times. By discovering usage patterns they want to get a better understanding of how developers use frameworks. This can then be used as a starting point for improving performance.
In 2015 the engineers of Chrome’s DevTools were focused on improving DevTools for building web sites. They put a lot of effort into making DevTools better for designers. Also mobile-first was considered an important point. Remote debugging for USB devices is now directly integrated into DevTools and doesn’t need to be accessed through a separate site anymore. Apart from that there is a new device mode with a better overview and a mechanism which makes testing for different screen orientations easier.
Many smaller improvements have been made as well. Users can now reorder tabs within DevTools or choose colors for their website from a color palette. Inspection of animations is another feature they added. Now animations can be inspected, replayed and edited right away. Even composed animations can be reviewed.
Increasing performance can also be done at a lower level, so switching to HTTP/2 is recommended. This offers a lot of features that give you the possibility to optimize your website’s performance. An advantage over HTTP/1.1 is that usually connections are TLS encrypted. Although unencrypted connections are possible, browsers like Chrome and Firefox won’t accept them. The limitation of connections in HTTP/1.1 can cost a lot of performance as well. For instance, in Chrome no more than 6 simultaneous connections are allowed. With HTTP/2 only one connection is needed because of a new transport model. What used to be a request response mechanism in HTTP/1.1 is now a logical stream. Every single response can now be written into it without having to wait for another request to complete. HTTP/2 also introduces header compression. Headers and data are split now, which allows headers to be compressed by HPACK, a special compression for HTTP headers. There is also the possibility to push a response to the client, which hasn’t even been requested. If the client requests it later, the request is being fulfilled on the client side right away. This can help speeding up websites. But pushing too much can slow down websites as well. So don’t push mindlessly.
Watch it on YouTube
Most talks from Chrome Dev Summit 2015 are available on YouTube, so head over there for all the details.
By loading the video, you agree to YouTube's privacy policy.
Learn more
Get in touch
Think I missed anything in my summary? Let me know in the comments below. If you liked this article, feel free to share it with your friends. For more information about mobile and web development visit our website, drop us an email at list-blog@inovex.de or call +49 721 619 021-0.
