The Current State of Progressive Web Apps

Dirk-Jan Rensema

A study on the performance, compatibility, consistency, security and privacy, and user and business impact of progressive web apps

Informatics

Bachelor Thesis

Term: VT20 Supervisor: Dr. Bridget T. Kane PhD Examiner: Prof. John Sören Pettersson

Abstract Since the late 80s the web has been evolving through new standards, added functionality, device performance and improved user experience. Websites evolved from static information to what is now known as web apps in which web technologies started to replace regular native programs and apps, as web apps slowly started offering similar functionality and performance, with the added benefit of being cross-platform. Over time, even more functionality and improvements were added to the web apps which, with the right combination, made them progressively become more like apps. In 2015, this combination got named by Google as Progressive Web Apps (PWA) which allow users to add web apps to their home-screens and use them like native apps. PWAs can support being used offline, give notifications, use the device’s hardware and more.

In this thesis, the compatibility, performance, security, privacy, and user/business impact of fundamental elements of PWA are researched through literature review and experimental analysis. Eight browsers are tested on four operating systems for compatibility of the Service Worker, Web App Manifest, add to home-screen ability and offline usage functionality. For performance, tests are done on a website called Fleet Management System (FMS) which is a track and trace system for Inter-Data Europe b.v. who will keep using the implementation and knowledge created from this study. For security, privacy and user/business impact, a literature review is done on past studies, use-cases and discoveries made during the implementation and tests.

The results show that most of PWA’s fundamental functionality is supported by most major browsers, especially on Android and on Chromium browsers, with the exception of iOS in which only Safari supports anything to do with PWA. Performance is found to be heavily dependent on implementation strategy but can make a significant difference if implemented correctly. Security is found to allow certain abuse and sensitive data leaks depending on implementation. Furthermore, user reengagement and revenue of major companies are found to increase significantly after implementing PWA.

Table of contents

1. Introduction ...... 1 1.1. Background ...... 1 1.1.1. The Web - History ...... 1 1.1.2. Web Apps ...... 2 1.1.3. The rise of the smart phones – Responsive design ...... 2 1.1.4. Websites disguised as Programs ...... 3 1.1.5. Progressive Web App – The natural progression ...... 3 1.1.6. Service workers ...... 4 1.1.7. Caching ...... 4 1.1.8. Manifest ...... 5 1.2. Purpose ...... 5 1.2.1. Target group ...... 6 1.3. Method ...... 6 1.3.1. Platforms and Browsers ...... 6 1.3.2. Research Question – Current state of PWA ...... 6 1.4. Ethical consideration ...... 8 1.5. COVID-19 ...... 8 2. Literature Overview ...... 9 2.1. Native, cross-platform frameworks and PWA ...... 9 2.2. Security, Privacy and Abuse ...... 9 2.3. Performance and compatibility ...... 10 2.4. Use Cases ...... 11 2.4.1. Trivago ...... 11 2.4.2. Uber ...... 11 2.4.3. Rooted Objects ...... 11 2.4.4. George.com ...... 12 2.4.5. Best Western River North Hotel ...... 12 2.4.6. Pinterest ...... 12 2.5. PWA Life Cycle ...... 13 2.6. Developing PWA ...... 13 2.6.1. Service Worker ...... 14 2.6.2. Web App Manifest ...... 16 3. Results ...... 17 3.1. Implementation ...... 17 3.1.1. Requirements ...... 17 II

3.1.2. Setup ...... 17 3.1.3. Manifest ...... 17 3.1.4. Service Worker ...... 18 3.1.5. Cache-first implementation ...... 20 3.2. Compatibility ...... 20 3.2.1. Service Worker ...... 20 3.2.2. Web App Manifest ...... 21 3.2.3. Add to home screen capability ...... 22 3.2.4. Offline usage ...... 24 3.3. Performance ...... 25 3.4. Security and Privacy ...... 25 3.4.1. Push-notification abuse ...... 25 3.4.2. Cryptocurrency mining ...... 26 3.4.3. Authenticated pages being cached after session expiration or logout ...... 26 3.5. User and Business impact ...... 26 4. Analysis and Discussion ...... 27 4.1. Compatibility Analysis ...... 27 4.2. Performance Analysis ...... 27 4.3. Security and Privacy Analysis ...... 28 4.4. FMS Analysis ...... 28 4.5. User and Business impact ...... 29 4.6. Summary ...... 29 5. Conclusion and Recommendations ...... 30 5.1. Limitations ...... 30 5.2. Future work ...... 30 5.2.1. Additional functionality ...... 30 5.2.2. Platforms and Browsers ...... 31 5.2.3. Caching strategies ...... 31 5.3. Recommendations ...... 31 Bibliography ...... 32 Appendix ...... 36

III

Acknowledgements I would like to thank Inter-Data for providing access to their resources including live projects for testing, and supervisor Dr. Bridget T. Kane for her support and patience during this study.

Abbreviations and Glossary Chromium Open-source web-browser engine by Google, used by Chrome (Chromium n.d.) and Edge (Belfiore 2020) among others.

Cross-platform Meaning software that is available across multiple operating systems and/or devices (Asal 2020). E.g. in PWA’s case being able to run across multiple browsers and across multiple operating systems and devices using the same code.

CSS Cascading Style Sheets – Set of styles that describe how the HTML elements should look (W3schools n.d.-b).

FMS Fleet Management System – A paid service/system provided by Inter-Data Europe b.v. that tracks vehicles using tracking devices. That data is then used through the website to show the current status and location as well as to create reports for tax declaration or similar.

HTML Hyper Text Markup Language – A markup language consisting of a series of elements that tell browsers how to show its contents (W3schools n.d.-a). It is the layout or structure of the website.

HTTP Hypertext Transfer Protocol – Data transfer protocol used for websites.

HTTPS Hypertext Transfer Protocol Secure – Secure version of HTTP using TLS, meaning that the communication between server and client is encrypted.

JavaScript JavaScript is a programming language that defines the behavior of a website. E.g. it JS can alter content and fetch additional information. (W3schools n.d.-c)

JSON JavaScript Object Notation – A lightweight format used for transferring data (W3schools n.d.-d).

Progressive Web App Websites acting like native applications with access to some native functionality PWA including notifications, offline use and limited hardware access. PWA is build using common web standards like HTML, CSS and JavaScript and is intended to work on any platform that uses compatible web-browsers. (Russell 2015)

Regular Web App RWA is the opposite of PWA meaning that it is essentially a normal website that RWA does not incorporate PWA functionality.

Service Worker JavaScript code that sits between the browser and network to handle network requests. Usage includes creating an offline experience, handling requests based on network status, handles caching and can use push notifications and background work. (Mills et al. 2020b)

TLS Transport Layer Security – A security protocol used to encrypt communication. Used for encrypting HTTP connections (HTTPS). (Cloudflare n.d.)

Web App Manifest A JSON file that provides a web app’s metadata including links to icons, start page, the application’s name and more (W3C 2020).

WebKit Open-source web-browser engine by Apple, used by Safari among others (WebKit n.d.).

1. Introduction Progressive Web Apps (PWA) is a fairly new concept coined by Google in 2015. PWA’s are used to give users a native-app experience through the use of web technologies (Russell 2015). In this study key aspects of PWA are investigated including compatibility, performance, security/privacy as well as user/business impact.

PWA is an important topic in web development as it is the future of many web applications and is being pushed hard by big companies. PWA’s offers a new perspective on what the web is and how it might even eliminate the need for many native apps due to PWAs being cross-platform and being more easily installed compared to native apps while still being useful straight from the browser without installing at all (Russell 2015).

1.1. Background This section is about where PWAs come from and how the web evolved into apps. This section is important in order to fully understand what PWAs are and why they are called progressive. How the rise of smartphones changed the web, how some websites pretend to be programs are also discussed. The purpose of the background is to explain the topic of this study including an overview of what makes it work, specifically service workers, manifests and caching.

1.1.1. The Web - History In 1989 a British physicist Tim Berners-Lee invented the web at the European Organization for Nuclear Research (CERN). Its original purpose was to share information between universities and institutes by physicists around the world. Later, in 1993 it was added to the public domain together with the necessary tools to host servers and view websites. (Giampietro 2013)

The first website was the WWW Project Page and went officially live in 1992 (Connolly 2000; Shelley 2019). It shows static information with hyperlinks to switch between pages and servers. At the time there were only about 26 reliable servers which were all linked from the website. Included were some universities and institutions around the world (CERN 1992a).

Websites at the time were simple, containing only very few and basic functionalities of what is being used today. The early definition of HTML included only a few basic tags and functions like titles, headings, anchors (hyperlinks), lists and paragraphs (CERN 1992b). It was not until 1995 that a complete definition of HTML was developed under the name HTML 2.0 (Berners-Lee & Connelly 1995).

Once the web was available, it grew exponentially. The number of websites went from over a hundred in 1993 to just shy of three thousand in a year. The number of hostnames soon breached a hundred thousand in 1996 and continued to a million only a year after that (Gray 1995; Netcraft 2020). Today it is estimated by Netcraft (2020) that there are almost 1.3 billion hostnames containing ca. 190 million active sites. In addition to the growth of the web, the pages themselves grew rapidly in size in a similar manner. In 1995 the average webpage was only 14.1 KB but has now grown to an estimate 1900 KB for desktop (website optimization 2014; http archive 2020).

In conjunction with this growth, the web had to adapt new standards to keep up with demand and both hardware capability improvements and limitations. Newer versions of HTML were released alongside CSS and JavaScript making the web more stylized and functional. The complexity of the web could increase alongside the increased performance of the devices that ran them, until mobile devices came into play.

1.1.2. Web Apps Slowly, websites became more advanced with added features, cloud storage and connectivity. Services like online banking, webmail and others started to appear. These services are run on the server the website is hosted on and simply displays an interface to the user in form of primarily HTML, CSS and JavaScript. By executing on the server and displaying the results on the client’s browser makes these services independent of platform, as long as those platforms have fully featured web browser installed capable of interpreting the results correctly. An added benefit of this is the ability to update the service without any interference with the user as they do not have the application locally stored in the same way as typical programs do, which also means that the user is not able to temper with the application directly. These websites are often referred to as Web Apps as they are applications that run entirely from the web. (Christensson 2014)

