Chapter 1. The Mobile Web World

The topic of performance on the mobile web might seem confusing at first. Isn’t the mobile web the same web as the one we already know?

The answer is not so simple. Yes, it’s the same web; but the context in which it’s being accessed—from a variety of browsers, devices, screens, and networks—is very different. Those differences play a big role in determining performance—or the lack of it—and that’s why we need to pay special attention to the mobile web.

Fortunately, following the idea originally stated by Luke Wroblewski in Mobile First, if you first apply performance techniques for mobile devices, your website will also perform well and faster on other kinds of devices, including desktops and TVs.

Mobile Performance First

If you have a multidevice web solution, starting to optimize the mobile web performance will also help with other devices, such as when using desktop browsers. While most techniques in this book can be applied to both the classic and mobile web, some of them are specific to mobile devices’ problems and therefore it’s easier if we start with them.

Don’t get me wrong, I’m not pushing the idea of having a separate web. Ultimately, we are still talking about the same content and the same services, accessed from different devices. In this chapter, we’ll cover the differences from the desktop web, which we will call from now on the classic web—that is the web from the main browsers on typically desktop-based operating systems, such as Windows, macOS, or Linux.

We’ll define the mobile web as web content being accessed from a feature phone, smartphone, tablet, or wearable device. I know there are some hybrid devices that can fit into the classic web definition, but I think we all know where the line is.

Before getting into the performance side of the mobile web, we need to establish and clarify the differences between classic web platforms, such as on desktop PCs, and web platforms running on mobile devices.

Form Factors

Several form factors are available on the market, but if we focus just on mobile devices with web platforms we can divide them into:

  • Tablets

  • Phablets (phones with screens bigger than 5.5″)

  • Smartphones (phones using a big OS such as Android, iOS, or Windows)

  • Social devices (cheap phones with web access using operating systems like Firefox OS, Nokia Ashas, or feature phones—these are starting to disappear these days)

  • Smartwatches

In this book, we’ll focus on smartphones, phablets, social phones, and tablets, but some techniques and tools might also be useful for other form factors.

Mobile Hardware

In the future, there might come a point when mobile devices will be more powerful than desktops and laptops (mostly because the technology is going in that direction), but we are not there yet. Mobile devices have less RAM available and less-powerful CPUs.

I know you might think this is not true, in an age of octa-core mobile devices, but the reality is that the average mobile device out there is not the most expensive device. And this is particularly true in certain regions in the world, such as Asia, Africa, and Latin America.

Note

If you are reading this book, you probably don’t have an average phone in terms of hardware and network access. When thinking about performance, always think about average users and test on those devices.

There are dozens of differences between mobile devices and classic desktop devices, such as screen resolutions, screen densities, and hardware sensors, but the ones that might affect web content’s performance are:

  • CPU, where the parsing, rendering, and execution happens

  • Memory, where the DOM tree, image buffers, and decompression data are stored

  • GPU, where, when available, some rendering happens (usually known as hardware accelerated)

  • GPU memory, where, when a GPU is available, some image buffers and layers are stored

We can roughly say that in terms of CPU, an average mobile device will be about five times slower than an average desktop device acquired at the same time. In terms of RAM, the difference is around three times smaller.

Mobile Networks

We have 4G now! We don’t have performance problems on the network anymore.

A random web developer

Mobile devices connect to the network in different ways, usually using a WLAN (WiFi) connection or a cellular connection.

WiFi access can be reliable (such as a home or office connection) or unreliable (such as at a coffee shop or on a plane or a bus, where it usually goes through a cellular connection).

Cellular connections are far less reliable compared to WiFi access because of the nature of the system. We are connecting wirelessly through radio waves, to a remote wired connection (in a cell tower up to a couple of miles from us). The connection changes cells, availability, and connection type frequently—more frequently if we are on the move.

Cellular connections today are usually known by popular names, such as 2G, 3G, and 4G. However, those names are used as a shorthand to refer to several different underlying connection types, such as:

  • GPRS (2G)

  • EDGE (2G, 2.5G, or 3G)

  • UMTS (3G)

  • WCDMA (3G)

  • HSPA (3G)

  • EVDO (3G)

  • HSPA+ (3G or 4G)

  • Mobile WiMax (4G)

  • LTE (4G)

Distribution

Although it’s easy to assume that 4G is now everywhere, particularly for those in urban areas, in reality, that’s far from the case.

At the end of 2015, according to GSMA Intelligence, 58% of the world was connected through 2G, 32% through 3G, and only 9% through 4G.

The values change when talking about developed countries, including the United States, but still 20% of the users were on 2G, 55% of the users on 3G, and just 25% on 4G.

5G Americas also has a chart of 4G penetration as of 1Q 2016 that shows that North America accounted for 20% of connections, Western Europe 11%, and all other regions outside of Oceania and Eastern and Southeastern Asia just under 13% combined.

The other important data here is that even when you have a 4G device and you have a 4G carrier, 30% of the time you might not be using that connection but downgrading to 3G or 2G. Open Signal has great deep information on this problem; it states that US 4G users are not using 4G 23% of the time while in Germany it can be up to 50%.

