 Good morning, everyone. Thanks for being here. My name is Jesse Yang. I work for the mobile web team of Booking.com. I was in charge of developing all the sub-structures related to features for our mobile website. And first of all, I want to ask how many of you have used Booking.com before? Oh, that's a lot. Thanks, guys. And how many of you are from outside of Amsterdam for this event today? Oh, did you use Booking.com for your recommendations? Ah, that's a small number. But what's your choice for you? You can never go around to Booking a hotel in Amsterdam via a company in Amsterdam, right? And Booking.com was first founded in the Netherlands in 1996. And after 20 years, we now have over 1,940,000 properties worldwide. And it's day there are over 1 million room lights reserved on our site and apps. And in terms of the mobile website, it was first built on 2010. And after six years, as you can see, the look has changed a lot. And I bet you the code has changed a lot, too. But all these histories and numbers contribute to the promises we need to take into consideration when we build our sayings for service workers and the progress of app. First of all, our website is already highly optimized. It's converting well. It's served the business needs. And there is just no way we're going to show it away and build everything from ground. And second, we have a very large team that is still growing fast. And we don't want to slow things down just by introducing a whole new way of work. Second, we have a very large code base that is serving the websites from since the beginning of time, like from since 1996, of course. And we have a very convenient AB testing infrastructure. We use everything. We use that for every features we put online. And we just have to use that for even new features like service workers. And that's why it's very important to be progressive. And that's the whole idea of Progress Web App, right? And then the team sat down and looked into the real possibilities, the real potentials we have from service workers and Progress Web App, and also what we can really achieve with it. And ideally, you should have a very extremely optimized performance with all these fancy new patterns and infrastructure and technologies service worker can do. You can do pre-cashin app show and even stream downloading. I bet a lot of people have talked about this from these two days. And also, you can have a fantastic user engagement experience. You can have full screen that's opening your website from the home screen of users. You can have also push notifications to better re-engage your users. And for us, for our business, it's about checking reminders, review invitations. That is, when you check our hotel, we invite you to other reviews for the hotel. And also, it's something else like abandoned baskets. When you browse some hotel but you didn't book, we invite you to come back and finish your booking. But we have a very limited scope for what we can work on service workers. We currently only have secure.booking.counterman. That is what we use for booking process and post-booking pages. All these user security sensitive data pages. And we don't have HTTPS for the main websites. There are such results on hotel pages. That means we can't really experiment much in those pages. Second is, for those user engagement scenes, it's really hard to see what the real impact is. Our current experiment tool, they don't have that much of metrics for our users offline behaviors. How would you analyze those behaviors? How would you decide they are good for your business? It's challenging for us. And also, for those push notifications, we are a little bit concerned what to push. For those of you who have used booking.com, I bet you have all these experiments of receiving many emails from us, right? And even push notifications if you used our apps. So that's why we don't really want to annoy our users even more with push notification from the web. And then there is another idea versus reality check that is implementation-wise. Implementation-wise, you should have web components and full cluster rendering and all the fancy things that's making your websites a single page app. And you should also ideally have your users always logged in so that you can put some more personalized stuff for them. But we can't really go full strings for all these things. We still wear a traditional web page, which means it's simple, robust, and SDU-friendly. That is just some traits you can't easily give up just for making your things more technically exciting. And second, we still use jQuery. We are not ashamed of it. And we use this jQuery and all the small pieces of libraries that we have to write a very fast A-B testing experiment. And that's making the whole waste of our work as quick and dirty as the norm. But we are still trying to improve the quality of our code, of course. And then for the users, we have mostly last-minute bookings and new users, who will do only very no-frequency purchases. You don't stay in a hotel every day, right? That's why we start to think about the real, small list of viable steps for our experiments with service workers, what we can really achieve with it, and what is the meaningful features we can push to our users. First experiment we tried is to make our booking confirmation page accessible offline, but without telling the users that they can access it offline. The reason is that we wanted to play safe, but we still want to have a meaningful feature online and just to see how users interact with it. With this experiment, we get the idea of what the traffic size is, like how many percentage of our users actually have a service worker available. And we are also trying to clear the potential roadblocks. That is how to integrate service worker codes with our existing code space. How to make the build process more smooth. And also, we are just delivering this to users to observe if there is any side effects in any aspect. And actually, we did see a few side effects. And we saw much more page views on the booking process, which is not the page we install the service worker. There are the pages under the same SecureDobukin.com domain, but people still visited those pages much more. We started wondering, why is this? And then explanation would be users opened the confirmation page more often because they can't reach cash now. And then they navigated to other pages. But we still can't say for sure whether that's true or not. And we did also see an increase in page no time. Why is that when with service worker, with all this performance improve and everybody else is talking about why we see an increase in the page no time? The explanation would be we didn't really add any additional cash for things, but because every asset is already cached by the native caching mechanism of browser. When explanation might be service worker consumes some CPU and somehow makes the browser slower. And we didn't see any conclusive results on conversion impact. That's why we didn't really put this experiment full on. And then we went through the next experiment. Next experiment is more meaningful to the users. We're kind of telling users to add their last latest booking to the home screen so they can access their bookings even more easily. And this home screen icon will open the last same confirmation page from cash. And it opens very fast. It works offline. And it will always be the latest booking users made. So if you book another booking after you add this home screen and you use that link again, it will still open your latest booking. And for this, Rambos users just ignore this banner because it's prompted out right after users made a booking. Next iteration, we added this explanation banner before we show the prompt. This is done with the before install prompt event. I think if you have played with App Manifest, there should be you should be aware of this event. And it's quite straightforward to set up. So we use a click on this banner. We show this later prompt. With this approach, users get a better understanding of what it is and actually a very high percentage of people who clicked on the banner will accept the instrument of home screen icon. And a lot of them who added this to the home screen will actually use it. So they are not just accepting something you promote to them. They are doing this with a conscious. And this approach also lead to more people added the home screen than previous one, where we show the prompts right away. With regard to this, I want to talk a little bit about this engagement check. That is something you need to pass when you want to display this prompt. This is a flag you can turn on in Chrome, which will allow you in Dave mode to always show this prompt. But in real life, real users will only see this prompt when they pass some kind of engagement check. And that criteria is defined by Google. It is said to be the user has visited your site at least twice, with at least five minutes between visits. At first, we thought it requires you to leave your site and come back again. But actually, it doesn't. Users can still get past the engagement check in the first visit. But still, that number is this kind of limitation makes us really hard to control which type of users can see this feature. We still see a very decent amount of people who should have seen the prompt, didn't really see it. We don't know whether it's really because they didn't pass the engagement check, they didn't meet the five minutes requirement, or whether because some version of Chrome doesn't support this feature at all, or whether it's because some custom ROMs of Android disable this feature for good. And that's making it harder for us to really examine the real impact. Then I want to dive a little deep into the code we wrote for service workers. This will show you how powerful a service worker can be, just by intercepting the network requests. The first story we tried is the first one I want to talk about is consolidating canonical URLs. So the idea is different URLs for the same resource should fetch the same cache, right? Or even ideally fetch the same request. We have all these kind of different structures of URLs that is actually pointing to the same same. We have language either in the HTML doc or either in the parameters of queries. And that's why we used this SW 12 box middleware to write our own middleware to handle this. SW 12 box is a library built by Google Chrome team. If you haven't checked it out, do please check it out. It provides all this cache patterns you have, and it's very easy to use. So we created this let's work first enhanced middleware, which will just add an additional use canonical option to the options. And if this true, we will check whether the request URL has a canonical URL. And that is just a function we wrote on the client side. Just do some regress matching and try to figure out so what's the canonical URL for that specific URL. And then if it's different than the request URL, we just file a new request with the canonical URL. And then another story we had is to home screen link via reticulation. If you remember, what we added to use as home screen is a link to the latest booking. And the latest booking will have different URLs if they made several different bookings. And that's why you need to, and for the app manifest, you can only add a static URL as the start URL of the home screen icon. So that's why we do this kind of redirection for the start URL. And that's redirection. We'll always redirect to users' latest bookings. So this router intercepts all the requests for the confirmation page. And when user reach that open that confirmation page, each time a 302 redirection response was forged on the client side and stored in the cache. And then the last confirmation endpoint is used for the start URL. And every time user visits that URL, it will go through a cache only in service worker router. And it will always try to look at this 302 director from the cache. This allows us to make the home screen icon work as a shortcut for users' bookings. But actually, it is not recommended to do so now, simply because the Chrome team has decided that this is not the best experience for the users. It will feel weird if you have a home screen icon that's just opening something in the browser as a shortcut. Starting from Chrome 51, I think, if you set the display mode in the manifest to anything else other than stand alone or full screen, you will get this error. And then the app banner will never show up. And then we have another solution for pre-caching. Traditionally, for pre-caching, you will have to mist all the URLs in an array or something. And you pass that via a message to service worker and let service worker to fetch all the content. But what we did is to fire an Ajax request from the client side page and add some kind of additional or request header to it. Then the service worker gets to read that header and tries to figure out whether this is a request for the cache. For pre-cache, if this is a request for pre-cache, the service worker tries to match in those requests from the cache. And if the cache exists, then the request will never fire. If the cache doesn't request, then it fires a request with no COS mode set to no COIS. This will enable this Ajax request to be able to work even when you request something outside of the domain. And that's some ideas we had for this service worker thing. Then I'd like to talk about some final thoughts we have for service workers. And for us, it's always about finding the best approach fits your business needs. We are a very large website. We have a lot of people working on the same thing. We don't want to sell people down. That's why we have to go into this small step approach and gradually adding things up. And then you need to be creative on your solutions. I guess some of the directing and the things quite surprising to you guys, if it is. But if it's not, it's also OK. And we kind of start to, because we can't try web compilates, we can't try Polymer, then that's why we start to think about what else we can try for that. And our general experience with service worker is even if we are trying something so small, we still see sometimes the API is unstable, it's changing, and it has some added limitation for the next Chrome version. And that you don't know. Then you have to research your experiment, which prolonged our experiment circles. And that's kind of frustrating to us. But we still think the future looks right for service worker itself and for us as well. So many opportunities still awaits us to explore. And we do want to try the app show architecture, even that we are not a single page web app. We wanted to try to use the streaming API to return users a app show screen when they load the page. And the app show screen will be returned from the client side, but we will stream the real request from a server. That's the plan we want to try. And also, we want to try predictive loading. For example, when you select a room in the hotel page, it often means you want to make a booking. So that's when we decide we can preload assets for the book process. And we also, of course, are very open to build an offline resilient app. And once we have HTTPS deployed for all the web pages we have, then it will become possible. And of course, notifications, although it's kind of annoying to some users, we will still want to see the real value of it. And so the message is clear just to experience and learn, even if you are a large company who has a lot of restrictions. Yeah, thanks a lot. I hope you enjoy your stay in Amsterdam and the rest of the work.