The main differences between a web app and a normal locally installed program are important to what the purpose of the application will be. Web apps do not require installation, are platform independent and do not typically require maintaining older versions due to not needing traditional updates to the client. What it cannot do, however, is accessing Operating System level systems like the CPU, memory and hardware accelerated graphic devices. The higher-level nature of web apps, meaning higher from the hardware, generally makes them slower for heavier workloads, especially for graphic intense applications like high-end video games, image/video editors, modeling software among others. Those applications typically have to be installed locally and do not run from a web browser. Another benefit that traditional programs have is that they are more reliable due to browser standards being continuously changed and users using different competing web browsers. (Christensson 2014)

1.1.3. The rise of the smart phones – Responsive design Since the introduction of smartphones, an increasing amount of people have started using them to access the web instead of a computer. According to StatCounter (2020) the amount of desktop computers on the web has steadily declined since 2009 and has since switching position with mobile users in 2013 making mobile phones the dominating device used on the web.

The result of this growth in mobile users is that it sparked the discussion about a mobile-first approach. This approach means prioritizing the mobile experience over the desktop version. In addition, using the mobile-first approach for Search Engine Optimization (SEO) is now preferred as Google since mid-2019 had decided to prioritize the mobile experience when using web-crawlers for indexing (Google 2019a).

The mobile-first approach gives a few challenges. Smartphones are typically connected to the internet using a limited and capped mobile connection, as well having limited hardware performance compared to desktop computers. These limitations lead to having to make compromises and cut down on unnecessary elements, animations and heavy content. Thse compromises are why starting with mobile when developing is preferred as it lets you build

up, instead of strip down. Anything that will work on a phone can be scaled up to a desktop. (Schwarz 2016)

In addition to performance, screen real estate is another important factor as smartphones are limited in that regard. That is where responsive web design (RWD) comes in. RWD became a discipline in ca. 2010 and means that the websites adapt to its surroundings, regardless if it is viewed from a desktop or a mobile device. They respond to the screen size of the device instead of following a set of designs for each common screen size. They can use media- queries to set styling rules for specific screen types or sizes and they can use elements that fully adapt to the size e.g. having pictures taking up a third of the screen’s width instead of using exact pixels. Responsive websites utilize both methods to make them fit on any screen, even future ones. (Marcotte 2010)

1.1.4. Websites disguised as Programs The cross-platform properties of websites are harvested by some companies and developers in the form of web-based programs, or rather programs using web technologies (Russell 2015). These include Electron by GitHub, React Native by Facebook and Chromium Embedded Framework, but there are also others using the same idea, although not all of them are cross-platform in the sense that the framework itself cannot be copied over (Russell 2015).

These platforms or frameworks handle all the background tasks of being installed and delivering API requests while the developers, for the most part, only have to work with standard web technologies like HTML, CSS and JavaScript (Electron n.d.). They have the advantage of being more easily programmable and maintained by developers who are already used to web standards, especially when going cross-platform and still having access to system APIs (Russell 2015). Those platforms can also work offline and be distributed through app stores (Russell 2015). This method of distribution also means that the services on those platforms are not typically usable from the internet as they separate themselves from the web and require the user to download them entirely (Russell 2015).

For reference, programs utilizing Electron includes Discord, Atom, Slack, Visual Studio Code, WordPress’s desktop app and many more (Electron n.d.). Spotify uses Chromium Embedded Framework since 2011 (Pérez 2019).

1.1.5. Progressive Web App – The natural progression Progressive Web Apps (PWA) are essentially a combination between web apps and standalone programs using web technologies. Alex Russell (2015), the senior staff software engineer at Google, described them in his blog post as being/having:

- “Responsive” - “Connectivity independent” - “App-like-interactions” - “Fresh” - “Safe” - “Discoverable” - “Re-engageable” - “Installable” and - “Linkable”

PWAs work like a normal website as they use an URL that can be shared and easily opened and discovered by search engines while also being able to be installed locally by pressing a single button. Using that button, the PWA is added to the user’s home-screen, app drawer or start menu of the user’s device and can then be started from there. The PWAs can then be opened in full-screen, hiding most traces of being a website and can even be used offline if setup in that manner. The PWAs can deliver notifications and use some of the device’s sensors after prompting the user, just like a normal app. (Russell 2015)

“Sites that want to send you notifications or be on your home screen have to earn that right over time as you use them more and more. They progressively become ‘apps’” (Russell 2015)

Progressive Web App (PWA) is not a specific feature or formalized standard, instead it is more like a paradigm, a strategy or collection of browser APIs. The PWA strategy aims at brining app-like experiences to the cross-platform environment of the web. (Mills et al. 2020c)

1.1.6. Service workers An important part of PWA is the service worker which is strongly associated with many of its features (Biørn-Hansen et al. 2017). The service worker is a script that runs in the background by the browser, separated from the web-page itself and allows, among other things, control over network requests and cache (Gaunt 2019). Service workers enabled features such as background sync, push notifications, offline use and others without the need for user interaction (Gaunt 2019).

A service worker gets installed by being registered by JavaScript running on the page, assuming all cache succeed to load and all prerequisites are met, including browser support and a secure connection using HTTPS. At this point there is still no guarantee that the worker is actually running as it might be terminated to save system resources, so the website has to function without its service worker enabled. (Gaunt 2019)

An important detail worth pointing out is that service workers are JavaScript workers (Gaunt 2019) which essentially means it runs as a separate thread and has no direct contact with either the DOM or any other running script on the page, but it can still influence the DOM through the use of postMessage (Bidelman 2010). That the script runs on a separate thread also has the benefit of being able to execute larger calculations and communication work without locking the browser (Mills et al. 2019a).

1.1.7. Caching In a PWA, it is the service worker who decides how to handle network requests including what to pull/store from/to cache and how to handle when the network is not available (Mills et al. 2019a). This cache is saved on the user’s device until the service worker deletes them, alternatively until the browser’s storage limit is met which is usually determined by the device’s free disk space and group storage use (Mills et al. 2019b). It is this cache that allows PWA to work without an active internet connection. It can collect and cache pages and requests while the device is online and then uses that when it loses connection.

1.1.8. Manifest The web app manifest controls app-like settings for the logo, splash-screen color and name, GUI elements like full-screen and address bar, app title, version, description and more (Biørn-Hansen et al. 2017; Medley, et al. 2020). The manifest is loaded in as a JSON formatted .json or .webmanifest file from the head tag in HTML (Medley, et al. 2020).

The main fields required for making a PWA be able to be added to the home-screen are background_color, short_name, start_url which defines where to start when the PWA is started, icons which include multiple sized icons for different places (Mills et al. 2020a), and display which indicates if the installed PWA should be full-screen (fullscreen), have a minimal UI such as only a titlebar (standalone) or with some controls like a back and refresh button (minimal-ui) (Bershanskiy 2020).

1.2. Purpose The purpose of this thesis is divided in two parts, with the first and foremost part being to give an overview of the current state of PWA. As PWA is still relatively new and still developing rapidly, there is therefore also a scarcity in studies that have been conducted on the subject. The purpose is therefore to fill this gap and provide more knowledge of the practical state of PWA.

The other part of the purpose for this study is to create a PWA for a live project by Inter- Data Europe b.v. called FMS (see 1.3.2.1) with the overview of PWA’s state for future development.

Research Question: Current state of PWA This question focuses on helping to make decisions about PWA’s implementation. In order to answer this question, multiple fundamental aspects are investigated and tested.

1. Performance How fast do PWA based websites load compared to normal websites? 2. Compatibility How many browsers, operating systems and devices does it function on and are there any inconsistencies? 3. User and business impact How does the implementation of PWA affect user engagement, experience and revenue? 4. Security and Privacy Are there any security and privacy issues associated with PWA’s functionality?

The answer to this research question is meant to give a sense of the current state of PWA and how it could affect a website.

1.2.1. Target group This study is aimed at web-developers and project decision makers interested in using PWA for either new or pre-existing projects. This thesis acts as a starting point and informative source for decision making regarding PWA and its implementation.

1.3. Method This study is conducting through literature and experimental research. The literature research is used throughout the entire study to gather information on topics like use-cases, security and privacy, past studies on performance and compatibility, and PWA development resources. Tests are also conducted and uses live websites as described in 1.3.2.1 on the devices described in the next section 1.3.1.

1.3.1. Platforms and Browsers Tests are conducted on physical Android 6, Android 8, iOS 12, Windows 10 and MacOS Mojave devices as well as emulated on Android 10 using the AVD manager in Android studio and iOS 12 for iPhones in Xcode’s device simulator.

The browsers focused on in this study are Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari, Opera, Brave, DuckDuckGo and Dolphin Browser on the platforms they are available on in the versions listed in Table 1. Most major browsers have built in tools to evaluate performance and PWA of websites and some have support on mobile as well, typically through a remote connection from a computer.

Table 1. Browser versions used in this study. DDG is short for DuckDuckGo Chrome Firefox Edge Safari Opera Brave DDG Dolphin Android 81 68 45 N/A 58 1.8 5.55 12 iOS 81 25 45 12 N/A 1.17 7.46 9 Windows 81 76 81 N/A 68 1.9 N/A N/A MacOS 81 76 81 12 68 N/A N/A N/A

All tests are conducted on the same network to increase the consistency and reliability of the tests. The speed of the internet connection used on the network has a 100 Mb/s download rate and a 10 Mb/s upload rate. The desktop computers are connected directly to the network using ethernet cables while the mobile devices use 5Ghz Wi-Fi connections at a distance of less than 2 meters from the access point.

1.3.2. Research Question – Current state of PWA The research question is answered using experimental analysis and literature research. The testing is performed using the above-mentioned operating systems and browsers.