Also, on unlimited plans, most carriers have a data limit. When you reach that limit, you are mostly downgraded to 2G, even if you are in a big US city with the latest iPhone or Android device.

All this data means that we will be living with 2G and 3G connections for a while, and we need to pay special attention to this when we are providing mobile services.

Bandwidth

The first thing that comes to mind when talking about 3G or 4G is bandwidth. And it’s true: better connections mean higher bandwidth.

The bandwidth available on average in each type of connection is shown in Table 1-1.

Table 1-1. Mobile network speeds in Megabits/second (Mbps)
Network Minimum Maximum Averagea

2G (EDGE)

0.1

0.4

0.1

3G

0.5

5

1.8

4G

1

50

3.2 (HSPA+), 12.6 (LTE)

WiFib

1

100

5

a Data by Open Signal State of LTE Report

b Measured by Open Signal on mobile apps

However, the question for us is: how important is the bandwidth when we are delivering mobile web content? More bandwidth is usually better, but the difference will not be huge because we are transferring just a bunch of small files. If you are doing video streaming, then bandwidth will be more important.

Latency

And here comes the biggest problem on mobile networks: the wireless network latency. The latency is the time it takes for the mobile device to send a data packet to the server. Usually we measure the round-trip time (RTT) latency—that is, the time it takes to get the first byte from the server after making a request.

Latencies can be up to 1 second on 2G networks—that means the browser will wait 1 second per request before starting to receive any actual data. Even on 4G (which, remember, accounts for just a small percentage of users worldwide), the RTT can be up to 180 milliseconds. Just to make a comparison with your home wired connection, a DSL in the United States has an RTT latency of 20 to 45 milliseconds.

Table 1-2 shows you the latencies we can find today in mobile networks.

Table 1-2. Mobile network latencies in milliseconds
Network Minimum Maximum Compared to average home

2G (EDGE)

300

1000

+20x

3G

150

450

+9x

4G

100

180

+4x
Note

RTT latency is a big problem for the mobile web, because a typical mobile website or web app is composed of a group of small files that travel through the network as several requests, each one with RTT overhead.

If you are wondering why we have the RTT latency, it’s caused by the network architecture involving:

  1. The travel time from the phone to the cell tower (wireless)

  2. The travel time from the cell tower to the carrier gateway (wired or wireless)

  3. The travel time from the carrier gateway to the Internet (mixed)

  4. The same travel time (1 to 3) in reverse order

When you are connecting to the web using a home or office connection, you are skipping travel times 1 and 2 from this list.

Radio state

The final characteristic of a mobile network is radio state changes. Your mobile device has a radio, the one used to send and receive data to and from the cell tower. That radio consumes battery, so the mobile operating system usually tries to save its usage to reduce battery consumption.

That means that if no app is using the network, the mobile device will switch the radio from active state to idle state. As a user, you don’t know the current radio state. When any app or website tries to gather some data from the network, the device will restart the radio, and that usually involves time. On 3G connections, the time can be up to 2.5 seconds, while on 4G connections, it’s usually less than 100 milliseconds.

Therefore, if the radio was in idle state, the first RTT latency will also have an overhead.

Note

You might be thinking: I’m not a network operator, what can I do from a web point of view about this? Throughout this book, we’ll see techniques and best practices to improve performance and perception thanks to having an understanding of these network problems.

Mobile Operating Systems

For the purposes of this book, we’ll focus our attention on the main mobile operating systems based on current market share. Most of the explanations and techniques will also be useful for other operating systems, and I’ll make some comments when something might be different.

The main operating systems are:

  • iOS

  • Android

  • Windows

For Windows, we’ll focus on the versions available on phones (formerly known as Windows Phone), with some comments on Windows for tablets.

Note

Fire OS is an operating system created by Amazon that powers the Kindle Fire series and the Fire Phone. Fire OS is a UI layer on top of Android, so from an OS perspective we’ll be considering it as Android. Nokia took a similar approach for one year with Nokia X, an Android-based platform that was discontinued by Microsoft in mid-2014. Both projects use different web runtimes and web browsers compared to the original standard Android flavors, meaning different techniques to test and debug for performance.

Besides the main operating systems, in the mobile space today we can also find a small number of devices using:

  • BlackBerry 10

  • Firefox OS

  • Tizen

  • Sailfish

  • Ubuntu

There are also other obsolete operating systems that we won’t cover in this book, as they have less than 0.5% market share at the time of this writing and don’t have any future. These include:

  • Symbian

  • MeeGo

  • webOS

  • Nokia Series 40

Warning

While most techniques in this book will also be useful on desktop devices, we will not focus here on Windows for desktop, macOS, Linux, or Chrome OS.

Engines

Before getting into the analysis of the current state of the mobile web, let’s do a quick review of web rendering engines and execution engines that will be useful to understand some references in the rest of this book.

Rendering Engines

The rendering engine (also known as the layout engine) is the code that will be downloading, parsing, and rendering your HTML and CSS code on the screen, as well as other related content, such as SVG or images.

With regard to mobile devices, for years the king of rendering engines was WebKit, powering browsers on iOS, Android, BlackBerry, Symbian, and many others.

