 Hello, I'm Ron Mirwood. Yeah. And I'm Sam Dutton. And yeah, we'd like to really talk to you about some of the revolutionary changes we're seeing in e-commerce. Yeah, you've seen a lot of e-commerce sites demo today. And we really think this is just the beginning of the conversation. Because the pillars of the PWA technologies that you've seen, we really think these are fundamental to improving the online shopping experience out there. Indeed, at the heart of the e-commerce revolution is this huge growth in mobile computing. The shift to mobile has completely transformed the landscape for online retail. You've seen this, right, a couple of years ago, depending on whose stats you look at. Mobile overtook desktop. And this is a huge shift for e-commerce in particular. Not just that, but we're seeing, of course, this huge growth in the number of people online who generally don't actually use desktop or laptop devices. Not just mobile, but mobile only. And just bear in mind that mobile only doesn't mean that everyone's doing e-commerce on high end spec, high end smartphones. New phones like the Geophone here and the Arcadell go flip, they're hugely popular and they're becoming a very appealing and accessible upgrade for many users, not least the hundreds of millions of feature phone users who now want to shop online. And all this is a major challenge for e-commerce developers. And just to be clear, online shopping is already a huge deal. Last year, mobile commerce was worth something like $123 billion in the US alone. Globally, the mobile share of e-commerce is growing really fast. In the US, mobile accounts for nearly a quarter of all e-commerce. And we're seeing similar figures for other countries. Now, it's no surprise, given the rise of mobile computing, that a majority of commercial traffic is coming from mobile devices. Now, what is surprising, perhaps, here is how much of mobile e-commerce is happening on the web rather than in native apps. Retail on mobile and desktop web already gets a relatively high proportion of user time compared to other verticals where people are more inclined to use mobile apps. This data from a recent UK study shows that retail has a relatively low share of app minutes compared to other verticals. There's another growing problem, I think, for native apps here. The reality is that, unless you're one of your customers' best-loved stores, you're unlikely to find a place on their home screen. And I think this is, like we've heard, where the mobile web really shines. You get reach for e-commerce without that barrier to entry. However, conversion rates, people who actually complete a purchase on mobile, on the mobile web, are far lower than for desktop websites. Mobile conversions are about 1 third of desktop conversions. And this is, I think, a fundamental challenge for the web. The web has gone mobile, but conversions on mobile remain low. Of course, this is not all about negative experiences on mobile. People have positive reasons for completing purchases on desktop devices or in store. People use different devices, I don't know, different times of the day in different contexts. And platform share actually varies quite a lot between retailers. There are even seasonal differences. I just learned, actually, that in the US, there's this big increase in mobile usage for purchases between, like, Black Friday and the end of December. It's interesting. But the fact is that the shopping experience on mobile has left a lot to be desired. We've all done this kind of stuff, yeah? And e-commerce, as I realize now, is all about removing friction. And we need, I don't know, we need much better integration with devices and with platforms. Another way of cutting this is to look at time spent online versus money spent on mobile. Simply put, people in the US spend most of their online time on mobile, but much more of their money on desktop. Now, given the success of online retail already on mobile, a better shopping experience represents a huge opportunity for the web. So how do you get started with that? Roman, please tell us. Oh, I'm glad you asked. Seamless transition. OK, I want to open up my section with an overused cliche, which I will seamlessly shoe into an e-commerce context for you. And it's this. If a customer doesn't convert on your site and no one is around to measure it, does it actually make a difference? People are on your site, they may even be buying things. But if you're not measuring it, you can't make an informed decision about what to change. So we've told you about setting a performance budget. I want you to do that. And I want you to be measuring things like low-level metrics, like page load. That's useful, but it's not the whole story. Also, look at the holistic metrics, like Serma was showing you, like time to interactive, because that's more indicative of the user's actual experience. However, none of this actually means anything if you measure these signals purely in isolation. There's no value. When we've constantly reiterated the performance message to you, the foundation of it has been that users are abandoning those slow sites. There's a real consequence for poor performance. So what you need to do is use your own business metrics to create your definition of success. Those metrics, the technical metrics, are then tracking your progress towards it. Of course, the problem with all of this is people. Once you give people, and especially developers, a score to work towards, they're going to focus on trying to hit that score. And that leads to this kind of thing. If I'm incentivized on performance metrics, then I can optimize for a page load, bandwidth, time to interactive, and so on. And in fact, here it is, the world debut. This is turboshop. This is the fastest e-commerce experience in the world. And it looks like this. It's a text box where you pop in the product ID and you just press buy. A search box and a button. We know this pattern works. This is going to change the world. Now, I hit all my performance targets, so the business metrics are going to be equally amazing, right? No? OK. A slightly extreme example. But I do see this kind of thing happening in the real world. It might be that it's just cutting the number of images that are in your image carousel to reduce bandwidth. Or maybe you have a database query that's quite intensive, fetching a list of products, so you limit the number of products that's returning. The thing is, people will cut critical content in order to meet the performance metrics that they're being incentivized on. So what you need to understand then is what's the right business metric here. To work that out, you have to understand what people are actually trying to do on your site. And here are a few examples. Firstly, 90% of the users coming to your site are going across multiple devices to make a purchase. So sure, it's easier to measure conversion if it all happens on the one device, but it's really not the whole story. And when I say embrace that, I don't mean just make a good experience on mobile and a good experience on desktop. I mean really support me moving between those as part of that journey, because browsing on mobile and then purchasing on desktop is actually a fairly common pattern. And it's not always just cross-device, either. 87% of people are checking online before they head into a physical store to make the purchase. So don't assume, just because I didn't convert on the site, that that doesn't mean success. And finally, you can mirror that back again. When they're in the store, they're right back on their phones looking for information about the products that are in front of them. So I want you to measure conversions, but I also want you to think about where the customer goes after that. If you got the experience right, they're coming back. Maybe they're even telling their friends or colleagues about it. So you need to dissect your pages to understand how those components are affecting the conversion for different user types. Do they read the reviews? How many carousel images are they looking at? And provide ways to tie that online experience to the in-store experience as well. Because basically the message here is that the technical metrics are just a tool for tracking progress towards the business value you're trying to deliver. Don't just blindly try and pursue these performance targets because we've told you to. Always be reevaluating your metrics to ensure that they're incentivizing the goals that you really care about. Okay. That little bit of intro out of the way. Let's dive into the first and most obvious aspect of an e-commerce site, which is actually showing people products. The message I want to convey here is really just an architectural one. For implementation, I kind of want you to take everything you learned in Addy's talk and Soma's talk and just apply it here. The end, go home. But remember the business objective you're trying to achieve because it can be tempting to find creative interpretations of some of these metrics. For example, here's an anti-pattern that I've seen on a few sites, which are going to remain nameless. And it's when you start adopting an app shell style architecture, it's incredibly helpful in getting that time to first paint down. And it's tempting to say that it's a meaningful first paint as well. I mean, we got the brand up there. We had an indication of progress. But what I came for was the product. So don't let your code structure dictate the way that you display content on screen. Fix this by ensuring that you understand the performance budget for your shell. And that's not delaying your other content by waiting for the shell to actually boot up. Additionally, there's this one. And I still see this. And this is unstable loading. So you got your critical content there first. And it's great. It's glorious, right? It's this cat that lives down the street, which obviously you want to see a larger version of. So you get right in and you're just about to tap and bam. We pop an ad in right under your finger. OK. I like the dog. Beautiful. We need more cat pics, not more dog pics. Now, honestly, when people stop doing this, I can stop including it in presentations. Not only is this annoying to your user, but all that additional rearranging of elements is hurting your page performance as well. So make sure, like Serma said, if possible, you include everything you need to do the layout of that page in your first request. You can actually see this approach in action if you take a look at how AMP renders its content. Even if you're not implementing AMP, you should learn from the lessons of what they do here. By mandating a static layout, it means that the runtime can calculate the elements that are going to appear in that first viewport and optimize to load those resources first. Images get loaded on demand. Ads are always loaded with a really low priority. And these best practices come through when you look at some of the AMP format. So here you can see a little snippet where we've got an iframe, we've set the height and width, we've provided an image in the middle, which is going to give us our fallback while it's loading. But AMP also defines this layout component, which provides some rules like responsive, fill, and fixed, and so on, that allow that flexibility in the display of the element, but in such a way that it's still possible to determine the layout without the content there already. As the format's grown, we've been adding more elements to address the needs of different verticals, like e-commerce, the AMP bind component is what's enabling the behavior up here, i.e. clicking a different color to change the product image and so on. These examples come from the aptly named ampbyexample.com. So you can go there to find way more detail about this. And as well, earlier, Tau mentioned Overstock where they've added AMP for their category pages. Now, that stable loading that I talked about in the layout means that I get that real meaningful content in front of me near instantly and tie it back to the business metrics that I was talking about. They've seen an 8.3 jump, 8.3% jump in conversion from these pages. Looking at the screenshots, though, images are pretty prominent here. Now, the AMP image tag provides a number of optimizations out of the box, but what about your publishing on the wider web? Well, luckily, Sam has some opinions about this. Yes, indeed, I do. Product image is a fundamental component of just about every e-commerce site. Successful online stores display dozens of product images on every landing page. And now, as you've heard from Ava's presentation, you need to develop load strategies for all your images. But of course, e-commerce is kind of different. Product images aren't just for decoration. Whatever devices or platforms or e-commerce frameworks you're targeting, you really, really need to optimize your images. We review a lot of websites. And I have to say, you know, I think it's... Well, I think it's fair to say that better use of images is the single biggest improvement that many e-commerce sites can make. You know, with image optimization, small changes can have a big impact. And, you know, as we know, that data blade can increase data cost but also can eat into memory, which can have a really detrimental effect, especially on lower-spec mobile devices. And as actually Sam Saccone will describe in his talk, you know, image loading can actually... Like load and decode can actually delay JavaScript parsing. So you need to be really careful about this stuff. Using the wrong image format, you know, this is a particularly common cause of data blade that we see on e-commerce sites. This example is from a well-known shopping site. The biggest images, it turns out, and I looked in the DevTools, are photographs saved as PNGs. You know, this second one here is like a photo of a cat that I managed to easily reduce to, like, around 13K, you know, just by resaving as a high-quality JPEG, compressing with image opt-in. This is a huge deal, you know, for the mobile web and e-commerce. Another common problem we see on e-commerce sites is product images saved with dimensions, you know, larger than needed. You should, of course, save images using pixel dimensions that are appropriate for target display size and pixel density. And this can significantly reduce data costs, but, like I say, also memory usage, which is, of course, a particular problem for low-spec devices. In this example, actually quoted from Adi Osmani's book about images, he's just published his e-book, Twitter made some changes, and they actually reduced decode time for a lot of their images on the timeline from, like, 400 milliseconds to 19, which is huge, really, by making, you know, just a really simple change there, getting image sizing right, yeah? Of course, not loading images at all is a great solution, or, you know, not loading images until they're required can solve a lot of data cost problems for image hemi sites, but you do need to be careful. You know, with product lists, like infinite scrolling or otherwise, it can be really sensible to avoid pagination, but, you know, we do see this on a lot of e-commerce sites. There's nothing worse than being forced to wait for images to load while you scroll. You know, don't do this. This kind of jank loses customers. Now, the new Intersection Observer API that I think Marika and Monica, I think showed briefly earlier, can provide a much less janky experience. This API gives JavaScript the ability to respond when elements are about to enter the viewport. Let's see that in action, and we'll see some kittens. This is Lyas and Little Puss. Anyway, you know, in this demo, the image is actually only loaded when it gets to within 100 pixels of the viewport, and you can see, of course, the image actually loading from the DevTools network panel. It's pretty easy to code this kind of thing. In this example, I've added the data source attributes to each image, specifying the image to load, and then in the JavaScript, you create the Intersection Observer and set it to watch for, like, one or more images, and then set the source when they're about to come into view. In this example, the root margin is set so that the callback loads images 100 pixels before they reach the viewport. Of course, you can't always guarantee images will load in time, especially when you're considering fluctuating connectivity. You know, as you've seen on lots of sites, you know, a nice technique to improve perceived performance is to load a low-resolution placeholder before the full image. You know, Facebook, Medium, lots of sites have done, like, really, really ingenious versions of this in different kinds of ways. One of my favorites takes on this, actually, just seen recently, is Image Trace Loader. I don't know if people have seen this, but you can see it here. And this is using a node module that creates SVG placeholders, which can then be used in line. It's really nice. One thing that's actually struck me looking at lots of e-commerce sites is the sheer number and, you know, churn rate for images. I just counted, and Amazon has, like, something like, I think it's 81 images on first load of its, you know, its homepage on mobile, and a whopping 290 images on desktop. That is a lot of cap. It is. That's astonishing. Yeah. So, you know, as well as, obviously, individually optimizing, like, you know, hero images, you need to automate. You must automate image production. And thankfully, there are a lot of really good free and paid-for tools and services to create and optimize images. The point here, I think, is that to handle images at e-commerce scale, you must incorporate good optimization tools in your workflow. It's kind of fundamental. So, finally, you really need to also build image testing into your workflow. And Lighthouse makes this really, really simple. You know, identifying images that could be better compressed, better sized, or otherwise optimized. You know, people love high-quality images on retail sites, and they can really help drive retail traffic. But you need to make sure that they don't weigh down your website. Oh, thank you. Okay, that was a pretty intense blast. I can keep going if you want. No, no, no, because we already, we cut... Subject dear to my heart. We cut, like, 80% of our content already. So, yeah. Okay, we've shown you some products with beautifully optimized images. But that first product isn't always the one you want to buy. You may actually want to navigate around the rest of the site. So, we should probably think about doing that. Now, I feel like e-commerce occupies this space somewhere between content consumption and a task-oriented application. If I'm consuming the video content, then the player will buffer ahead, ensuring, let's say, the next 30 seconds of video are loaded for me. So, as I explore your site, I want the content that I visited to be appropriately cached so I can come back to it. And ideally, I want the content I will visit to be preloaded so it's ready when I get there. Course bandwidth isn't free, so I'm not gonna be happy if you go ahead and preload every single possible link off of the page. One way you can go about doing this, if you have a service worker in place caching your incoming requests, is that you can use the link rel prefetch tag. Now, what this means is that prefetch, the browser will fire off a low-priority request for the resource you've specified in its idle time. Now, this means you can safely start to warm up the next set of resources without impacting the user's current experience. The difficult part here is not doing the prefetch, it's choosing what to prefetch. So, like I was saying before, you need to use your metrics to determine what are these likely next steps and build a threshold in for when you want to fetch them. Now, you can also just use to add items to the cache directly yourself. As Jeff mentioned, the cache API is actually available from the window as well as the service worker. This is useful if you want to trigger this behavior in response to a user action. So for example, if you have products that are often purchased together, once I add one to my basket, you could go ahead and pre-cache the other products so that they're ready for me to browse through immediately. The other thing that you could also do here is just trigger a fetch request. So if you already have a fetch handler that is handling your caching, especially if you're doing something more complex, then firing the fetch lets you encapsulate that behavior all in the fetch handler and just do the caching there. While this is more powerful, you do need to be a bit more careful. These requests are just sort of fired as soon as you specify them. So you're responsible for scheduling them and be careful not to mix in this kind of approach with like the preload and prefetch as well because you can easily trigger duplicate requests for the user. So that's some browsing and exploring. But what about if I already know the product that I'm looking for? Yeah, that's where search comes in. Findability is crucial for successful online retail. I'm not going to talk about SEO here, but what I want to talk about is search within your websites. The need for search really differentiates e-commerce from other types of sites and apps. This is one of the task-oriented aspects of the e-commerce experience. As you can see from this chart, search on shopping sites could do a lot better. This is a survey of top 50 retailers and it shows really quite high levels of frustration. Basic problems with search. Product search really needs to improve, even just to match data beyond product names would be an improvement for a lot of sites. A good start with this really is just to look at your search logs and see how people are actually searching. I think there's a common theme in a lot of this. It's like resilience to differences in online behavior, the variety of ways that people search for products, in this case. So Rowan talked about caching static content or preemptively caching resources dynamically to make sure not to interrupt the customer flow. But what about search for e-commerce websites? People have a perception that native apps can work without connectivity or under flaky connectivity and not the mobile web, but that's changing. Wouldn't it be great if search could work offline? Search that could handle flaky connectivity is not available on any e-commerce site that we're aware of. We'd like to be proven wrong, but this seems strange to me. Places with intimate and connectivity, like public transport, for example, are exactly the kind of contexts where people might want to search or browse your products. There's a reason why there's advertising on subway trains and buses and so on. Of course, there are caveats, price or availability, data can become stale, and data caching can only work for a limited number of products. Content is also limited. You can't preemptively cache hundreds of product images, let alone videos or other heavy content. What data you choose to cache, choose to make available for search, depends on your users, and you can really make a choice here. Now, there are lots of ways to do search that I'm not going to talk about, you know, back-end search engines like Solar Elastic Search, newer full-stack frameworks like Firebase's Firestore, for example. What I want to show you is one simple way to build client-side offline-enabled search, not because this is the best or the only way to do it, but just because it shows that network resilient search is actually possible. So here it is in action, product search, which is like super fast, and it actually works seamlessly online or offline. Images load if they're cached, or otherwise you just get text. Now, this demo uses a JavaScript library called Lunar, which is based on Solar. As they say on the tin, it's not as bright, but much, much smaller. The core idea is that you build an index on the server or on the client and then use that with a minimal JavaScript library to implement full-text search. Now, what's nice is that the index and with the product data is JSON, it can be stored using the cache API, and that makes it really, really simple to implement, and you can even include, like I say, the data with the index in a single JSON file. The major constraint is that the index is often, you know, for a set of data that's like significantly larger than the data itself, but that can still be very manageable since JSON compresses really well with GZIP. In our test, we found that, like combining the index and product data for 1,000 items took a bit over like 300K compressed. About two-thirds of that is actually the index data. So, you know, that's pretty good. In the example I've used, I've actually used something called Elastic Lunar, which, as you can see here, compresses too are very tidy, six kilobytes. Lunar can actually be used to enable full-text search in other contexts, like with index DB, with wrappers and frameworks, stuff like DeXie and, you know, PouchDB. Let's take a look at the codes. First up, you need to build search index data from your product data, and you can do that on the server like I have here using Node. Alternatively, you could actually fetch the product data and then build the index on the client like I've done here. Second, to enable the network resilience I talked about, you can cache the index locally using the cache API. Here's some service worker code to do just that. Here, I've specified an array of resources to cache and service worker event listeners, and here's the code for caching and handling fetch requests. And then you can get your index data, load it, and you're good to go. And remember that the index data, including the product data, is now cached, so you can still do search even if connectivity goes up the spout. Finally, the bit that matters, you know, there are lots of options for search, but it can be as simple as this. Like I say, we'll give you a link to some offline search demos at the end of this presentation. Now, I understand there's just a demo and this approach is certainly not suitable for every site. The point here is that it's possible to build experiences that work really well, despite erratic connectivity or no connectivity at all. You know, service worker and the cache API mean that network resilience is becoming the norm for good web experiences. And, you know, I think e-commerce really needs to embrace that. Cool. Okay, I feel like there's kind of an extra session there, which Sam will do that at the after-party, and now we're into the home stretch, which we're going to do really quickly, which is we're actually going to add something to our basket and we're going to buy it. Well, okay, at least we're going to try and do that. The problem is over half of US consumers are abandoning their carts. That's due to small screens, too many fields to fill in, poor connectivity, or poor performance. So this is getting to the heart of that 66% lower conversion figure we showed you at the start. We want to try and solve this problem, right? If users are abandoning the site because it's a subpar experience, obviously we should address this. However, like we saw, people want a cross-device experience, so we should embrace that as well. Users should be able to choose where they want to shop, and that's the key. It should be a choice, right? Not just because we've made the alternative horribly unusable. So let's start with filling in forms. You may remember the stats from earlier today. If you don't, then here's a reminder of how many times we help people there. This is, okay, this is 8 billion sign-ins assisted per month. I think the number this morning was actually 9 billion, but I can't even imagine 8 billion, so 8, 9 billion. A lot of people. Yeah, it's a lot. Basically, what this translates to is, I would like you to mark up your forms properly. Seriously, it's so trivial to do this, and it makes your users, it makes my life a lot easier. It's not just the autocomplete. It's giving me the right keyboard for, like, my email address, my credit card number, and so on. In fact, those of you with your laptops and access to your code, check this right now, right? Get it implemented. I will review the PR for you. We promise to LGTM all of you. I saw you all with laptops. I know you can do this. Okay. And of course, like I said before, it's not just, I mean, I assume you have a metric for how happy I am, but maybe that's not the most important one. You probably want to measure some other things as well. There's an approach from Paul Kinlan that you can use here. It makes use of the WebKit Autofill pseudo class, so you can hook a listener onto that, listen to your input events. Avalar you can now detect when Autofill has been used. Okay. In the end, we're still filling in forms, though. We're still sending passwords and credit card numbers over the wire. The user experience, but the underlying problems still exist. Now, you've seen payment requests a few times today. What I want to highlight here is the journey from those forms, the basic level, this is programmatic access to retrieving those saved card details. So now you have this browser level, standardized way of retrieving card data and shipping addresses and more. But beyond that, it's also beginning to provide that integrated hook into native payment requests like Android Pay and so on. You move past transmitting card numbers to something that is both simpler and safer for you and your users. So just a quick reminder. Another video that it's almost like they knew we need to speed up, so they're like, just skip that. Just skip that. That is tragic. These are just like files on the page. How can you need to request access for that? So this is what you do. You set up your data first, your payment method, the transaction, the shipping requests and so on. You create the payment request passing that data in. When you call show, this is what triggers the request to be displayed on screen. And then when that promise resolves, when the user has completed that, you either handle the completed request and send it to your payment processor or you handle any errors. Now, payment request, as you saw, is also available on desktop, so I can have the same experience there. But what about taking my basket with me? I just don't want to browse on my phone and then re-add everything on my laptop. And like I told you, Chrome will help you there, but you're still making me go through the extra effort of pressing a button to do that. Credential management API is, again, moving from that autofill to an interface to store and retrieve the credentials. And then, as you can see here, I'm basically hitting the page, checking to see if I've got some credentials, and if I do, then I'm passing them to my normal sign-in process to log my user in. With the announcement of our one-tap sign-up and sign-in libraries, you can build on top of that to streamline the process even further. So now, my identity is just something that seamlessly travels with me, and I'm going to expect the personalized experience everywhere. Chris and Tal mentioned Starbucks earlier, so you can see how they've started with Credential Manager API to automatically retrieve my saved credentials and sign me in as soon as I hit the site. No interaction required. So, to be honest, I can't really do any thinking before I've had a coffee, so I'm enthusiastic about anything that's as seamless as possible. Yeah, thanks, Ron. Anyway, so, you know, we've taken you from, like, viewing products through browsing, search, right up to checkout, but of course, that's just, you know, a tiny slice of the entire problem. I just wanted to check, actually. We were wondering, is there anyone in the audience who's actually ever worked on an e-commerce site on an online store? Oh, my God! Okay, that's quite a lot of people. Okay, well, look, we have a lot of Googlers on hand, you know, who've worked on payments and credentials and are really experts in online retail, so please come and chat to us in the forum or wherever. You know, we'd really like to hear your experiences, what you want from the platform, and what's missing, you know, what we can do to help. Yeah, and I mean, this is really just the beginning of the conversation. It's not just us. We've been talking to retailers to try and learn about their challenges. We've been talking to e-commerce platforms, like Magento, who are busy transforming their product into a PWA platform, they're around today, and would be more than happy to chat with you as well. Now, speaking of slices, we wanted to find a way to keep serving up even more of these examples. So we're building... That was an actual boo! I feel like that's my... That's an achievement. We're building the progressively improved e-commerce for PyShop as a platform for sharing this with you. So you can follow along with our progress there on GitHub. Right, yeah. We've also put together a document to accompany this talk which has links to a lot more information, including the demos you couldn't see earlier, and also the, you know, the PyShop project and all the resources we've referred to today. Yes, so thank you for listening. You can find us later on Twitter. We'd love to chat more. Goodbye.