1.3.2.1. Websites used & Implementation To investigate the question, a live PWA enabled website is needed to perform the tests on. The website used for this is the Fleet Management System (FMS) from Inter-Data Europe b.v. which is a track-and-trace platform used by other companies and customers to view and export advanced driving logs for tax declarations and internal reporting using GPS and sensor tracking modules.

Before this study, the FMS did not incorporate a PWA solution, so one is created first. To create the PWA implementation of FMS, some requirements has to be collected first. These requirements are kept simple to avoid potentially overcomplicating the PWA and to make 6

sure the results are not only relevant for FMS. Furthermore, as this website is already live, has real users and will continue using the PWA solution from this study as its base, it will give this study a higher purpose and credibility.

The creation and further investigation of the PWA on FMS will help future development, as well as multiple other websites at Inter-Data as the results from this study will eventually also be implemented into the company’s boilerplate, code-named Front-end BASE v2.

As to not become biased to FMS’s solution, Google’s developer’s website developers.google.com will also be used for testing PWA.

1.3.2.2. Current state of PWA The following fundamental parts of PWA are investigated, each with their own method.

Performance The performance is tested using the developer tools build-in to the browser to gather accurate and reliable data. The data collected is the time until the Load event is triggered which occurs when the whole page has loaded, including all the necessary assets such as scrips and stylesheets (Babé et al. 2020). At the same time, data is collected on the amount of data that has been transferred from the network which gives an insight into how much was loaded from the device compared to the internet.

In order to increase the reliability of the data, every test is repeated 10 times and then the average of those samples is used for the final results.

The website tested for this section is FMS using the custom tailored PWA implementation talked about in the results (see 3.1) which focuses on retrieving data from the internet before falling back to using the cache. Then, an implementation that focuses on using the cache first and then falling back to the network is used to see the performance difference between the techniques. This last implementation is talked about in 2.6 and is from the Google’s documentation, though some minor changes are done to keep the two patterns balanced. The changed are further discussed in the implementation in the results 3.1.5.

Compatibility Information about the support and compatibility of PWA for the browsers and platforms outlined in section 1.3.1 are initially investigated using internet resources that specialize in browser compatibility, primarily caniuse.com, as well as going through changelogs and similar where needed.

Then, experimentation is used to test the compatibility using devices outlined in section 1.3.1. To test the service worker, console logs and behavior are checked as well as any relevant settings in the browser’s developer tools. For offline and caching use, tests are done by loading websites with PWA enabled (primarily FMS and developers.google.com), turning off internet access and then seeing if the website still loads the previous visited pages. For manifest functionality a PWA will be installed on the device to check if icons, titles and splash screens are working. Then for testing the installation support a few PWA enabled websites (primarily FMS and developers.google.com) are loaded to see if they offer the ability to be added to the device’s home screen.

User and Business Impact This part of the study is investigated using use-cases from various companies (see 2.4 about the use-cases) and statistics from the web.

Security and privacy Security considerations are brought up using literature and experiments of ideas that come up during the experimentation phase of this study.

1.4. Ethical consideration No personal information is collected during this study and no contact with end-users is conducted. The source code for the various companies and projects are excluded from this paper as they are not relevant, with the exception of the PWA components.

All works studied in for this thesis are acknowledged and referenced to using Harvard KAU and any potential known biases or other influences are given.

1.5. COVID-19 This study is conducted during the COVID-19 pandemic of 2020. My supervisor instructed to avoid physical contact with people and crowded areas for public health reasons, which has limited the possibility of gathering additional information. Access to additional devices to use for testing are also limited by the pandemic.

2. Literature Overview In this section, literature is reviewed and discussed including past studies, case-studies and PWA documentation.

2.1. Native, cross-platform frameworks and PWA In a paper from Majchrzak, Biørn-Hansen, and Grønli (2018), they talk about cross-platform development, how PWA can potentially become the definite approach and about the compatibility and adoption of PWA.

The paper of Majchrzak et al. (2018) describes how native apps that are specifically made for an OS has always had the advantage of improved performance (at least for well-made apps) and a native look and feel but has at the same time suffered from having to be re- developed in different programming languages. The paper goes on about alternative multi- platform solutions in the form of runtime environments and generative meaning they either run on a layer above the OS or get generated into native code respectively with both having the issue of not being able to directly interact entirely with the lower levels of the OS. (Majchrzak et al. 2018)

Compatibility is one of the comparisons drawn in Majchrzal et al. (2018)’s paper. Majchrzal et al. (2018) says that, at the time of publishing, some browsers and platforms do not support PWA yet including Safari and iOS. Majchrzal et al. (2018) claims that it was speculated that Apple was refusing to support PWA to avoid their own app store falling into disuse while big companies move to PWA which would completely avoid Apple’s cut of purchases.

Majchrzak et al. (2018) came to the conclusion that PWA met many of their requirements for being an alternative to the current cross-platform alternatives, but also that it is too early to tell for sure due to spotty adaptation by browsers and websites. This paper was however written in 2018 and PWA has since then been more fully implemented by updated browsers according to caniuse.com (2020a) and outlined in section 3.2.

Furthermore, Majchrzak et al (2018) also mentions there being relatively little research being available on PWA which has proven to still be true to some extent. PWA has since its soft launch in 2015 (Russell 2015) grown rapidly, especially in browser support (caniuse.com 2020a) which explains why research papers are scarce and quickly outdated.

2.2. Security, Privacy and Abuse Considering how PWAs are essentially just websites, one might think the security and privacy might be very similar but this assumption seems to be wrong. Studies done on this topic are scarce and limited but some research into security does exist.

A study by Lee et al. (2018) explores multiple vulnerabilities in security and privacy within the added functionality of PWA. One of those vulnerabilities have to do with how browsers display push-notifications. The authors explain how the poor visibility of the sender in a notification makes them prone to be abused for phishing attacks and that even if that issue were to be fixed, the sender can be spoofed, as little to no authentication checks are performed. This phishing, which means tricking the user into thinking an attacker is a real company, can be done by simply using that company’s name and logo in the notification.

An unobservant user then thinks it is genuine and might give up information that can be used to do harm. (Lee et al. 2018)

Push-notifications in PWA is further studied in another paper by Subramani et al. (2020) in which the authors created a system called PushAdMiner with the aim to determine the amount of push-notifications being abused by ads as well as how many of those ads were malicious. Subramani et al. (2020) ended up analyzing 21541 push-notifications of which 5143 were ads pushed from 572 ad campaigns. Of those 5143 ads the authors determined that 51% were malicious.

Subramani et al. (2020) also found that ad-blocking programs and blacklists were ineffective at stopping malicious use of push-notifications, partially due to the ad-blocking services not being able to gain access to service workers, and that this may be the reason why ad- campaigns specifically target the notification system.

Another issue Lee et al. (2018) found was that service workers could be used to leech of the user’s device for e.g. cryptocurrency mining. The paper explains that this is possible due to service workers automatically being installed when visiting websites and that they have the ability to silently run in the background. Lee et al. (2018) conducted an experiment and managed to gain small fraction of money after 24 hours. A small amount of money could be generated constantly if many thousands of devices would end up being infected by such an attack (Lee et al. 2018). It would also greatly reduce the performance and battery life of the devices in question (Lee et al. 2018).

Lee et al. (2018) also describes a method of retrieving a user’s history by opening a lot of pages inside iframes in the hope that some load while the user’s internet is gone. The paper describes very specific criteria for this to work and essentially requires brute forcing every website imaginable. This would be a slow process that has to be aimed at specific websites to be effective but it is nonetheless a breach of privacy.

2.3. Performance and compatibility A study made in 2019 by Farid Said Tahirshah tests the performance of PWA and regular web apps (RWA) with an additional focus on HTTP versus HTTPS speeds. Tahirshah’s conclusion on his benchmarks were that PWA was generally slower on first load due to not having cached data yet, and faster when running a second time. It is worth noting, however, that most of his results show minimal actual difference with his First Meaningful Paint Benchmark only showing a difference of 50 milliseconds between PWA and RWA on the second load. Tahirshah also does not go thoroughly through which caching strategy he ended up using and only mentioned that he did not optimize it in any capacity, so his results may vary and are therefore harder to replicate.

Tahirshah (2019) did discover a bigger difference when it came to HTTP and HTTPS where HTTPS had a significant performance penalty on speed index with an average of 5 seconds on first load and 361 milliseconds though this seems irrelevant to me considering HTTP is getting slowly pushed out by big companies like Google (Si 2020; Google 2018).

Tahirshah’s (2019) paper also talks about the browser compatibility at the time and its limitations. Tahirshah (2019) shows that full support for web app manifests are relatively limited with only Chrome appearing to support it entirely but also notes that further support for the manifest was being developed for the other browsers. Tahirshah (2019) goes on to 10

TLS support, which is required for PWA. While older versions are being deprecated, TLS 1.2 is essentially fully supported by all browsers with further support for TLS 1.3 on its way. Furthermore, Tahirshah (2019) found that the browser compatibility for service workers and offline modes were relatively well supported. What did lack support, however, was the functionality of being able to install a PWA via a prompt, especially on desktop PCs. But Tahirshah (2019) does mention that some browsers like Safari on iOS used at least some of that functionality when adding a website to the device’s home-screen from a sub-menu to display icons and to launch it in a different way compared to normal website.

Tahirshah’s (2019) research on compatibility is however not particularly thorough as he does not test anything himself and neither does he test for consistency which is something this thesis can contribute with.

2.4. Use Cases This section is about real-life use-cases of PWA by companies with a focus on user interaction and implementations to better illustrate the impact of PWA in practice. The purpose of these use-cases is to answer the user adoption question in the results 3.5.

2.4.1. Trivago Trivago is one of the biggest hotel search engines and has always looked at new technologies to stay ahead. They saw the rise of mobile devices and them taking over desktop browsers and decided to embrace the new users as a potential to grow. Trivago had to focus on the user experience and therefore also the issues that come with phones and mobile data. Trivago wanted connection losses to not affect the user experience and cause a disruption and saw PWA as a potential solution. (Think with Google 2017)