Today, in the mobile space we can find the following rendering engines available:

  • WebKit

  • Blink

  • Trident

  • Gecko

  • Presto

Created by Apple in 2001, WebKit is an open source project based on KHTML (another engine available for Linux-based browsers created in 1998) to support the Safari browser. The component related to layout and rendering is known as WebCore. Many companies have been using WebKit in the mobile space for years, including BlackBerry, Nokia, Google, Samsung, and Palm. It’s today the most used rendering engine in the mobile space.

Note

When we talk about WebKit, we are usually talking about WebCore, the part of WebKit that is responsible for parsing and rendering HTML and CSS.

The great thing about WebKit is that most web platforms in the mobile world are using it. This means that even on very different mobile devices we can expect very similar web rendering with simple markup and styles, which is good news for developers. However, it isn’t perfect—as we’ll see in later chapters, many differences do exist between WebKit implementations, as well as in HTML5 compatibility.

Google Chrome was using WebKit until 2013, when it decided to fork it and continue it in a separate path with the name Blink. Today, in terms of performance Blink and WebKit are different even though they share the same source. Blink powers Google Chrome and Opera.

Trident is the proprietary engine inside Internet Explorer, while Gecko is an open source engine managed by the Mozilla Foundation. Neither of them has gained much traction in the mobile space yet, but they have enough market share to pay attention to them. From Windows 10, a new engine was born on Microsoft Edge; while it was originally based on Trident, it was rewritten almost entirely.

Finally, Opera used Presto—its own proprietary engine—for years on its mobile browsers, but as of Opera 12, switched to Blink, ceasing future updates of Presto. However, even today there are still users browsing the web with older versions of Opera using this engine. The Presto engine is still being used on Opera proxy-based solutions, such as Opera Mini, where the rendering happens server-side.

Execution Engines

When you have JavaScript code, the execution engine comes into action. It’s the runtime that interprets your code, manages the memory for your variables and objects, and interacts with the platform behind it—usually, a browser.

We need to separate the life of JavaScript execution engines into two eras: classic and just-in-time (JIT) compilers. Classic engines interpret JavaScript while executing, while JIT engines precompile the JavaScript code into native code before executing it, with a big improvement in terms of performance.

The first of the new engines was Carakan, created by Opera for its desktop browser; this was followed by V8, an open source JavaScript engine developed by Google that is currently used in Google Chrome and other projects such as Node.js. Other modern JavaScript engines include JägerMonkey (Mozilla Foundation), IonMonkey (Mozilla Foundation, since 2013), Nitro (also known as SquirrelFish), and Chakra (Internet Explorer).

Note

Execution engines with JIT compilers can run JavaScript code between three and five times faster on the same device.

Older engines with no precompilation features include the original JavaScriptCore—part of the WebKit project—and SpiderMonkey (originally used in Netscape, later in Firefox). As of 2016, JavaScriptCore includes the FTL JIT compiler B3.

Web Platforms

A web platform is the scope where our web content is being executed and parsed. We can start categorizing the mobile web platforms today into:

  • Web browsers

  • Web apps

  • Web view–based content

  • Ebooks

Ebooks are out of the scope of this book, but I will say for now that latest versions of EPUB (the standard format for publishing ebooks) and MOBI (the Amazon proprietary format) are using HTML5-based content. Therefore, interactivity comes in the form of JavaScript running inside the ebook reader.

While I’m pretty sure you already know what a web browser is, you might have some doubts about the exact definitions of the other platforms. Let’s talk about them before we get into the world of web browsers on mobile devices.

Web Apps

While the definition is not 100% written in stone, at least from this book’s perspective, a web app is web content that is installed in the Applications menu or the home screen of a device and has a Chromeless user interface in the operating system.

You can think on of a web app as a website on steroids; from a user’s perspective it looks like an installed app, but from our perspective we are talking about web content in HTML5, CSS, and JavaScript.

Web App Synonyms

Web apps are sometimes known as home screen web apps or full screen web apps. Also, a new name has appeared lately: progressive web apps, including similar solutions but with new techniques.

From a performance point of view, a web app includes:

  • A server that is hosting the files

  • A possible local resource installation

  • A declaration of metadata for the installation process

  • A web rendering engine and a JavaScript execution engine loading the content, with or without the context of a browser process

There is no compilation or package process. Web apps can be installed from a browser or from an app store.

Warning

While on some operating systems a web app runs on exactly the same engine as a website, on others the engine might differ, meaning different performance measurements and techniques.

At the time of this writing, the web app platforms available are:

  • iOS home screen web apps

  • Progressive web apps (available at the time of this writing mostly on Android using Chrome, Firefox, Opera, or Samsung Internet, with Windows support coming in 2017 with Edge)

There were some other platforms supporting web apps that today are considered obsolete, such as Series 40 web apps and MeeGo web apps, both from Nokia, before Microsoft’s acquisition.

iOS Home Screen Web Apps

On iOS—the operating system behind iPhones, iPod touches, and iPads—Safari has an option to “Add to the Home Screen” any website. By default, when the option is activated, Safari adds a shortcut to the website on the home screen, as we can see in Figure 1-1.

