 Hi, my name is Demian, and I work at Google as a partner engineer. This is the first video of a two-part series on the topic of progressive web apps on sites that consist of multiple origins. In this talk, we will review the challenges for achieving a unified PWA experience in multi-origin sites. In the second video of the series, we will take a look at the opposite case, developers that want to build multiple PWAs, taking advantage of the same domain name. Take into account that all the use cases, APIs, and techniques that we will cover belong to the open web, so they are not tied to a specific platform, and they affect PWAs in any form factor, like mobile and desktop devices. Now, let's get started with this topic. You might have seen many sites where the user starts the journey in the main origin, for example, the home page, and as they navigate, they end up visiting different subdomains during a single session. Architectural decisions like this one often have important long-term implications on a PWA project. There are different reasons why many sites are built in this way. We can consider some of them as acceptable practices while others are not recommended. Let's start with the good uses of multiple origins. The first one is localization. For example, using a country code top-level domain to separate versions of your PWA to be served in different countries. You can also use subdomains to divide sites targeted to different locations, for example, specific cities. As we will see with these types of configuration, since users don't move frequently across origins, it's not a big problem. The second one is independent web apps. That means using different subdomains to build PWAs, whose proposed differs considerably from each other and from the site on the main origin. Here again, the user starts their journey in one origin or app and usually stays there for the whole session. So we don't consider this one as a bad practice. We will explore this use case in depth in the second video of this series. Finally, some developers separate common sections in subdomains. Well, this is not always a good practice. We can think of it as acceptable for some use cases. For example, if a company has multiple web apps and all of them use the same login flow, it is not unusual to move this section to their own origin to centralize the traffic instead of replicating this functionality in every web app. As discussed, these examples can be considered good or acceptable practices. But if you are not doing any of these things, it's likely that using a multi-origin site architecture will be a disadvantage when building progressive web apps. Let's take a look now at some examples of non-recommended use cases for multiple origins. The common one is arbitrarily separating site sections of the web app in multiple origins that should be part of a unified experience. For example, a new site with each subsection, like sports, politics, and culture, belongs to a subdomain or an e-commerce site that has the homepage at example.com where the listings, product, and shopping cart pages are in different subdomains. In this example, the user will likely move across multiple origins during a single session. And as we will see, this can be disruptive for a PWA experience. Sites sometimes have multiple origins due to legacy reasons, mostly outside of the developer's control. For example, before most of the web migrated to HTTPS, some sites had only certain sections in SSL, like login and checkout, and use subdomains to separate these more secure sections from others. After they migrated the rest of the site to HTTPS, they never moved these sections back to the main origin. As you can imagine, these types of legacy decisions do not currently provide any advantages, but they can bring negative consequences. Finally, we have also heard about organizational needs. For example, companies use subdomains to isolate the work of different teams or use that separation to simplify the reporting of analytics data across different parts of the site. These decisions don't respond to technical needs or constraints, but to external factors. So, as expected, might not end up being good from a technical standpoint. So far, we have reviewed some good and bad uses of multiple origins. Let's now take a step back. What is exactly an origin? And why having multiple origins across your site can make it hard to achieve a unified PWA experience? An origin is a combination of three things. The first one is a scheme, also known as the protocol. For example, HTTP or HTTPS. The second one is the host name. And the third one is the board, as long as it's specified. If any of these three parts is different, then the origins are entirely different. Let's suppose you're the owner of example.com and you create a subdomain at subdomain.example.com. Using a subdomain means that the host names are different. For that reason, these are completely different origins, even when they have the same domain name. So, if you were expecting that using subdomains across your PWA could not prevent you from achieving a unified experience, you might find that in reality, the level of isolation between them is actually more strict than you thought. This is because of the same origin policy. This policy imposes restrictions for sharing things like service workers, storage and permissions across origins. This might not be a huge problem in a site like this, when the user spends most of the time navigating pages in example.com and only visits the login page once in a while. But what happens in a site like this one, where the user frequently moves across different origins during a single session. First, achieving a consistent offline experience across the site can be more difficult. This is because service workers are tied to a single origin. So if you want to provide an offline experience in every part of the site, you will need to implement at least one service worker per origin. This is not only difficult to maintain, but also registering and having multiple service workers running consumes additional resources like memory and CPU. Achieving a great performance across your PWA can also be more difficult. If you want to use caching techniques to speed up your site, you will have the same problem, because APIs like IndexedDB and the Cache API are also partitioned by origin. That also makes it hard to share local data across different parts of your PWA. Permissions are also scoped to origins. This means that if a user granted a given permission to example.com, it won't carry over to other origins like subdomains. Imagine having to ask for example for the geolocation permission multiple times during a single session, or for a video calling PWA asking for the audio and camera permissions in different parts of the PWA. Finally, another related issue is that when you navigate across origins in a full screen PWA, you will see an out of scope bar indicating that you are moving outside of the main PWA experience. Having seen all these limitations, if you are going to have one take away from this talk, remember this one. If the goal is to build a single PWA experience, avoid dividing the site into subdomains. If the site is already built in that way, migrating to a single origin is always the best approach. And what happens if you already have a site built on multiple origins and you can't migrate to a single one? Here are some workarounds that you can explore. If you have a site like this one where the user spends most of their time at example.com and moves to different subdomains rather infrequently, you can keep all your service worker and cache in logic in the most frequently visited origin. Most of the time, when the users lose connection, they will be navigating these pages. In cases like these where there are many subdomains, you can check what are the ones that are most frequently visited and are your caching and service worker logic only there. Keep in mind that if you decide to add more than one service worker, this can drain more resources from your user's devices. But if you end up choosing that route, our advice is to keep service worker installation lightweight to avoid making users pay a big installation cost every time a new service worker is installed. In other words, only pre-cached resources that are absolutely necessary. From the point of view of installability, nothing prevents you from prompting your users to install your PWA so they can have a quick access icon and enjoy navigating in full-screen mode. Just make sure that you are showing the prompt only on the main PWA origin to avoid making the user install multiple PWAs. You can check out the most up-to-date install criteria for PWAs in this link. Finally, to mitigate the problem of showing an out-of-the-scope bar when navigating to other origins in full-screen mode, there is a new API that you can explore. It is called the Scope Extensions API. Scope extensions allow sites that control multiple subdomains and top-level domains to be presented as a single web app. To implement it, add a Scope Extensions App Manifest member to the main origin's manifest, indicating the list of origin to extend the scope too. Each of the listing origins has to confirm the association with the web app using a well-known web app origin association configuration file and pointing back to the main origin. The Scope Extensions API just moved to the origin trial phase. Check out this link to know more about it. And this is pretty much all we have for this talk. If you want to know more about this topic, check out the companion article to this talk about multi-origin PWAs. And don't forget to watch the second video of the series, where we will analyze the case where having multiple subdomains can play to your advantage if you want to build multiple PWAs using the same domain name. I hope you have enjoyed this talk. Thanks for watching.