Trivago initially focused on getting their website working offline, setting up notifications and allowing the PWA to be added to the user’s home-screen. These implementations resulted in a huge success for Trivago and so they decided to keep developing it. (Think with Google 2017)

The end result was a 150% increase in repeat visits, a notification system that resulted in a better user re-engagement system compared to their old email only one and a 97% increase in users ending up in external hotel offers. (Think with Google 2017)

2.4.2. Uber Uber is a service that lets its users request a car ride to a given location. For Uber’s PWA, they wanted to provide an app-like experience with focus on weaker devices that might not even qualify for their native app and poor internet connections. (Croll 2017)

Uber ended up with a PWA core the size of about 50KB Gzipped (a compression algorithm) using smart solutions like tiny libraries and minimizing dependencies. This size allows the PWA to be loaded in only three seconds on a typical 2G connection. (Croll 2017)

2.4.3. Rooted Objects Rooted Objects is a marketplace for luxury and streetwear designers and creators to sell products that line up with the website’s design philosophy. Rooted Objects had the problem that their mobile users were getting frustrated and stopping before the checkout due to the lack in performance of their website. The web shop briefly though about making a native

app but realized it would only solve the problem for those using it, not their wider user base. They eventually decided to use PWA through Vue Storefront. (Aureate n.d.)

After implementation, Rooted Objects ended up with roughly 25% faster load times, allowed users to use the website offline, and giving them a native-like experience. This resulted in a 162% higher conversion rate and an overall 44% increase in revenue. (Aureate n.d.)

2.4.4. George.com The UK clothing brand George.com realized that their customer expectation of mobile experiences was at an all-time high while their mobile solution was outdated, and so decided to build a PWA. After implementing PWA incrementally, they ended up with a 3.8 times faster load time, 2 times lower bounce rate, a 31% increase in conversion and users ended up visiting 20% more pages per visit. (Google Developers 2018)

2.4.5. Best Western River North Hotel An urban hotel in Chicago wanted to update their website to attract more guests and hired Brewer Digital Marketing to create a site with PWA. The CEO at Brewer Digital Marketing mentioned customers being impatient and expecting to reach content quickly and the company understood the influence a PWA could have. (Brewer Digital Marketing 2018)

The result was a website that could be used offline, that reengaged customers with push- notifications, was accessible by all devices and loaded quickly. The results ended up in a 300% increase in revenue and 5 times the amount of nights booked when compared to the old website. (Brewer Digital Marketing 2018)

2.4.6. Pinterest Pinterest has a large case-study on their implementation of PWA. They realized that their old and slower website only convinced about 1% of their users to sign-up, login or install their native app. In the course of 3 months Pinterest rebuild their website using React, Redux and Webpack with cache first strategy and managed to reduce their First Meaningful Paint time from 4.2 seconds down to 1.8 seconds and later down to 0.6 seconds on repeat loads thanks to only having a ca. 150KB core. (Osmani 2017)

Pinterest’s new PWA experience resulted in an increase of 40% in time spend over 5 minutes, an increase of 44% in ad revenue and an improvement of 60% in core engagements compared to their old mobile site. The study also includes a comparison with their native app showing a slight improvement in the same time spend, ad revenue and core engagement. (Osmani 2017)

2.5. PWA Life Cycle Before developing the PWA it is good to understand the general life cycle. A paper by Gambhir and Raj (2018) goes through the steps a service worker takes with a focus on caching. The authors explain that a service worker is terminated as soon as it’s no longer in use and gets restarted when it does, which for data persistence is why caching techniques are important.

The cycle begins with the server worker getting downloaded and registered when visiting the website for the first time. It also checks if there are any updates available to the service worker by comparing the local and remote files. (Gambhir & Raj 2018)

When loaded, the service worker triggers at Figure 1. Service worker life cycle by Gambhir, A. & Raj, least three important events, install, activate G. (2018) and fetch (see Figure 1). The install event is triggered when the service worker is installed for the first time. It is the first event that occurs during the life cycle. The install event is used for caching the most important parts of the PWA which can include CSS, JavaScript, HTML, images and whatever else is needed. (Gambhir & Raj 2018)

The second event Gambhir and Raj (2018) mention is activate which is triggered after the installation and is used to update or delete files from the cache. This is also the point in which the service worker is ready to handle fetch requests (Archibald 2019a).

The last event that Gambhir and Raj (2018) talk about is fetch which gets triggered upon every request made by the website. This event can be used to handle how data is requested and where to get that data from.

Gambhir and Raj (2018) also explicitly show how to handle the events. In summary they use the following lines of code with the ‘event’ part replaced by the actual handled event.