If the website has the proper declaration through <meta> tags, when the user adds the website to the home screen, the icon becomes a web app. A web app runs in full-screen mode, it appears as a full app from the operating system’s perspective, and it doesn’t run under Safari, as we can see in Figure 1-2.

hpmw 0101
Figure 1-1. On Safari, we can add a website to the home screen to get an icon as an application. Here, we add forecast.io to illustrate the process.
hpmw 0102
Figure 1-2. When a web app has the right metadata, it runs in full-screen mode, outside of the scope of Safari. From an operating system’s point of view, it’s a separate app from Safari.

For the purposes of this book, we won’t get into too much detail about how to create these web apps. If you want more insights, check out my book Programming the Mobile Web (O’Reilly). However, let’s say that the main reason for getting a homescreen web app is using the following <meta> tag:

<meta name="apple-mobile-web-app-capable" content="yes">
Note

If you have never seen a web app on iOS, you can try these examples from Safari iOS: Financial Times, AliExpress, or Forecast.

Web apps on iOS run under a process known as Web. This process uses the same WebCore and Nitro engine as Safari but it also adds its own set of features and bugs.

iOS web apps didn’t have the JIT Nitro engine for a couple of versions when this faster engine appeared on Safari. This absence led to several criticisms in the press about Apple not pushing web technologies. From version iOS 5.0, the home screen web apps are using the much faster engine instead of the older JavaScript code.

Warning

On iOS, home screen web apps are usually the target of several bugs when a new version appears. If you are creating these kinds of solutions, keep in mind that you should retest your app after each iOS release.

Chrome Home Screen Web Apps

Google Chrome for Android (since version 33) also supports home screen web apps using the same mechanism: the user can select the option from the menu and a new icon will appear on the home screen, as shown in Figure 1-3.

As in iOS, the web app appears from an OS point of view as a different document, and in terms of performance and engines, it is using the Chrome you have installed on your phone. That means that if you update Chrome from the Play Store, the web app’s engine will also be updated.

Remember that a website is not a web app by default after adding it to the home screen. The website has to declare a manifest file for Chrome to consider it as a web app. Without the manifest, the icon on the home screen will just open Chrome, as for a normal website.

hpmw 0103
Figure 1-3. Chrome for Android has the ability to install a web app through the drop-down menu. Here, forecast.io installation is illustrated step by step.

If you want to learn more about Chrome home screen web apps, visit the Chrome Developer’s Guide.

Warning

While sharing an engine and code from Android 4.4, home screen web apps and web views have different compatibility and performance when running on the same device.

Progressive Web Apps

After Chrome added support for home screen web apps, the team evolved the concept, adding more features to what is now known as a progressive web app (PWA). A PWA is a website running in a browser that will progressively add more features based on compatibility. The features involve using service workers for offline usage, optional web push notifications, and letting the user install the web app in the home screen through the manifest.

On compatible browsers, if you meet some conditions, the browser will ask the user if she wants to install the PWA into the home screen, creating a fully offline-capable app experience on the device.

PWAs are compatible at the time of this writing with Chrome, Firefox, Opera, and Samsung Internet browsers on Android. Microsoft has announced PWA support coming to the Edge browser on all their platforms starting in 2017. In terms of web rendering engine, a PWA will use the engine from the browser from which it was installed. Therefore, you can have several icons on the home screen pointing to the same PWA but running on different web engines if you install it from several browsers.

The installation part of a progressive web app is available thanks to the Web App Manifest.

Note

PWA Rocks is a progressive web app gallery maintained by the Opera team.

When you update the browser, it will automatically update the web rendering engine for all the PWAs installed on that device.

Note

Firefox has created an open platform for web apps for Android and Firefox OS (an operating system that was available for mobile devices for a while). The Open Web Apps platform was deprecated in favor of progressive web apps in 2016, and it won’t have any further development.

Summary of Web Apps

Web apps are a way to install apps without the need for native compilation and store distribution, based 100% on web content. Table 1-4 provides information on the engines available.

Table 1-4. Web app engines
OS Devices Versions Rendering Execution Process

iOS

All

2.0–4.3

WebKit

JavaScriptCore

Web.app

iOS

All

5.0+

WebKit

Nitro

Web.app

Android with Chrome

All

4.0+

Blink

V8

Chrome

Android with Firefox

All

2.3+

Gecko

SpiderMonkey

Firefox

Android with Opera

All

4.0+

Blink

V8

Opera

Android with Samsung

All

4.1+

Blink

V8

Internet

Remember, when we are talking about web apps we are not packaging the contents in a ZIP file or similar container, such as APKs (Android packages) or IPAs (iPhone applications). We are using just a normal web server to host the files, and those files will run in a full-screen environment.

Web Views

A web view is a native control available on most platforms (similar to buttons, labels, and text inputs) that allows a native app to include and run web content. The web view can use the entire screen or just a small portion of it.

While most of the techniques in this book will apply to web view–based content, later on we’ll focus specifically on web view–based platforms. We need to consider web views separately because while they sometimes share the same engine as the default browser on the device, performance techniques will vary.

