PWAs & SEO: Why you want one, how to get them & optimize for them

Welcome to the most magical edition of Crawling Mondays, and not only because I have grown somehow this huge Mickey Mouse mouse-like hand here. However, it's going to be super magical not because of that, but because of the topic today, progressive web apps. I have started to speak about it, this topic, much more lately. Last month, you can see here, I published this blog post sharing a little bit about what they are, what are the functionalities, why we want them, and how we can actually easily start implementing them. On our own sites even. The same with the presentation that I gave a couple of days ago. I would like to cover today some of the most important aspects, highlighting those much more critical aspects that I believe that we all should take into consideration and also taking you to see some of those resources that I consider to be very, very, very useful to really facilitate the implementation of progressive web apps in any website, considering also a little bit of, of course, SEO implications of them. But we are going to see that actually it shouldn't be necessarily bad. Progressive web apps, they don't necessarily challenge additionally of what we should be already doing in today's 2019 state of technical SEO anyway. Let's take a look. The main issue is, the main challenge that we have nowadays is that we live in a world that we don't even realize, but mobile apps are broken. And they, well, they have evolved like this lately, right? Like they eat your mobile battery a lot, they take a lot of phone space, require constant updates, app content is not findable, which I have to say, this is one of the most important critical things that I will say, they pay me more as an SEO, right? The content lives on a not necessarily open environment that are the app stores and try to find something of specific information that any of these web apps have internally, right? Like there's not necessarily, that's not necessarily that easy right now. They are fragmented and vertical. There are so many different apps that brands can enable to cover limited functionality too. So at the end, this all makes app development very, very, very expensive. Why do we still keep using them? Why do we use these apps still anyway? Realistically, the mobile web especially is not necessarily that better from a usability and functionality perspective. Unfortunately, it's still Still today, mobile websites suck a lot, many of them, like the Aer Lingus, they don't even have a proper mobile site, a mobile version, or when I was looking to research a few information about a few attractions on Disney when I was going on the last days, take a look, this is an actual screenshot of the site on my mobile that I was trying to access, there was no way, and you can see how what I can actually see is the ad and that's it, right? So speed and usability are still huge challenges, and of course we cannot access the information when we are offline. This is a big, big challenge for better engagement from a user perspective, of course, and of course easier app access for frequent use too because we can add the app on the home screen of our phone and Many apps use additional— need to use additional functionalities and features of our phone hardware that is not possible to do for normal web apps. So all of this incentivizes us from a functionality perspective to end up using mobile apps, and of course, to brands to build those mobile apps despite all of the challenges that I mentioned before. This type of experience is what progressive web apps will help to fix and close the gap between mobile web, a lot of users, very high reach, good reach, but difficult to use sometimes to access the content offline, and that is why it has engagement challenges. And then on the other hand, apps, easy to use from that perspective, much more engageable, easier engagement, but in this closed environment where the content is not open. This is how progressive web apps will close the functionalities between native apps versus responsive website, mobile websites, right? They have functions online, we can use push notifications, they are installable on home screen of smartphones, and they can provide this full-screen experience. Progressive web apps are an additional add-on and provide this additional functionality on our current web experience right now. However, they don't provide any SEO advantage. I mean, they are not a ranking factor, not because we are using progressive web apps that we are going to rank better on Google. On the other hand, it should be also said that they don't necessarily challenge more SEO of what We already have, Nishali. Why? Because, well, I see that a lot of people think that, for example, progressive web apps are harder because they are web apps by default, right? And many of web apps are single-page applications. Well, realistically, many are single-page applications, but a few are not, right? And they actually— this is not a requirement. I mean, A SPA, a single-page application, can become a progressive web app. But in order to be a progressive web app that complies with all of the requirements we are going to see of the existing checklist to validate it, they need to provide a single URL, a specific URL per page. So if they are a single-page application, it won't work well necessarily. But this is a restriction and a challenge and a problem that single-page applications have, not progressive web apps, because we can evolve and we can add progressive web apps capabilities to any type of web app, not only single-page applications, but also to multiple-page applications. And we can even enable progressive web apps functionalities, and I'm going to show you how, to your existing website. Guidelines for building indexable progressive web apps, when they highlighted that one common approach to creating progressive web apps is to use client-side rendering, rely on JavaScript to generate a lot of the content of of them because many of them are the evolution of web apps. They add this progressive web apps functionalities and characteristics of already existing web apps that rely a lot— they have been developed with JS frameworks that rely on client-side JavaScript rendering in order to show content. But again, this is not a necessary challenge of progressive web apps. These are a challenge of current JavaScript development status, right, in 2019, that making it a little bit harder to Google to identify the content, crawl and index the content, to render the content. For a website, let's say that you already have a website, you don't intend to necessarily create a web app from scratch. You also can enjoy of progressive web app type of You need to build a responsive website that can also be AMP-based if you want, as an alternative of technology, of course. You can create a web manifest, a JSON file that will inform about the Progressive Web Apps to be installable, and then also set up a service worker that is JavaScript that will run in the background, defining what data is available and what there is there to update on the web. or not, and the notifications while— and make it workable also while offline. What there is out there too is to make sure that any of these different types of progressive web apps, to be considered real progressive web apps, they should comply with these features. They need to be served over HTTPS, they should load while offline, they should have a time to interact in less than 10 seconds in 3G. Each page should have its own URL, sorry, SPAS, right? So this is the requirement here. And we can see how we can provide these characteristics to any type of website. Let's take a look how. And we have here very good step-by-step guides. And I am going to show you a couple of websites that I have built following these guides. This Codelabs guide from Google is step-by-step to build a progressive web app migrating from a current existing website. We have this other that is to build a progressive web app from scratch or build a progressive web app site too. So this website that you see on screen right now, that is the website that I created that is called How PWA Works. Is actually created on PWA by following this step-by-step guide here from the Codelabs where they actually give you all the information and all the code to create your first PWA website. So for example, if I go and take a look here at the HTML, you will see how this is an AMP-based webpage here. There is a service worker here that is being And if I run here the Progressive Web App validation from Lighthouse, it will validate the main, the most important characteristics and features that I explained before that are required. Let's see. So here, so we can see how using the validation here, have been able to check that this page here, this AMP HTML-based page, passes all of these validations to be considered a progressive web app. Loads fast, serving HTTPS. In this case, where is the service worker? Response with a 200 went offline. Users can be prompted to install the web app if If we want. So this is great. We can validate that this is indeed a progressive web app. Here is another example of a shockingly progressive web app feature site. Why my web traffic dropped. And it's a website that I created using WordPress. But we can see here how, for example, this particular page here, the service worker, worker that it has here that is enabled with Super Progressive Web App, which is that here, the plugin that I use for it, and it's completely free to use with WordPress. And here the web app manifest, again, with the name. Here's the little JSON file that I generated with it, the colors, the icons to be shown and downloadable to the user. So we can also validate this easily with Chrome DevTools here using the Applications panel here. And then again, we can do the validation that as we did before with Lighthouse by checking if this is a progressive web app or not. So you can see here that in this particular case, everything was passed, but that it took a little bit longer took too much to load. Oh my, I blame WordPress for that. No, no, no, never mind. But all of the additional validations are correctly passed here as you can see. There are a few additional validations that need to be made manually, like for example that each page has a URL, site works cross-browser. Of course you need to manually check that in other type of browsers too. Pages transitions don't feel that they block. And then of course, there are web apps like this one of Starbucks that they have this parallel web app that lives in an app subdomain that have progressive web apps functionalities too. So for example, I've come here to validate this functionality. I will run the validations with Lighthouse. We are going to see how, yeah, they pass the functionality. This is a progressive web app indeed. However, we are going to see how in this other particular case, unlike the case of the AMP-based website or the WordPress website that of course is already optimizable or optimized because it was a former website where we had been doing SEO anyway before and optimizing it. This other case is a little bit different, right? So again, it passes the validations, most of them. This one of the speed is not passed, surprise, surprise. But then the other functionalities are validated, are correctly validated. However, what we can see here on the other hand is that a lot of this content here, if I come here and I see this content, I look for this content on DOM, I'm going to see that it exists there, join Starbucks Rewards to get more of what you love. However, if I go and look for this content in the source HTML, I won't find it because they rely on, again, oh, join Star Wars, we're going to take a look, it's here, but it's here in this chunk of scripts, right? This is not in the HTML. You can go to the mobile validation from Google, for example, to see the visual representation of how how Google renders the information of this app here. So that is for this particular page, but we should be able to do that for every meaningful page. And we know that this will work well maybe for smaller websites, but if this is a dynamic website that is updating the content all the time that has millions of URLs, well, it can be a little bit more resource intensive for Google and we really want to facilitate this. We don't want to rely necessarily on client-side rendering and we need to be careful and verify that the content that is indexable, that is crawlable, that is in this case rendered on the page also is the one that any user can access and the ones that we really want to make sure that Google sees from our content. But again, this is because not necessarily this is a progressive web app, this is because it's a mobile app that relies on JavaScript rendering. Last but not least, Google, I have to say, really facilitates our life on this because they have these examples here of indexable progressive web apps pages. One of them is hybrid render, another one is client-side render, the other server-side render. They provide the code here on GitHub and they have also the examples here that we can take a look. So we can share this with our developers if we're in the process to develop a new website that we want to have Progressive Web App functionalities and at some point we want to check their implementations quite easily. We can come here and we can check how it is progressive web apps for, for example, a server-render website, a client-render one. Of course, we come here and if we disable the JavaScript, we will see that there's not much to see, surprise, surprise. So if we load again, it will be like this, yes. And of course, this is something that we want to avoid, but again, not necessarily only a specific website, specific issue of progressive web apps, but the nature of the web nowadays, right? And this is why it's important to always double-check, double-validate, that we always crawl with and without JavaScript, and we compare those crawls as I show here on the slides, and we are aware that something there important is I hope that you have enjoyed today's edition of Crawling Mondays, and if you hadn't yet, you now see all the opportunities that progressive web apps have for us in the future, how easy it can be to implement, and how they don't necessarily add up much more complexity if you are already optimizing your website, what you already should be doing anyway. If you want to take a look at much more Check out the How PWA Works website, all of the resources that I have here, guides even to track progressive web app events too, how there are some themes here in WordPress that already support progressive web apps too, or tools to validate progressive web apps and progressive web apps examples too. There is something very, very important before I leave. This website, that is called the PWA Directory. Here you can take a look at many websites and web apps that are already progressive web apps too. So for example, I can click on any of them and it will allow us to see their Lighthouse validation status here, their progressive web app and performance one. And this is something that we can share with our team if they want examples, if they want reference, we can check out the the app manifest here. And this is super exciting because every time that I check out this website, there are even more progressive web apps out there too. So thank you very much. I hope that you have enjoyed today's Progressive Web App Edition of Crawling Mondays. And hopefully you have liked all the information about all the functionalities and opportunities out there. If you want me to cover any topic too that I haven't yet covered, just let me know. Send me a message or send me a tweet at Crawling Mondays, and I am very looking forward to see you next Monday too. Have a great week. Bye bye. Crawling Mondays.