self.addEventListener('event', event => { // ... });

2.6. Developing PWA This section is about the introduction documentation available for setting up a basic PWA that can later be used as a base to start from. This basic setup includes a service worker and web app manifest. For this section, primarily Mozilla and Google’s documentations are used. Some code examples are provided but are also explained in overview.

2.6.1. Service Worker Register Gaunt (2019) on Google’s Web Fundamentals show how the service worker can be registered from a website’s main JavaScript file. First, Gaunt (2019) checks if the browser supports service workers before registering it. Then it simply gives a message telling the developer if it succeeded or not.

if ('serviceWorker' in navigator) { window.addEventListener('load', function() { navigator.serviceWorker.register('/sw.js').then(function(registration) { // Registration was successful console.log('ServiceWorker registration successful with scope: ', registration.scope); }, function(err) { // registration failed :( console.log('ServiceWorker registration failed: ', err); }); }); } (Gaunt 2019)

Install Gaunt (2019) goes on to show an example of how to initiate a service worker and include a couple of static caches. First of all, the code makes sure with installing the service worker until all the caches using waitUntil. Then, the code opens the cache storage which enables saving data. Multiple cache storage objects can be used so a name is also given to specify which one to use. After opening the cache storage Gaunt (2019) adds all the previously provided URLs to the cache.

var CACHE_NAME = 'my-site-cache-v1'; var urlsToCache = [ '/', '/styles/main.css', '/script/main.js' ];

self.addEventListener('install', function(event) { // Perform install steps event.waitUntil( caches.open(CACHE_NAME) .then(function(cache) { console.log('Opened cache'); return cache.addAll(urlsToCache); }) ); }); (Gaunt 2019)

Managing Cache After the installation is done Gaunt (2019) goes on to basic cache management using the fetch event mentioned in 2.5. Gaunt (2019) provides example code that acts as a cache-first approach as it first checks if a cached response is available before falling back to loading it from the network.

self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // Cache hit - return response if (response) { return response; } return fetch(event.request); } ) ); }); (Gaunt 2019)

Afterwards, Gaunt (2019) expands his example somewhat by adding a way to cache every single request (see Figure 2). After checking if a cached version is available and failing, the example continues to load the request from the network and clone it into the cache storage, assuming the response was not incorrect. In short what the following somewhat shortened code from Gaunt (2019) does is that it tries the cache first, and if that fails it loads it from the network and makes a new cache out of it.

self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // Cache hit - return response if (response) { return response; }

return fetch(event.request).then( function(response) { // Check if we received a valid response if(!response || response.status !== 200 || response.type !== 'basic') { return response; }

caches.open(CACHE_NAME) .then(function(cache) { cache.put(event.request, response.clone()); });

return response; } ); }) ); }); (Gaunt 2019)

Figure 2. Overview of Gaunt’s (2019) service worker handling a fetch request

2.6.2. Web App Manifest The manifest is written in JSON and contains meta data required to make the PWA look like an app when installed (Medley et al. 2020). Medley et al. (2020) lists all the keys it can use:

- background_color - categories - description - dir - display - iarc_rating_id - icons - lang - name - orientation - prefer_related_applications - related_applications - scope - screenshots - serviceworker - short_name - start_url - theme_color

For a PWA to be able to be installed on at least Chrome, the following attributes are required: name or short_name, icons including a 192x192 and 512x512 pixels icon, and a start_url to tell the PWA what page to start on launch. (LePage & Beaufort 2020)

To then add this manifest to the site a HTML element has to be added to its HEAD (LePage & Beaufort 2020).

(LePage & Beaufort 2020)

3. Results This chapter is about the results and findings of the tests and research.

3.1. Implementation The initial implementation was done before the discovery that iOS requires additional HTML HEAD elements to make use of certain features including splash-screens and icons (see 0). The implementation is based on the literature review made on the topic in chapter 2.

3.1.1. Requirements The requirements were kept simple as discussed in the method (see 1.3.2.1). Conclusions were made by considering the nature of FMS.

- FMS is a website that is locked behind a login system therefore security considerations are required. - FMS handles live data and users want to stay updated, therefore a network-first approach is required. - The portal has a big map on multiple pages, including on the landing page after being logged in. It uses a map viewer called OpenLayers that loads in tiles from various potential servers so the service worker should make sure to not cache every single tile and flood the cache which would fill the user’s device storage.

3.1.2. Setup The setup used is essentially the same as it was in the literature overview (2.6), which means that the manifest is being loaded in using a HTML HEAD element and the service worker is being loaded in through the FMS’s main JavaScript file.

One difference is that the service worker does not install on first visit to the login page as to postpone the add to home-screen prompt and to not cache the login page which would be pointless when the server cannot be reached for authentication.

HTML HEAD element:

Main JavaScript file: if ('serviceWorker' in navigator) { // Try to register the worker register navigator.serviceWorker.register('service-worker.js') .then(function(reg){ // Success! }).catch(function(err) { // Failed! console.log("Service worker did not register. ", err); }); }

3.1.3. Manifest The manifest contains all the required values including name, short_name and three icons at 144x144, 192x192 and 512x512 pixels in addition to theme_color, background_color and a standalone as display to explicitly hide the address bar. It is set to use the dashboard specifically as start_url as that is the default page and also redirects back to the login page, just like any other page on the website does.

{ "name": "Fleet Managment System", "short_name": "FMS", "icons": [ { "src":"img/fms_logo/FMS_square_placeholder_144px.png", "sizes": "144x144", "type": "image/png" }, { "src":"img/fms_logo/FMS_square_placeholder_192px.png", "sizes": "192x192", "type": "image/png" }, { "src":"img/fms_logo/FMS_square_placeholder_512px.png", "sizes": "512x512", "type": "image/png" } ], "start_url": "/?mode=dashboard", "display": "standalone", "background_color": "#fff", "theme_color": "#105F80" }

3.1.4. Service Worker The service worker starts by caching some basic and static assets that are required to stay operational after being disconnected. Among the cached files are the main JavaScript and CSS files, an offline page to show when a connection fails and the required files for the map library called OpenLayers. The size of the OpenLayers script and styling alone are already 627KB and essentially never update, making them perfect to cache. The landing page of the website is also added to the cache on installation but is not in the list of static assets which is done to make sure there is always something to show but also allow it to be updated later on.

Figure 3. Overview of the FMS service worker’s process when intercepting a fetch request

When the browser tries to load anything, the service worker intercepts the request and starts with checking if it is part of the static list which if true, means that the service worker will load it immediately from the cache and will fall back to the network if needed, which can be called a cache-first pattern. If the request is not a part of the static assets, the service worker will instead use a network-first pattern in which it attempts to load the request from the internet before falling back to using the cache. (see Figure 3) 18

In order to use the earlier discussed offline page, the service worker detects if the failed fetch request was a navigation request trying to load a new page, and will then load in the offline page from the cache instead. This offline page shows the user that the website has lost its connection with the server and that the user should check their connection. The offline page will keep trying to reconnect until it does or until the user clicks on the back button which will attempt to load the last visited page again from cache.

In order to handle the map, a filter goes through all the requests and makes sure that all the requests to map servers goes directly through the network and not through the cache. However, in an attempt to make the website still show some information on the map during a network outage, the second zoom level of the map is still cached. This zoom level is almost completely zoomed out and has a low number of tiles to load in.

The service worker only has a few recognizable parts from the literature review, which was based on the documentation of Google, but most of the code is custom tailored to FMS’s needs.

let cacheName = 'FMS-cache'; let staticlist = [ '/?mode=offline', '/style/base/style.php?mode=offline&bread=', '/lib/openlayers_5.1.3/ol.js', '/lib/openlayers_5.1.3/ol.css', '/js/base.js', '/js/dashboard.js', '/style/base/style.php?mode=dashboard&bread=' ];

self.addEventListener('install', function(event) { // Add static cache event.waitUntil(caches.open(cacheName).then(function(cache) { return cache.addAll(staticlist.concat(['/?mode=dashboard'])); })); });

self.addEventListener('fetch', function(event) { // -- Get static cache if (staticlist.find(function(s) {return event.request.url.endsWith(s)})) { event.respondWith(caches.match(event.request) .then(function(response) { if(debug)console.log("Getting static cache", event.request.method, event.request.url); if (response) return response; if(debug)console.log("Error, static cache failed", event.request.method, event.request.url); return fetch(event.request); // Fallback, just in case })); } else { // -- Get Dynamic cache event.respondWith(caches.open(cacheName).then(function(cache) { // Don't cache OSM unless zoom level 2 if ((!event.request.url.includes("osm.track2data.com") && !event.request.url.includes("openstreetmap.org") && !event.request.url.includes("mt1.google.com")) || event.request.url.includes("osm.track2data.com/hot/2") || event.request.url.includes("openstreetmap.org/2")) { return fetch(event.request).then(function(response) { if(debug)console.log("Success, getting live", event.request.method, event.request.url); cache.put(event.request, response.clone()); return response; }) .catch(function(e) { if(debug)console.log("Error, trying from cache", event.request.method, event.request.url); return cache.match(event.request) .then(function(result) { // -- Page navigation. Show offline page on fail // request.mode = navigate isn't supported in all browsers // so include a check for Accept: text/html header. if (!result && (event.request.mode === 'navigate' || (event.request.method === 'GET' && event.request.headers.get('accept').includes('text/html')))) { console.log("Navigation failed, getting offline page"); 19

return caches.match("/?mode=offline"); } // Either return cached data or an error, we can't do more than this return result; }); }); } else { if(debug)console.log("OSM, ignoring cache", event.request.method, event.request.url); return fetch(event.request); } })); } });

3.1.5. Cache-first implementation The second type of implementation is used to compare the performance between the custom tailored, but mostly network-first, pattern and a simplified cache-first pattern from Google’s documentation as discussed in 2.6. The cache-first pattern is however slightly altered to fit FMS and to keep it balanced with the custom pattern. The instalation method (3.1.2), static cache list and install event (3.1.4) remain the same as the custom pattern. In addition, the filter that forces requests that are send to the map-servers to ignore the cache system from the custom pattern is re-implmented to avoid flooding the cache with map tiles as discussed in the requirements 3.1.1. See Figure 4 for an overview of this implementation with focus on request handling.

Figure 4. Service worker process from Google’s documentation but with an added map-server filter

3.2. Compatibility Compatibility of the key features of PWA are relatively well supported as this section describes in detail.

3.2.1. Service Worker According to Can I use (2020a) most used and updated web browsers have generally good support for the Service Workers (see Figure 5). However, this does not mean every browser and platform supports an equal number of features.

Figure 5: Can I use (2020a) chart showing Service Worker support. The numbers are versions, green is supported, olive partially supported and red unsupported

On iOS, only the Safari browser appeared to make use of the Service Worker when testing all the browsers mentioned in the methodology chapter. This is further confirmed by Fablet (2018) who essentially says that the Service Worker API is only available for Safari as Apple restricts third-party web-engines on iOS (Apple 2020).

WebKit, primarily used by Safari (WebKit n.d.), has in general deviated somewhat from standards being pushed by Chromium according to Firtman (2020). WebKit has support for some Apple specific functionality like Apple Pay and sign-in-with-Apple but has yet to implement support for push notifications, background work, hardware access and more (Firtman 2020).

Safari on MacOS supports the service workers as of version 11.1 according to Apple (2018). Tests of the service worker on the browser confirm support.

A test using FMS and developers.google.com shows that Edge for Android registers the service worker as the browser caches pages and offers the user to install the PWA. As Edge shares the same web engine as Chrome called Chromium (Nath 2019) the assumption was made that the rest of Edge’s behavior and functionality is similar to that of Chrome.

Table 2. Service worker support overview. DDG is short for DuckDuckGo Chrome Firefox Edge Safari Opera Brave DDG Dolphin Android Yes Yes Yes N/A Yes Yes Yes Yes iOS No No No Yes N/A No No No Windows Yes Yes Yes N/A Yes Yes N/A N/A MacOS Yes Yes Yes Yes Yes N/A N/A N/A

3.2.2. Web App Manifest The manifest on the other hand has much less consistent support among browsers compared to the Service Worker with desktop browsers only supporting it on Edge and Chrome according to Can I use (2020b) (see Figure 6).

Figure 6: Can I use (2020b) chart showing Web App Manifest support

Investigation shows Firefox and Safari both lacking support on desktop, which makes sense as they also lack support for adding the PWA to the device’s home-screen (see 3.2.3). Tests conclude that Firefox on iOS does not support the manifest either for the same reason, but it does work on Android. Safari on iOS however does work but behaves differently compared to the rest.

On desktop, the rest of the tested browsers, Chrome and Edge, showed no usage of a splash screen but did use the other manifest settings including icons and titles for the start- menu/launchpad, and theme color for the title bars. The display setting is however limited to standalone and minimal-ui as fullscreen is ignored and browser gives an error message in the developer-tools saying it is not allowed as a value which also causes the PWA to no longer be installable. It is also noteworthy that Edge showed a back button on both standalone and minimal-ui while Chrome only showed it in minimal-ui. iOS browsers only use WebKit and cannot be added to the home-screen, as mentioned in 3.2.1, meaning that the web app manifest cannot does not have to be tested. Safari on iOS, on the other hand, does support some of the manifest’s features as tested. For some of the other features, workarounds are available. With only the manifest and nothing else, it shows a preview of the website as its icon and no splash-screen on startup. To add some of the missing functionality, several additional HTML elements had to be added to the website’s HEAD.

To get the icon to work, the HTML head element apple-touch-icon has to be given, and the splash-screen requires apple-touch-startup-image for the screen sizes provided by the iOS’s Human Interface Guidelines (Apple n.d.). There are more missing functionality including the use of theme colors and only some of them can be fixed using alternative methods.

On Android the manifest is supported by all the browsers mentioned in the methodology with only minor inconsistencies as tested. The inconsistencies found for the browsers were that Firefox does not show a splash-screen and that Edge does not use the theme color to color the notification bar. Further inconsistencies include that DuckDuckGo does not show the app icon, that Brave, Firefox and Dolphin do not show splash-screens, that Opera does show the splash-screen but not the splash-screen icon, that Dolphin does not hide the address bar, and that DuckDuckGo and Dolphin do not use the app name.

Tests show that the manifest is supported the most by Chrome on all platforms and worked with all functionality implemented in the FMS manifest (see methodology chapter) as well as in developers.google.com.

Table 3. General overview of browsers supporting the web app manifest. DDG is short for DuckDuckGo Chrome Firefox Edge Safari Opera Brave DDG Dolphin Android Yes Yes Yes N/A Yes Yes Yes Yes iOS No No No No N/A No No No Windows Yes No Yes N/A No Yes N/A N/A MacOS Yes No Yes No No N/A N/A N/A

3.2.3. Add to home screen capability Observations show that the number of browsers with support for being installed depends partially on the platform, with Android and Chromium based browsers being the most consistent.

Table 4. Browsers supporting add to home-screen functionality and how it’s activated. DDG is short for DuckDuckGo Chrome Firefox Edge Safari Opera Brave DDG Dolphin Android Prompt Button Prompt N/A Prompt Menu Menu Menu iOS No No No Menu N/A No No No Windows Button No Button N/A No Button N/A N/A MacOS Button No Button No No N/A N/A N/A

Android On Android all browsers mentioned in the methodology support being added to the home- screen with only minor inconsistencies of which most are covered in the 0 section about manifest support. An additional inconsistency is that only Chrome seems to put its PWAs in the app drawer itself while the rest of the browsers only put the PWA on the home screen menu. It is also only Chrome that shows an installing notification after pressing the add to home-screen button and later allows it to be uninstalled instead of just removed like a shortcut like the other browsers do. PWAs added from Chrome even appear in the installed apps list on the device’s settings making them much more like an app compared to the rest.

Firefox seems to be able to tell the difference as it shows an additional icon next to the add to home-screen button (see Figure 7) when Chrome has already installed the PWA. This button, which has an Android logo as it’s icon, simply opens the previously installed PWA while still allowing the add to home-screen button to add new Figure 7. Firefox when the FMS PWA is shortcuts to the home-screen. already installed by Chrome Edge also seems to sense the presence of a Chrome installed PWA as it stops prompting the user to add it to their home-screen after the PWA is installed through the Chrome browser.

On Android, when it comes to notifying the user that the PWA can be installed, Chrome, Opera and Edge show a dialog upon visiting the website asking the user if they want the PWA to be added to their home-screen (see Figure 8). Firefox, Brave, Dolphin and DuckDuckGo on the other hand leave it up to the user to find how to do it with the most common location being in the browser’s menu, often labeled as add to home-screen or similar with the exception of Firefox who instead uses an icon on the address bar.

Figure 8. Add to home-screen button on various Android browsers 23

iOS As every browser on iOS is forced to run the same web engine and view as Safari, as mentioned in 3.2.1, the browsers supporting add to home-screen functionality is limited. Only Safari gives the option to add a PWA and is located in the less obvious location under the share menu (see Figure 9). Figure 9. Add to home-screen on iOS Safari A small observation was also made about the data retention when the FMS PWA is added to the home-screen on iOS, the user gets logged-out upon opening it. This happening indicates that the PWA is a separate identity from Safari, which is not the case on Android, MacOS and Windows where the PWA retains the browser’s data and even allows seamless switching between browser and PWA.

Windows The investigation on Windows showed that the only browsers from the methodology browser list that allows the PWA to be added to the start menu are Chrome, Edge and Brave which all happen to be Chromium based browsers (Chromium n.d.; Belfjore 2020; Cimpanu 2018). All 3 browsers have a very similar installation process which includes pressing a small button with a plus in a circle as it’s icon on the right of the address bar that opens up a prompt asking the user if they want to install it or not (see Figure 10).

Figure 10. Add to home-screen button on various Windows browsers

MacOS On MacOS, only Chrome and Edge allow users to add PWAs to the launchpad. The PWAs get added to the programs/chrome-apps and programs/edge-apps folders respectively. The process of installing on Chrome and Edge is the same as for Windows. Simply click on the button with a plus inside a circle and a prompt shows up asking the user to install it (see Chrome and Edge on Figure 10).

3.2.4. Offline usage The experimentation shows that all the tested browsers on Android, Windows and MacOS support offline use through the service worker, and the browsers even show the offline page when visiting pages that were not loaded previously before disconnecting the devices from the internet. On iOS however, only Safari showed this capability with the other browsers falling back to showing an error message saying that they could not load the page due to the lack of an internet connection.

Table 5. Browsers supporting offline usage. DDG is short for DuckDuckGo Chrome Firefox Edge Safari Opera Brave DDG Dolphin Android Yes Yes Yes N/A Yes Yes Yes Yes iOS No No No Yes N/A No No No Windows Yes Yes Yes N/A Yes Yes N/A N/A MacOS Yes Yes Yes Yes Yes N/A N/A N/A

3.3. Performance Figure 11 shows the time it takes to load FMS either without PWA (RWA), with the custom pattern (PWA, 3.1) and with a cache-first pattern (PWA-C 3.1.5), as well as the data transferred. The first blue bar in each group represent the time or data transferred for the first time loading the website, and the second orange bar shows them for the second load after the PWA and build-in browser caching has started having an effect.

The results were gathered using 10 samples of each method as described in the method section.

Load time in ms (lower is better) Data Transfered in KB (lower is better)

1200 ms 3000 KB

1000 ms 2500 KB

800 ms 2000 KB

600 ms 1500 KB

400 ms 1000 KB

200 ms 500 KB

0 ms 0 KB RWA PWA PWA-C RWA PWA PWA-C First Load 991 ms 973 ms 980 ms First Load 2124 KB 2502 KB 2503 KB Second Load 697 ms 669 ms 177 ms Second Load 371 KB 259 KB 27 KB

Figure 11. Load time and data transferred in FMS on Chrome, Windows 10

During the tests it was also noted that Chrome itself heavily cached assets itself and often even from the system memory instead of from the storage device which is typically much faster. However, the difference between Chrome’s own cache and the service worker is that the service worker knows which assets do not need to be checked for updates while the browser has to make educated guesses which explains the difference in transferred data between the regular web app (RWA) and the PWA, but especially noticeable when compared to the cache-first pattern (PWA-C).

3.4. Security and Privacy The following security flaws were found.

3.4.1. Push-notification abuse In the literature review 2.2, a few major security flaws were found in PWA. One of them being the push-notifications being vulnerable to spoofing and can therefore be used to trick 25

the user for malicious advertisements and phishing attacks (Lee et al. 2018). Subramani et al. 2020) found that roughly a quarter of all push-notifications were used for advertising of which almost half was malicious.

3.4.2. Cryptocurrency mining A security flaw was found by Lee et al. (2018) as described in 2.2 which was about service workers being used for cryptocurrency mining in the background without the user’s knowledge and permission.

3.4.3. Authenticated pages being cached after session expiration or logout One security flaw with the implementation described in 3.1 is that logged in pages are cached and are not disposed of after the user logs-out or the session expires. The service worker can self-eliminate its cache but only when the user uses the logout button. If the session expires while the website is not in active use, then the service worker is not activated either which means its cache will stay dormant and accessible from the browser’s developer tools.

To combat the cache of logged-in pages, one could potentially use a Periodic Background Sync to schedule an interval in which the service worker would wake up (Bar 2020) and check the user’s expiration time or manipulate the cache’s headers to include an expiration time (Verney 2020). Both solutions have problems, one being that the Periodic Background Sync is not meant for this and is fairly new and unsupported (Bar 2020) and trying to control headers of cache is cumbersome to update. Further investigation is required to mend this issue but that is out of the scope of this study.

3.5. User and Business impact As seen in the use-cases in the literature review 2.4, most cases reported have a considerable increase in user engagement and in revenue. The case-studies also all report implementing PWA for the reason of satisfying impatient users and to allow engagement on unstable internet connections.

4. Analysis and Discussion The Progressive Web App paradigm is a constant evolving concept that includes an ever- changing number of browser APIs and functionalities, and it is therefore no surprise that browser compatibility and feature consistency is not the same across all platforms as shown in the results in chapter 3.

4.1. Compatibility Analysis In the chapter 3.2, multiple key elements of PWA are investigated for compatibility and the results vary significantly depending on the feature. Based on the results of the tested elements of PWA, being the service worker, manifest, offline functionality and add to home- screen ability, it is relatively safe to say that PWA will work for most users especially for those using Android, Windows or MacOS. Users using any other browser besides Safari on iOS might however run into problems when it comes to support.

The browser supporting most of PWA’s tested functionality is Chrome on all operating systems with the exception of iOS. The most likely reason for Chromes support is because Google has been pushing PWA ever since they coined the term in 2015 by Alex Russel as described in the background chapter (1.1.5).

Some of the other browsers that support most if not all of PWA functionality are the ones based on Chromium, namely Chrome, Edge and Brave. These browsers essentially receive most of its PWA functionality by simply being based upon Chromium, which is also why those browsers look visually similar, especially when it comes to PWA functionality like the add to home-screen icon and menu in the address bar (see Figure 10 on page 24). iOS has the least amount of support, which is explained by Apple not allowing third-party browsers to implement their own web-engines as discovered in 3.2.1. Instead, those third- party browsers have to use the same web technology as Safari and are therefore limited by the amount of functionality that Apple is willing to give them.

4.2. Performance Analysis The performance testing on FMS using the custom-but-mostly-network-first pattern results in a very low difference compared to not using a PWA at all. As outlined in the results 3.3, this minimal difference in performance is due to the browser being particularly effective at caching by itself. However, the browser can only make educated guesses towards what needs to be updated, resulting in a slight difference in data transfer and load time of 112KB and 28ms respectively (see Figure 11 on page 25).

Another reason that the custom service worker does not offer any significant differences compared to not using a service worker at all, is that the service worker does not provide particularly many static assets to load and reuse directly from the cache. Most of the requests sent are retrieved using a network-first strategy which makes the PWA similar to the RWA in terms of how many assets are loaded directly from the network. The browser does however still cache on its own just like the RWA which is why they both have similar second load times.

There is a consistent difference between the data transfers of RWA and both PWA solutions on first load of about 378KB (see Figure 11 on page 25). This difference occurs since both 27

PWA solutions load in additional static assets on first load to install the PWA on the user’s device as described in 3.1.4. The increase of data on the first visit will theoretically be earned back after the fourth visit and will save data from there on out thanks to the second and assumingly all consecutive data transfers being on average 112KB lower

The initial data transfer difference would have been more significant if the landing page would not have included an interactive map, as the map scrip and styling files resided in the static cache, are already 627KB on their own as mentioned in 3.1.4. The reason why having a map would then make a difference could then be explained by the map script being loaded in regardless through the service worker’s static cache while the non PWA would then only have to load assets that were actually being used on the loaded page.

While the custom PWA result in terms of performance may not look like a huge success, one has to remember that one of the requirements mentioned in 3.1.1 is that most of the website’s content has to be updated frequently which entails having to use the network-first caching pattern for most of the website’s resources. In 4.4 an analysis of how the PWA for FMS is made and a potential solution for increasing the performance are discussed further.

4.3. Security and Privacy Analysis In section 3.4, some security concerns are brought up. Most of the concerns based on the literature review in 2.2 are about the potential abuse of certain functionality, namely background workers and push-notifications being open to cryptocurrency mining and phishing or scam attacks respectively. Some of those flaws could be mitigated by the browser developers by limiting the amount of background work service workers are allowed to perform and by more clearly showing the true origin of the push-notifications.

One of the biggest implications for FMS, based on the results, is that logged in pages are being cached but not deleted making it fairly easy to read potentially sensitive information by utilizing the developer tools or by accident when browsing offline. This problem could especially be troublesome when considering public or shared computers.

One solution to the caching issue could be to simply delete the cache when the user logs out but that has some problems on its own as discussed in section 3.4, which was that the service worker might not be active at the time the user’s session expires and would be accessible from the developer tools. Further work has to be conducted to investigate more appropriate solutions to this issue, but that is out of the scope of this study.

4.4. FMS Analysis Considering the performance difference for the custom PWA being minimal while the simpler cache-first pattern being significantly better, as discussed in 4.2, an improvement to the PWA could potentially be made by incorporating the cache-first strategy in more parts of the PWA. The simplest improvements could be adding more files to static cache on the basis that static cache that is being loaded cache-first is significantly faster as shown in the results section 3.3. Bigger improvements might however require rebuilding the structure of the website to allow for more static assets. For example, excluding any actual content from the site and then loading it in afterwards would allow the page itself to be entirely loaded cache-first while the actual content is loaded in with network-first afterwards. This concept is often called the app shell model (Osmani 2019) and is out of the scope of this study, but could be expected to significantly improve performance. 28

The app shell model is also mentioned or hinted at by some of the use-cases reviewed in section 2.4. These use-cases, however, often revolve around building their mobile solutions from the ground up which allows for better integration of a PWA. For the case of FMS, the PWA is being implemented after the fact which limits the potential full incorporation of all of the possible techniques that can be used with PWA. However, improvements are still possible with the concept of the app shell model, especially when it comes to the landing page which, if made static as in the example above about loading in the content afterwards, could significantly improve startup times on revisits and PWA launches.

4.5. User and Business impact The case-studies describe in literature review 2.4 and summarized in the results section 3.5 are all on the positive side of PWA. The information gathered from those case-studies should be taken with a grain of salt however, as they are all positive and do not have anything negative to say about it, which makes sense as most companies probably do not want to disclose failed projects and thrown away funds to their stake holders. Regardless, the companies found were mostly big companies with many of active users and their results are significant and should therefore be taken seriously. Those companies do, however, have presumably massive budgets and development teams and often even redesign their entire website in the process as some of the case-study companies did in section 2.4. The rebuilding or redesigning of their websites might also have increased sales and user reengagements and might therefore not be solely based on the fact that they implemented a PWA, though this is hard to prove.

Pinterest and Uber are found to be the most helpful case-studies, as their studies are much more thorough compared to the rest, with explanations of how the two companies went about implementing their solutions and detailed information about their results.

It is clear to see that PWA has a general positive impact on both user experiences, with lower data transfers, load times and functionality like offline usage, as well as on the business side of the equation with higher user reengagement and therefore also higher ad-revenue and purchases.

4.6. Summary Progressive Web Apps are clearly here to stay and will keep on being developed and being pushed as long as user experience keeps improving and revenue keeps increasing. It is however also clear to see that PWA is still on the rise as not every feature is compatible with every browser on every operating system, though this should not matter as the websites do not break when a browser does not support the PWA if implemented as intended.

5. Conclusion and Recommendations Since the development of the web started, big fundamental changes have changed how the web work and is perceived. It all started with having completely static websites that only showed pure information which then very slowly progressed into interactive web apps in which users could do things normally only possible through locally installed programs. Progressive Web Apps are the next stage of this change, making the web more versatile and universal as well as more accessible even on poor internet connections.

In this thesis we discover that PWA is not going away and that it is still being heavily developed upon. It is discovered that despite PWA’s ever changing nature, it is revealed that it is still something most browsers seek to support. The gains from using PWA are plentiful in terms of user experience, including load times, data savings and app-like behaviors, as well as an overall revenue increase. Security and privacy are on the other hand topics that have to be dealt with, at least to some extent. Though by thinking thoroughly about what the PWA implementation does, most issues can be avoided.

5.1. Limitations Due to the current pandemic mentioned in 1.5, certain parts of the original plan for this thesis was scrapped due to not having the ability to make use of University resources and opinions of people using the user test labs. It was originally planned to also investigate ease-of- implementation through opinion gathering.

Furthermore, there were plans to investigate websites and analyze their specific implementations to compile a list of caching strategies that are commonly used for specific types of websites, e.g. web shops that might want to focus on attracting reengaging users and security, and documentation websites that might want to focus on offline availability instead. The investigation was unfortunately scrapped due to time constraints and many companies obfuscating and minifying their source code, making them largely unreadable.

5.2. Future work This thesis goes over some of the more fundamental parts of PWA, but additional aspects can be found but are in the scope of this project. The following are some of the aspects that might be further studied upon to give PWA a more thorough overview and also to improve on implementation and security.

5.2.1. Additional functionality In addition to looking at the compatibility and consistency of the manifest, fetch handling offline capability and add to home-screen functionality, security and user and business impact, more studies could be performed on other aspects and API libraries. Libraries may include e.g. the Background Sync API which lets PWAs send data after the device is back online (Archibald 2019b), Notifications API which allows a server to send notifications at a system level outside of the website (Patonnier 2020), Web Storage API that allows storing key/value pairs in the browser (Mills 2020d) and more.

Other aspects to further study on may include the perception of users, how many are using the add to home-screen function, how many people understand exactly what they are giving a website permission to do when they click on allow when prompted, cache storage quotas/reliability/abuse/etc., background sync reliability, WebAPKs, additional hardware 30

sensor access like the camera and many more. As mentioned earlier, this thesis only covers the fundamentals, but there is a lot more to PWA worth studying. In addition, considering how quickly PWA functionality and combability changes, any older studies done on PWA has the risk of quickly becoming outdated.

5.2.2. Platforms and Browsers As written in the methodology section 1.3.1, this thesis covers the browsers Chrome, Firefox, Edge, Safari, Opera, Brave DuckDuckGo and Dolphin on the operating systems Android, iOS, Windows and MacOS. Additional browsers and operating systems could be studied upon in the future, especially on various Linux distributions like Ubuntu, Mint Mate and Peppermint. Additional browsers may e.g. include Samsung Internet and Opera Mini, among others.

5.2.3. Caching strategies Caching strategies were, as mentioned in 5.1, originally planned to be more deeply investigated in this thesis but was eventually scrapped. In future studies, taking this investigation up again for a deeper dive into the different types of strategies or patterns can be worth doing. Studying the patterns can give an overview of which style would be beneficial for certain categories of websites and what is commonly used throughout the industry. Having this overview might give a business a starting point and direction in what sort of PWA implementation they might want to use for their website as well as what features to focus their development resources on.

It can also be worth further investigating the implementation of application shells as mentioned in 4.4, as they seem to be often used in conjunction with PWAs as discovered during the literature overview.

5.3. Recommendations Progressive Web Apps are now at a point in which they are supported by most major web browsers on most major platforms with only iOS having some special needs. Most of the fundamental functionality works fine and is ready to be implemented into any website that wants to increase its user experience. The paradigm is mature enough that there is no longer a need to wait for the systems to be widely accepted and for individual fundamental functionalities to be standardized.

Security has to be kept in mind, though for most common websites, especially those that are near static, security will not be much of an issue. Just remember to consider what is being cached by the service worker and if there is any sensitive information that needs to be handled with care and privacy.

Apple’s restriction on third-party web-engines on iOS, which leads to limited PWA support, is something developers should be aware of as they develop their PWAs, but is not something that should discourage them as the rewards and user impact are significant regardless, as summarized in 3.5.

Bibliography

Apple (2018). Safari 11.1. https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.ht ml [2020-05-30]

Apple (2020). App Store Review Guidelines. https://developer.apple.com/app-store/review/guidelines/ [2020- 05-20]

Apple (n.d.). Configuring Web Applications. https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ ConfiguringWebApplications/ConfiguringWebApplications.html [2020-05-20]

Archibald, J. (2019a). The Service Worker Lifecycle. https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle [2020-05-30]

Archibald, J. (2019b). Introducing Background Sync. https://developers.google.com/web/updates/2015/12/background-sync [2020-06-10]

Asal, H. (2019). What is Cross-Platform Software? https://medium.com/@hakanasal51/what-is-cross- platform-software-38ee57b7304a [2020-06-01]

Aureate (n.d.). Rooted Objects, Magento 2 PWA. https://aureatelabs.com/case-studies/rooted-objects- magento-2-pwa/ [2020-06-01]

Babé, L.R. and contributors (2020). Window: load event. https://developer.mozilla.org/en- US/docs/Web/API/Window/load_event [2020-05-30]

Bar, A. (2020). Task Scheduling. https://whatwebcando.today/scheduler.html [2020-06-01]

Belfiore, J. (2020). New year, new browser – The new Microsoft Edge is out of preview and now available for download. https://blogs.windows.com/windowsexperience/2020/01/15/new-year-new-browser-the-new- microsoft-edge-is-out-of-preview-and-now-available-for-download/ [2020-05-20]

Berners-Lee, T. & Connelly, D. (1995). Hypertext Markup Language – 2.0. https://tools.ietf.org/html/rfc1866 [2020-03-01]

Bershanskiy, A. and contributors (2020). display. https://developer.mozilla.org/en- US/docs/Web/Manifest/display [2020-05-20]

Bidelman, E. (2010). The Basics of Web Workers. https://www.html5rocks.com/en/tutorials/workers/basics/ [2020-04-20]

Biørn-Hansen, A., Majchrzak, T.A. and Grønli, T.M. (2017). Progressive Web Apps: The Possible Web- native Unifier for Mobile Development. In WEBIST (pp. 344-351).

Brewer Digital Marketing (2018). The Best Western River North Hotel sees 300% increase in Revenue with New Progressive Web App. http://www.brewerdigitalmarketing.com/blog/case-study-bw-river-north [2020- 06-01]

Can I use (2020a). Service Workers. https://caniuse.com/#feat=serviceworkers [2020-04-10]

Can I use (2020b). Web App Manifest. https://caniuse.com/#feat=web-app-manifest [2020-04-10]

Can I use (2020c). https://caniuse.com/ [2020-06-10]

CERN (1992a). W3 servers. http://info.cern.ch/hypertext/DataSources/WWW/Servers.html [2020-03-01]

CERN (1992b). HTML Tags. http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html [2020-03-01]

Christensson, P. (2014). Web Application Definition. https://techterms.com/definition/web_application [2020-03-01]

Chromium (n.d.). The Chromium Projects. https://www.chromium.org/ [2020-05-20]

Cimpanu, C. (2018). Brave browser moves to Chromium codebase, now supports Chrome extensions. https://www.zdnet.com/article/brave-browser-moves-to-chromium-codebase-now-supports-chrome- extensions/ [2020-05-20]

Cloudflare (n.d.). What is transport layer security (TLS)? https://www.cloudflare.com/learning/ssl/transport- layer-security-tls/ [2020-05-20]

Connolly, D. (2000). A Little History of the World Wide Web. https://www.w3.org/History.html [2020-03-01]

Croll, A. (2017). Building m.uber: Engineering a High-Performance Web App for the Global Market. https://eng.uber.com/m-uber/ [2020-06-01]

Electron (n.d.). Build cross-platform desktop apps with JavaScript, HTML, and CSS. https://www.electronjs.org/ [2020-03-10]

Fablet, Y. (2018). Workers at Your Service. https://webkit.org/blog/8090/workers-at-your-service/ [2020-05- 20]

Firtman, M. (2020). Progressive Web Apps in 2020. https://medium.com/@firt/progressive-web-apps-in- 2020-c15018c9931c [2020-05-20]

Gambhir, A., Raj, G. (2018). Analysis of Cache in Service Worker and Performance Scoring of Progressive Web Application. In 2018 International Conference on Advances in Computing and Communication Engineering (ICACCE), 294–299. https://doi.org/10.1109/ICACCE.2018.8441715.

Gaunt, M. (2019). Service Workers: an Introduction. https://developers.google.com/web/fundamentals/primers/service-workers [2020-04-20]

Giampietro, M. (2013). Twenty years of a free, open web. https://home.cern/news/news/computing/twenty- years-free-open-web [2020-03-01]

Google (2018). Chrome Enterprise release notes. https://support.google.com/chrome/a/answer/7679408#68 [2020-04-20]

Google (2019a). Mobile-first indexing best practices. https://developers.google.com/search/mobile- sites/mobile-first-indexing [2020-03-01]

Google (2019b). Introduction to Service Worker. https://developers.google.com/web/ilt/pwa/introduction-to- service-worker [2020-05-30]

Google Developers (2018). George.com enhances the mobile customer experience with new Progressive Web App. https://developers.google.com/web/showcase/2018/asda-george [2020-06-01]

Google Developers (n.d.). https://developers.google.com/ [2020-06-10]

Gray, M. (1995). Measuring the Growth of the Web. https://www.mit.edu/people/mkgray/growth/ [2020-03- 01] http archive (2020). Report: Page Weight. https://httparchive.org/reports/page-weight?start=2020_02_01 [2020-03-01]

Lee, J., Kim, H., Park, J., Shin, I., Son, S. (2018). Pride and Prejudice in Progressive Web Apps: Abusing Native App-like Features in Web Applications. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 1731–1746. CCS ’18. Toronto, Canada: Association for Computing Machinery. https://doi.org/10.1145/3243734.3243867.

LePage, P., Beaufort, F. (2020). Add a web app manifest. https://web.dev/add-manifest/ [2020-05-30]

Majchrzak, T. A., Biørn-Hansen, A., & Grønli, T. M. (2018). Progressive web apps: the definite approach to cross-platform development? 10.24251/HICSS.2018.718.

Medley, J., and contributors (2020). Web app manifests. https://developer.mozilla.org/en- US/docs/Web/Manifest [2020-04-20]

Mills, C., and contributors (2019a). Making PWAs work offline with Service workers. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers [2020-04- 20]

Mills, C., and contributors (2019b). Browser storage limits and eviction criteria. https://developer.mozilla.org/en- US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria [2020-04-20]

Mills, C., and contributors (2020a). Add to Home screen. https://developer.mozilla.org/en- US/docs/Web/Progressive_web_apps/Add_to_home_screen [2020-05-20]

Mills, C., and contributors (2020b). Service Worker API. https://developer.mozilla.org/en- US/docs/Web/API/Service_Worker_API [2020-05-30]

Mills, C., and contributors (2020c). Progressive web apps (PWAs). https://developer.mozilla.org/en- US/docs/Web/Progressive_web_apps [2020-06-01]

Mills, C., and contributors (2020d). Using the Web Storage API. https://developer.mozilla.org/en- US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API [2020-06-10]

Nath, V. (2019). https://twitter.com/VishnuNath/status/1109830188487999488 [2020-05-20]

Netcraft (2020). February 2020 Web Server Survey. https://news.netcraft.com/archives/2020/02/20/february- 2020-web-server-survey.html [2020-03-01]

Osmani, A. (2017). A Pinterest Progressive Web App Performance Case Study. https://medium.com/dev- channel/a-pinterest-progressive-web-app-performance-case-study-3bd6ed2e6154 [2020-06-01]

Osmani, A. (2019). The App Shell Model. https://developers.google.com/web/fundamentals/architecture/app- shell [2020-06-01]

Patonnier, J., and contributors (2020). Using the Notifications API. https://developer.mozilla.org/en- US/docs/Web/API/Notifications_API/Using_the_Notifications_API [2020-06-10]

Pérez, J. M. (2019). Building Spotify’s New Web Player. https://labs.spotify.com/2019/03/25/building- spotifys-new-web-player/ [2020-03-10]

Russell, A. (2015). Progressive Web Apps: Escaping Tabs Without Losing Our Soul. https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/ [2020-03-10]

Said Tahirshah, Farid (2019). Comparison between Progressive Web App and Regular Web App. Blekinge: Blekinge Tekniska Högskolan. Bachelor Thesis. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-18384 [2020- 03-10]

Schwarz, D. (2016). 3 Vital Ways a Mobile-First Approach Can Improve Web Performance. https://sympli.io/blog/2016/07/19/3-vital-ways-a-mobile-first-approach-can-improve-web-performance/ [2020-03-10]

Si, S. (2020). Google Is Forcing You to Switch to HTTPS by October or Lose Rankings. https://seo- hacker.com/google-adopt-https/ [2020-04-20]

StatCounter (2020). Desktop vs Mobile vs Tablet Market Share Worldwide. https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-200901- 202002 [2020-03-01]

Subramani, K., Xingzi Y., Omid S., Phani V., Kyu H.L., Roberto P. (2020) Measuring Abuse in Web Push Advertising. ArXiv:2002.06448 [Cs] http://arxiv.org/abs/2002.06448

Think with Google (2017). The next billion users: trivago embrace progressive web apps as the future of mobile. https://www.thinkwithgoogle.com/intl/en-gb/consumer-insights/trivago-embrace-progressive-web- apps-as-the-future-of-mobile/ [2020-06-01]

Verney, L. (2020). Manage expiration of cached assets with Service Worker caching. https://phyks.me/2019/01/manage-expiration-of-cached-assets-with-service-worker-caching.html [2020-06- 01]

W3C (2020). Web App Manifest. https://www.w3.org/TR/appmanifest/ [2020-05-30]

W3schools (n.d.-a). HTML Introduction. https://www.w3schools.com/html/html_intro.asp [2020-05-20]

W3schools (n.d.-b). CSS Introduction. https://www.w3schools.com/css/css_intro.asp [2020-05-20]

W3schools (n.d.-c). JavaScript Tutorial. https://www.w3schools.com/js/default.asp [2020-05-20]

W3schools (n.d.-d). What is JSON? https://www.w3schools.com/whatis/whatis_json.asp [2020-05-20]

WebKit (n.d.). A fast, open source web browser engine. https://webkit.org/ [2020-05-20]

WebSiteOptimization (2014). Average Web Page Breaks 1600K. http://www.websiteoptimization.com/speed/tweak/average-web-page/ [2020-03-01]

Appendix Performance data for Chrome, Windows 10

Load (ms) RWA RWA 2 PWA PWA 2 PWA-C PWA-C-2 1 940 666 997 681 1050 164 2 1020 693 931 660 964 178 3 1000 748 1000 671 871 177 4 983 716 993 661 935 176 5 949 704 957 713 1010 170 6 1030 680 985 655 987 169 7 1010 697 951 670 1010 192 8 978 708 1060 650 993 183 9 1020 668 893 637 996 184 10 979 693 959 692 981 176 Average 991 ms 697 ms 973 ms 669 ms 980 ms 177 ms

Data Transfered (KB) RWA RWA 2 PWA PWA 2 PWA-C PWA-C 2 1 2108 391 2509 253 2522 37,1 2 2131 355 2505 253 2497 32,3 3 2127 360 2531 258 2509 44,1 4 2140 355 2496 261 2490 30,6 5 2131 355 2496 249 2490 10,8 6 2128 371 2501 262 2481 10,8 7 2126 405 2496 261 2518 15,2 8 2109 390 2467 296 2502 30,6 9 2130 382 2509 241 2531 28,1 10 2109 348 2509 253 2487 33,6 Average 2124 KB 371 KB 2502 KB 259 KB 2503 KB 27 KB