Web views can be used for different purposes, including to:

  • Show rich content

  • Execute JavaScript code

  • Show animations or ads

  • Show an in-app browser

  • Create a pseudo-browser

  • Create the entire user interface and logic with web content (usually known as a native web app or a hybrid app), such as an app using Apache Cordova or PhoneGap

  • Create a native shell for a web app

Warning

While working with web view–based solutions, we need to understand that the same code on different devices might run on different engines. Even on the same device, after an OS update the engines will be updated, meaning that our code is not guaranteed to run in exactly the same way. If we follow good practices, we will reduce the risk of incompatibilities in the future.

Native Web Apps

On some platforms, we have an official set of tools to create native apps from web content without creating a native project and adding a web view. These platforms are using the web view inside.

Some platforms that will use the web view in the background are:

  • Apache Cordova (also known as PhoneGap), including if you build using the PhoneGap Build service from Adobe

  • JavaScript Windows apps

  • BlackBerry WebWorks

  • Amazon Web Apps for Fire OS and Android

  • Tizen apps

Compared to the web apps we covered before, a native web app or hybrid involves:

  • Packaging the web content into a ZIP file or platform-specific container

  • Creating a manifest declaration

  • Signing the package

  • Distributing the app as a native app on app stores

Warning

We shouldn’t confuse a native web app platform running web content on the fly on the device with cross-platform solutions that might start with web content but precompile it into native code before publishing it. No web view is involved in these cases. Appcelerator, ReactNative, and NativeScript are examples of these tools; you write JavaScript but it is compiled into native code.

In native web apps, we are not hosting the files on a web server but inside the app’s package. This will be a big difference when talking about performance.

In-App Browsers

Some native applications have the need to show you a website, but don’t want you to leave the app. This happens mostly on iOS, where before iOS 9 you didn’t have a back button to quickly go back to the app after opening the browser. Even with a small back button available since iOS 9 in the status bar, most apps still want to have in-app browsers. Great examples here are Facebook (see Figure 1-4), Twitter, and Flipboard.

hpmw 0104
Figure 1-4. Some iOS apps include an in-app browser mechanism, such as Facebook, which allows you to browse a friend’s suggested website without opening Safari

According to ScientiaMobile’s Mobile Overview Report (MOVR), from October 2015 to April 2016, 33% of the web traffic coming from iOS and 40% from Android was received from inside a native app that is not marketed as a browser, Facebook being the most prominent app (accounting for 95% and 86% of this traffic, respectively).

Note

When you see an app with an ad on iOS or Android there is a good chance that it’s using a web view, because both iAd from Apple and AdSense from Google are using this control for in-app advertisements.

Pseudo-Browsers

I’m pretty sure you’ve never heard about pseudo-browsers. It’s really a new category that I defined a couple of years ago. A pseudo-browser is a native application marketed as a web browser that, instead of providing its own rendering and execution engines, uses the native web view.

From a user’s point of view, it’s a browser. From a developer’s point of view, it’s just the web view with a particular UI. Therefore, we have the same rendering engine as in the preinstalled browser, but with a different UI. These pseudo-browsers are mostly available for iOS and Android, and they offer the same service as the native browsers but with different services on top of them.

Warning

On iOS, the web view is upgraded with the operating system. There is no way to update or change it as a separate component. Because of an App Store rule, we can’t provide our own web engine inside an iPhone native app, as in other operating systems.

This can lead to some philosophical questions about what a browser is. From a developer’s perspective, it’s important to understand that pseudo-browsers are not adding fragmentation—they’re not new engines, but simply the web view from the operating system.

Chrome on iOS is the best example of a pseudo-browser; because Apple has a restriction on using third-party engines, Chrome uses the iOS web view instead of a Blink-based engine.

The main difference with an in-app browser is that in that case, the app is not marketed as a browser—you can’t say that Facebook, for example, is a web browser, even though it now has an in-app browser on iOS and Android.

Other examples on iOS are Firefox and Brave.

The Web View on iOS

The web view available on iOS is WebKit-based, and while some people will consider the web view as an embedded Safari, the reality is different.

First, on iOS since version 8.0, we have two web views available: the old one (known as UIWebView) and the new one (known as WKWebView). While we will talk more about this later in this book, from our point of view it’s important to understand that performance on both web views will be different.

To clarify the engines behind iOS, take a look at Table 1-5.

Table 1-5. iOS web engines
Type Versions Rendering Execution

Safari and Safari View Controller

1.0–4.2

WebKit

JavaScriptCore

Safari and Safari View Controller

4.3+

WebKit

Nitro JIT

Web app

2.0–4.3

WebKit

JavaScriptCore

Web app

5.0+

WebKit

Nitro JIT

UIWebView

All

WebKit

JavaScriptCore

WKWebView

8.0+

WebKit

Nitro JIT
Note

On iOS, the difference between using JavaScriptCore and Nitro with the JIT compiler is a factor of 3. That is, on the same device, JavaScript code running on UIWebView will be at least three times slower than the same code running on WKWebView or Safari. However, we will see later that JavaScript execution time is just one part of the total time a page takes to load, so this doesn’t mean your website loads three times slower.

The Web View on Android

For years, the web view on Android was the cause of many companies not using HTML5 for creating native apps. The web view was extremely slow on Android 2.x; it got better on 4.0 but wasn’t really good enough until 4.4.

Until Android 4.3, the web view was based on WebKit, and from 4.0 to 4.3 it was pretty much the same version without any changes or updates in terms of performance or compatibility.

Because of this problem, some Android manufacturers, including Samsung and HTC, have decided to replace the default web view with a modern version of WebKit or Chromium (the open source version of Chrome with Blink and V8, much faster and compatible with modern HTML5 features). The problem is that on each device and version of the operating system, the version of WebKit or Chromium (as well as the features and abilities enabled) might be different.

Amazon for Kindle Fire has kept the original Android web view but also added a second web view, known as Amazon Web View (based on Chromium 18), from the Kindle Fire 2nd Generation. Finally, on the Fire Phone, Amazon has decided to just replace the default web view on Android 4.2 (the version it uses) with its Amazon web view.

From Android 4.4 (KitKat), Google has decided to replace the web view on Android with Chromium to keep everything under one umbrella again, starting with Chromium 30 (equivalent to Chrome 30) and following with version 33 in the small 4.4.1 update.

Warning

Even if they have installed Chrome, or Chrome came pre-installed, users on Android 4.0–4.3 will execute web view–based code on WebKit and a non-JIT JavaScript engine by default.

Since Android 5.0, the web view is based on Chromium 39, and it has become—for the first time—updatable from the Google Play Store, meaning that the user can install new versions of the Chromium-based web view without waiting for the next version of the operating system. Therefore, now web view–based solutions can keep up to date with Chrome’s new features.

Warning

Some people are treating Android Browser as a modern Internet Explorer 6: a slow, noncompatible browser that is difficult to get rid of from the market and that we need to still support. In July 2013, I wrote about this issue in the article “Android and the Eternal Dying Mobile Browser”.

Table 1-6 provides a summary of what the web view world on Android looks like today.

Table 1-6. Android web view engines
Devices Versions Rendering Execution

Alla

1.0–4.3

WebKit

JavaScriptCore

All

4.4

Chromium 30

V8 JIT

All

4.4.1

Chromium 33

V8 JIT

All

5.0+

Chromium 37+ (updatable via store)

V8 JIT

Samsung

4.1–4.3 (some devices, such as S3 and S4)

WebKit

V8 JIT

Samsung

4.1–4.3

Chromium (Blink)

V8 JIT

HTC

4.1–4.3

WebKit

V8 JIT

Amazon Kindle Fire (using alternative web view)

4.0+

Chromium (Blink)

V8 JIT

Amazon Fire Phone

4.2+

Chromium (Blink)

V8 JIT

a Not including Samsung, HTC, and Amazon devices with custom web views.

Tip

Intel has created an open source project based on Chromium called Crosswalk that offers us an injectable web view for Android 4.0+, supporting the latest versions of Chrome. If we use it, we will be normalizing all the web views on Android but delivering a bigger Android app file.

The Web View on Windows

The web view on Windows (formerly also known as Windows Phone), such as on Microsoft Lumia devices, is far simpler than that on Android or iOS. It uses Trident and Chakra, the engines behind Internet Explorer, which up to Windows 8.1 differ depending on the version of Windows.

For example, on Windows 8 the engine is the same as in IE10, and on Windows 8.1 it is the same as in IE11. From Windows 10 in all versions (mobile and desktop), the engine was replaced by Edge, removing all the old IE stuff.

While technically you can inject your own web view in a native desktop Windows app, there are no options to do that for mobile phones at the time of this writing.

Summary of Web Views

We now know that web view engines can be pretty different on different devices—even on the same version of the operating system. Table 1-7 shows the current state of web views with their rendering and execution engines.

Table 1-7. Web view engines
OS Devices Versions Rendering Execution

iOS UIWebView

All

All

WebKit

JavaScriptCore

iOS WKWebView

All

8.0+

WebKit

Nitro

Android

All

2.x

WebKit

JavaScriptCore

Android

Alla

4.0–4.3

WebKit

JavaScriptCore

Android

All

4.4+

Blink

V8

Android

Amazon Kindle Fire

4.0+

WebKit

JavaScriptCore

Android

Fire Phone

4.0+

Blink

V8

Android

Some Samsung devices

4.0–4.3

WebKit

JavaScriptCore

Android

Some Samsung devices

4.0–4.3

Blink

V8

Android

Some HTC devices

4.0–4.3

Blink

V8

Windows

All

7.5–8.1

Trident

Chakra

Windows

All

10

Edge

Edge

Windows

All

Android Runtime

Blink

V8

BlackBerry

All

7.0–10.2

WebKit

JavaScriptCore

BlackBerry

All

10.3+

Blink

V8

Tizen

All

All

WebKit

JavaScriptCore

a Excluding Amazon, Samsung, and HTC devices with custom web views.

Web Browsers

When talking about the classic web, usually web browsers are the only platform we care about. In the mobile web, it’s for sure the most important category but not the only one, as we’ve just seen.

Now that we have looked at the web view and web app platforms, it’s time to discuss browsers. I won’t make a big list of mobile browsers here, but will provide just enough information to help you understand where users are browsing the mobile web, as that might affect our performance analysis and techniques.

We have already covered the most important operating systems that we will follow in this book, such as iOS, Android, and Windows. And maybe you are thinking that in terms of browsers it’s easy: Safari, Chrome, and Internet Explorer/Edge. That’s a typical mistake—in reality, it’s a bit more complex.

Stats

Instead of just guessing, we can check different sources that will give us some hints on the current state of affairs. Unfortunately, there are several sources with different measurement methods.

Note

If you are using an analytics tools such as Google Analytics, you can check information about your own website and compare it with the global data from these sources.

The sources available for checking information on mobile browsers are:

I processed all those sources to reach some conclusions. Table 1-8 shows what the market share in terms of browsers looked like at the end of 2015. The table does include web views when used for browsing the web, such as in-app browsers (e.g., inside Facebook) and pseudo-browsers (e.g., Chrome on iOS).

Note that the data will change radically depending on whether you count tablets as contributing to mobile browser share, as Safari for the iPad accounts for a lot of traffic.

Table 1-8. Mobile web browsers global market share
Browser Operating systems Engines %

Safari and web view

iOS

WebKit

45%

Chrome

Android

Blink

23%

Android Browser

Android

WebKit

15%

Samsung Browser

Android

Blink

7%

Operaa

Mixed

Presto

3%

Internet Explorer

Windows

Trident

3%

UC Browser

Mixed

U3 (proprietary engine)

3%

Firefox

Android and Firefox OS

Gecko

1%

Nokia Browser

Symbian

WebKit

<1%

Nokia Browser

Series 40

Gecko

<1%

Nokia Browser

Android (Nokia X)

Chromium

<1%

BlackBerry Browser

BBOS

WebKit

<1%

Samsung Dolfin

Samsung

WebKit

<1%

Amazon Silk

Fire OS

Blink

<1%

a Mostly Opera Mini.

Warning

If your website or web app is targeting specific countries or regions, you should be aware that mobile browser market share might change a lot based on the region. In Asia, you will see more than 30% of users using UC Browser, while the old Nokia and BlackBerry Browsers with Internet Explorer might account for 10% and iOS for only 15% in Latin America.

Cloud Versus Direct Browsers

Direct browsers get content directly from the website server, and cloud browsers (also known as proxied browsers) go through a proxy server in the cloud. The proxy server usually does many of the following actions on the fly:

  • Reduces the content, eliminating features that are not mobile-compatible

  • Compresses the content (images included)

  • Prerenders the content, so it can be displayed in the browser faster

  • Converts the content, so we can see Flash video on devices with no Flash support

  • Encrypts the content

  • Caches the content for quick access to frequently visited sites

  • Potentially blocks ads

Cloud-based browsers, such as Opera Mini, consume less bandwidth, increasing performance and reducing total navigation time at the same time. From a developer’s perspective, the main difference is that the device is not directly accessing our web server; it’s the proxy server in the cloud that is requesting all the files from our server, rendering those files in the cloud, and delivering a compressed, proprietary result to the browser. Usually there is no client-side interaction happening in these browsers.

Note

Tim Kadlec did a great job analyzing proxy-based browsers in his article “Understanding Proxy Browsers: Architecture”.

Google Chrome, Opera Mobile, Internet Explorer, and Amazon Silk offer a cloud compression mechanism as an optional feature to their direct browsers, as we can see in Figure 1-5. The feature needs to explicitly be enabled by the user (choose “Reduce data usage” in Chrome, “Off-Road mode” in Opera, “DataSense” in IE, and “Compression in Silk”) and there is no data available on how many users are currently enabling the option.

hpmw 0105
Figure 1-5. Because performance is a top priority in mobile web browsing, some browsers, including Chrome, Opera, IE, and Silk, offer you an option to enable a proxy compression option

Stock Browsers

Practically every mobile device on the market today has a preinstalled browser (also known as the stock browser). The average user typically doesn’t install a new web browser; therefore, on each device the preinstalled browser is the most-used one. One main disadvantage of preinstalled browsers is that sometimes there is no way to update the browser independently from the operating system. If your device doesn’t get operating system updates, usually you will not get browser updates.

iOS Browsers

In iOS, there is a simple and single answer: Safari. We saw that nearly half of the mobile web traffic comes from iOS, and fortunately all the traffic uses the same engine.

If you are not browsing the web on iOS with Safari, it’s because you are using a pseudo-browser, such as Chrome, Firefox, or Brave, or an in-app browser, such as when clicking on a link inside Facebook. In any case, you are using the same WebCore. The JavaScript runtime might differ, though, as in different versions of the web view (UIWebView or WKWebView) we have JavaScriptCore or Nitro with the JIT compiler.

Note

According to Mobile Overview Report, 33% of iOS traffic comes from Facebook’s in-app browser, 5% from Twitter and other apps, and 3% from Chrome on iOS and other pseudo-browsers. Therefore, around 41% of iOS traffic is being executed in a web view and not inside Safari.

Android Browsers

Some developers and designers think that if we are talking about “the Android browser” we are talking about Google Chrome. Unfortunately, that’s not exactly the reality.

Android, as an open source operating system, doesn’t include Chrome, which is a non–open source browser. It has included a Chromium-based web view version since 4.4, and up to 4.3 it included a browser based purely on WebKit. This browser is usually known as Android Browser, the Stock Browser, or Android WebKit. The browser, while sharing roots with Chrome on WebKit, is a very different app in terms of performance and web compatibility, as you can see in Figure 1-6.

hpmw 0106
Figure 1-6. Here we can see HTML5test.com results on Android Browser 2.3, 4.0, and 4.3 compared with Google Chrome

From Android 4.4, Google has decided to remove support for that browser, but it didn’t replace it with Chrome (at least not technically). I know you’ve seen several Android 4.4+ devices with Chrome preinstalled. That is because the manufacturer (Samsung, HTC, Motorola, Sony, etc.) signed a separate agreement with Google to include Play Services and Google apps that are not part of the Android OS, such as Maps, Gmail, Inbox, Play Store, and Google Chrome.

Note

Because Google Chrome is not really part of the Android Open Source Project (AOSP) and it’s part of Play Services, it can be uninstalled, reinstalled, and updated from the Google Play Store by the user at any time. That’s not true of preinstalled browsers.

Because the default Android Browser wasn’t good enough, some vendors using Android as an operating system, including Samsung, Amazon, HTC, Nokia, and Barnes and Noble, have created their own custom versions of the default browser, sometimes WebKit-based (but more modern than the one used by Android), sometimes Chromium-based (using the Blink engine). Figure 1-7 shows a few examples.

And that’s not all, because some manufacturers and some carriers around the globe have made agreements with Opera or Firefox to replace the default browser with those versions.

Note

Some devices, such as the Samsung Galaxy series, include two different browsers preinstalled, such as Chrome—thanks to a Google Play agreement—and the Samsung Internet Browser (with Internet as the name of the icon; also Chromium-based on modern devices). The user has the choice to use one or the other.

hpmw 0107
Figure 1-7. Some manufacturers, such as LG and Samsung, include a preinstalled browser that is not Android Browser or Chrome. They are today usually based on Chromium, but as you can see here, with different compatibility with the original Chrome.

Table 1-9 gives us an idea of how complicated the preinstalled browser situation looks on Android. Remember, most users will use just that browser.

Table 1-9. Preinstalled browsers on Android
Browser Devices Version Engine Updatable

Android Browser

Alla

1.0–4.3

WebKit

no

Google Chrome

Manufacturers with a Play Services agreement

4.2+

Blink

Yes

Samsung Internet

Galaxy S3 and others

4.2+

WebKit

No

Samsung Internet

Galaxy S4 and others

4.2+

Blink

No

Nokia Browser

Nokia X, X+

4.1, 4.3

Blink

Yes

HTC Browser

Some

4.2+

Blink

No

LG Browser

Some

4.2+

Blink

No

Silk

Kindle Fire

4.2+

WebKit or Blink

No

Silk

Fire Phone

4.2+

Blink

No

Opera

Based on carrier

4.0+

Blink

Yes

Firefox

Kobo, Gigabyte devices

4.0+

Gecko

Yes

a Except those whose manufacturer replaced it by a custom browser.

Android users have several options from the Google Play Store in terms of downloading browsers, as we can see in Figure 1-8, including Firefox (Gecko), Opera Mobile (Blink), Opera Mini (cloud-, Presto-based), UC Browser (cloud-based), and Dolphin (Blink). Unfortunately, stats show that few users actually use additional browsers.

hpmw 0108
Figure 1-8. On Android, the user has the option to install several browsers on the same device from the Play Store
Note

According to the Mobile Overview Report, 34% of Android traffic comes from Facebook in-app browser and 5% from other in-app browsers. Therefore, around 39% of Android traffic is being executed in a web view and not inside a browser.

Windows Browsers

On Windows mobile devices, Internet Explorer (different versions based on the OS version) was the only browser available by default up to Windows 8.1. As of Windows 10, it was replaced by Microsoft Edge.

Some cloud-based browsers are available to download from the Windows Store, including Xpress Browser and UC Browser.

The Mobile Web Is Not Just a Narrow Viewport

In this chapter, we’ve covered the main differences of the mobile web as compared to classic web engines. It’s important to not underestimate these differences or the diversity of the mobile web—and to test, debug, and measure with multiple devices and scenarios in mind, in order to account for the variety of mobile devices, cellular networks, and browsers currently in use.

As a review, we’ve covered in this chapter:

  • Different engines in the mobile world, such as WebKit, Trident, and Blink

  • Different platforms, such as the browser, web apps, and web views

  • How different platforms and web views can define the performance of your solution

  • How the web browser market share looks on the mobile side

In the next chapter, we will analyze where to measure web performance before getting into the necessary tools and metrics and how to improve perception.

Get High Performance Mobile Web now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial