 Well, it's been 74 years since Maslow published his hierarchy of needs. And there's still a lot that we can learn from it today, or maybe a slightly more modified version. But I actually think that this version is not even quite as accurate as this one. And that's because slow Wi-Fi is worse than no Wi-Fi at all. I mean, they put it on a T-shirt, so it must be true, but also just listen to the word choice of this person on Reddit. So Wi-Fi pisses me off. That is pain and frustration. And that's because when we have to wait for things to load, it is really, and I mean scientifically, stressful. More stressful than watching a horror film. Now, as marketers, we generally try not to piss off the people who make us money, so you might already be aware this could pose quite the dilemma. But even when we look at this quantitatively, we see how big of a problem it can be. Like a 10% of your audience lost problem for every second added to your load time. Luckily on the flip side, when we do a good job, when we actually deliver quick experiences to our customers, to our users, they reward us. They're delighted, and we get incredible uplift and conversion rate, engagement, or even for e-commerce sites, interesting things like an increase in orders or conversions amongst new customers. That can translate to real revenue for the business, like $300,000 in revenue, or even $800 million a year in increased customer spending. But let's talk a little bit more about why site speed might be important for SEO specifically. Now, if you've been paying attention to some of the announcements that have come out of Google, you might have heard earlier this year Google announced something called the speed update. Actually launched this week, if you're paying attention, but let's think about their announcement. I've actually read through all the documents, and I promise that there's no mention of Sandra Bullock. This is incredibly different, and it's basically Google just announcing that they're going to start factoring in speed into their mobile ranking algorithms, which is a big change for them. Previously, they had only announced they'd done this on desktop. But let's unpack this a little bit more and look at the too long didn't read here. So the announcement claimed that it would impact rankings, not indexing. So if your site was really slow, you could still be included in the index, but you wouldn't necessarily rank as well. Similar to that, it was intended to hurt slow pages and not give boosts to fast pages. So it was something that if you were already pretty speedy, you might think, well, that doesn't really impact me, and Google kind of echoed that by saying only a small number of pages should actually be impacted. So why am I telling you things that might make you think that this is not a big deal? And I think that it's because, honestly, the speed update aside, we should all be caring about page speed for SEO, not because of rankings, but because of the fact that it's incredibly important when we're trying to acquire users from a search context. That search context is incredibly critical, because in a search context, users know that they have other options. They see them all listed there. And when your site doesn't deliver, when it's not performance, when it is a terrible product, users know that they are just a back button away from somebody else who can fulfill their needs. So not only are you losing that potential customer, but you're driving them right back into the hands of your potential competitor. But we suck. I mean, all sorts of reasons to be good at this, and we still suck at it. I mean, we miss industry benchmarks. This is actually a sample size of looking at pages that are from AdWords, which means that we're paying for traffic to these slow pages that don't perform to industry benchmarks. And it's happening with big brands, too. I mean, we think often that big brands should be better at this. They have bigger engineering teams. They should rock. They should have incredibly performant sites. And that's just not the case. So I want to ask why we suck at this. It's hard, duh. But no, seriously, it's really hard. And it's hard for developers, too. And so when I wanted to figure out why we were creating this really un-performance, this really slow web as a group of people that should be motivated to improve it, I looked to Paul Kinlan, who is a developer advocate at Google, and he published this great document at the beginning of the year about some of the challenges that he sees in the development community. And one of the biggest challenges he outlined was building performant fast websites. There are lots of technical challenges that obviously developers face, but I wanted to focus on two that weren't technical at all. The first one was that devs don't know what the goals that they need to aim for are. I thought that's really interesting. Why don't they know that? And the second one was devs don't have all the info about their user base and the impact that their decisions can have on them. And I thought that's a problem that we should solve. If you think about what Johnno was saying earlier this week, we've been keeping this information to ourselves for far too long. And the fact that developers feel like they don't know what kind of impact they can have on their customers is really tragic, and this is making the web slower. So how do we fix this? Today I want to provide a framework for you to go back to your businesses and learn how to work with your development teams, work with your managers, and make sure that your products are actually delighting your customers. So the first part of this is choosing your key metrics. It's interesting to choose key metrics to measure speed. You have to ask yourself the question of what is fast? How do I measure fast? And that's actually quite a bit more complicated than we think it would be. Lots of people can define this in very different ways, but ultimately what we're looking for is to determine that speed as a proxy for feelings. We want to measure if something feels fast, right? It doesn't matter if a thing loads before another thing unless it's giving off that feeling of fast for our users. That's what's going to give us uplift. And so Google has done a good job of trying to document the various feelings that are associated with fast. Is it happening? Is it useful? Is it usable? And understanding that those are three key distinct feelings that happen as a page is loading. And then you can map those feelings to some of the more technical measurements. But I think it's really critical that we start from the feeling and map our way down instead of starting from the measurements and trying to understand what those mean. The other thing to note here is that some metrics will correlate more with your core business metrics, things like revenue or conversion rates. And it's important to understand the relationship between the metrics that you're choosing to measure whether or not your site is fast and your core business metrics. For example, if you're an e-commerce site and you rely heavily on conversion rate, something like Time to Interactive, which is measuring that is it usable feeling, is incredibly critical for your conversion rate. Now let's go back to our framework. Let's assume that you've done your research, you understand how to measure what fast looks like, and you've picked a few key metrics that are going to help your business measure how you're progressing with your work in site speed. Now you need to get some data. And that's really important is to understand, okay, we've picked what's important to us, but how do we actually do? Are we fast? How fast are we? To get this data, I want to make sure that we understand the different kinds of data that we can get when we're measuring site speed. The first thing that we need to look at are potentially lab tests. These are simulated measurements. So we're going to simulate how fast the site loads, measure that simulation, and log that in our results. The second thing that we can look at are what's called real user metrics or RUM. RUM is shorter and easier to say. Also it sounds like fun, so that's, I think, why they came up with that. So I'm going to take you through a few different pros and cons with each of these. So lab test tools or simulated performance tools. There are lots of these available. A lot of them are free. The great thing about these tools is that in pretty much all of them, you can just drop in a URL. You can set various parameters for how you want to look at that site's performance. You can choose things like your network speed. You can choose things like the location of the device. You can even narrow it down by the very device itself. And this is really helpful because when you then run that simulated performance test, these tools will give you various results. Some will even run multiple tests and give you the median because that's a bit more accurate. But in the end, what you get is sort of a breakdown of your performance by various metrics. You can even in a lot of these tools set those custom metrics up that you defined at the beginning. And if you drill down deeper into this, you can actually see a bit of that film strip view and you can see how highly correlated it is with the metrics that you defined up front. Below that film strip view, and this is in web page test, you might actually get a waterfall view of all of the network requests and all of the assets that your site has to deal with in terms of loading. And as you sort of scroll on that film strip, you'll get the same perspective on the waterfall. This is also available in Chrome Dev tools. So there are lots of tools right now that are exposing this information. The great thing about these tools, these lab tests simulated performance tools, is that there's almost no setup required. You can just go right in, you can enter a URL and you can start to get information from a simulated test, which also makes it really easy to track your competitors. You can also test pages here before they launch, which is fantastic. If you wanna see how your site speed is going to be impacted in a new page template or something like that. And it's a controlled environment, which makes it good for debugging. That means that you could go ahead, make a change and then run the same test conditions on that same page to see if there was an improvement or not. And you can be pretty sure that a lot of the test conditions were the same. You don't have a lot of variables. It also allows you to test on multiple networks and of course, different locations and devices. But on the negative side, this is really hard to scale and keep current. As you've noticed, it's kind of a manual process. And if you wanna run these, then it's gonna require some dev work to come up with a system that can continually make these requests to run continual simulated performances. You do have to often run multiple tests to get something that's a bit more accurate. That's why web page tests will run three tests and take the median results. And then it's also missing a lot of real world conditions. So you don't get an accurate snapshot of what your users are experiencing. You only get an accurate snapshot of what the specific conditions that you set up were. This makes it really hard to measure the impact of things like dynamic content. If you're constantly switching things in and out or maybe you're running lots of tests and things can vary constantly, you have no way to know if you hit the test or not. This is why it's also good to take the median result. This is where real user metrics come in. Now, these RUM tools are fantastic. They are few and far between are free, but there are actually some now that are free, particularly Google is trying to expose a lot of the data that they get out of Chrome for you available for free. When you get this real user data from whichever tool provider you choose to use or even if you set it custom yourself using something like browser APIs, you'll end up getting a really interesting way of looking at this data. You get so many different numbers, it's not quite as clean as these lab tests, and I actually think that it's often more useful to look at this data in a table than in that kind of chart because you can make statements like, it looks like 10% of our mobile visitors are having to wait longer than 12.6 seconds for our site to become interactive. Again, we're solving some of the problems here from those lab tests. We get to look at real load times of our users. It's scalable by design, we're tracking them in real time, which is exciting, so we get that information as it comes in, and it's really easy to feel the pain of our audience because we know every data point was a real person, not just a simulation. It's also interestingly what Google is looking at. So we talked a little bit about the speed update. You might have wondered, how does Google know how fast my site is? Well, Tom Antony who is at Distilled did some really great sleuthing, I think, and found out that Google was going to use Chrome usage data to impact this speed algorithm, and he wrote a great post on it at Moz so you can go read all about it, but basically, if you wanted to look at the data that Google thinks applies to your site, you can go look at it in the Chrome User Experience Report, which is available on PageSpeed Insights or in Google BigQuery. Let's talk about some of the downsides, right? This is gonna require more engineering setup. It's not something where you can just go drop it in URL and hit enter. It's gonna suffer also from survivorship bias, which means that unfortunately, since we're trying to track how long it takes for our users to get to various stages in our loading journey, if they don't get to that stage, we don't capture their measurement, right? Which can be really challenging. So if you're only looking at your real user metrics and you're not looking at your simulator reports, you might miss some of those really slow pages just because people aren't actually getting that far in the process on their slower connections. This is also limited to the specs of your current audience. So if you wanna launch something in a newer developing market and they have completely different devices or speeds of their network conditions, this is not very helpful. And it can be difficult for debugging. If you make a change and then you see something go up or down, you don't really know what changed in that time. It could have been your fix or it could have been that 5G network was released and you had no idea that all your customers were getting much faster internet. So as you might have guessed, the best thing that you can possibly do, usually in a development cycle, is to have these two kinds of metrics work together in a cycle. So you'll write your code, you'll make your fix, you'll make your edits to your page, you'll test those fixes in the lab to verify that it actually had a positive improvement on the metrics that you care about. Then you'll release that to users and then you'll try and observe that that actually had an impact in the wild. Rinse, repeat. But developers have been knowing how to do this for a long time. And I opened this presentation by saying, I think that there's a lot that we as marketers can do to impact this. So they can take the run data and the lab data and they probably already have or maybe somebody has and they can put it in a spreadsheet and they can look at how bad things are. But I think that the piece that's missing, the piece that the developers are missing right now that we really need to contribute is how important it is, how important every page template is. And we know that information. We know which users are on each page type or page template, we know which pages drive the most traffic and most conversions. And once we start factoring that information into our system, our company is able to actually prioritize this work. Now, you can even add in a little effort score if you think that that's going to be really important to your business goals. And now you have a much clearer picture. You know, not only how bad is it, but what's the potential impact and how hard is it gonna be to fix? So let's finally go into this last section, optimize the experience. And this is honestly the section that most people in marketing, I think like to focus on when it comes to performance optimization. Most people focus on this first part, optimizing sites that actual speed that we wanna improve those metrics that we set out to improve from the beginning. But I wanna remind you that our metrics were just a proxy for feelings. And if we can change user feelings, we don't necessarily have to change the metrics, right? That's just one step toward the goal. That's one way that we can help approximate that we're going to change feelings. But if we can change users' perception of how fast our site loads, we can achieve roughly the same goal. So I'm gonna talk to you about both of these and let's go ahead and start with optimizing site. Now, people have been optimizing their websites to be more performant for years now. This book High Performance Websites was released about 10 years ago. And if you ask most developers what's changed, generally the whole strategy is pretty much the same. And I love this quote from Patrick Mena who sums up what the goal is in a pretty elegant way. He says it mostly boils down to ship less stuff and what you do ship, ship in an optimal order. So let's see how that might apply to some of the things that we as marketers often interact with on websites. So images, number one cause of bloat on the web. I think we can say that that's pretty accurate still today. This is a great guide to image optimization, but I can already preview it for you because we know that we need to ship less stuff. That means ship less, shipping smaller file sizes, trying to make improvements on how much we're shipping. And then we also need to make sure that we're shipping in an optimal order. So we're prioritizing images that are critical and then we're also lazy loading the rest. And that's pretty much it. We just went through an exercise and that's exciting. The one thing that I think that is missing from this sort of general understanding of how to do performance optimization is that there then becomes often an SEO or marketing impact based on the decisions that we make for more performance websites. And in this case, it's that when we make those decisions to make some of the images lazy loaded, we also need to make sure that search engines can still see them and that they're still following search engine best practices. So Alexis talked a little bit about this yesterday, but very important to make sure that you're constantly sort of looking at the impact of what your performance decisions are doing for your marketing. The next thing I wanna talk about are third-party scripts. Third-party scripts are really interesting because these are things like ads or widgets that come from other websites where you don't have control over the script itself. And this is a really interesting thing because we as marketers, we love to request these from our development teams without putting much thought into it. But if you think about it from your development team's perspective, they can fine tune that race car, that website as much as they want because they've built that, that's theirs, they own that. But when we ask them to bring in a third-party script, what we're asking them to do is bring in something that they cannot change for the most part. Some of them you can change, but for the most part they can't. It's like asking them to put a subwoofer on top of that finely tuned race car. The only way to improve it most of the time is to just take the subwoofer off. So this is the only thing I'm gonna say about AMP today. But AMP's biggest advantage, a colleague of mine did a great research project on this, AMP's biggest advantage he found was not a lot of the fancy stuff that they're trying to do to optimize the code and everything like that. It was actually the fact that it was limiting the number of third-party scripts, the number of stuff that you could cram on a single page. And I think that that's really impressive and that's super important for us to know that if we're willing to say no to get into the AMP experience, why aren't we willing to say no to things on our own site? And so as marketers, I hope that you kind of get out of this experience that maybe there are some tough calls that we have to bring to this conversation with our developers and they're calls that we're gonna have to make. If you wanna know how badly your site is impacted by third-party scripts, there are great resources that can help you do this. The process is very simple. Essentially, you go and you look at all of the third-party scripts that you have on your site in something like Chrome DevTools, you turn them off, and then you rerun your simulated lab test and you see how much your performance has improved. You can do that in Chrome DevTools, you could also do that in web page tests. All of your simulated lab test tools should be able to help you out with something like this. The next thing I wanna talk about is render blocking scripts. Render blocking scripts are a particular beast that prevents the web page from being displayed until the script itself has been downloaded and processed by the browser. And in some cases, this makes sense, but in other cases, it can be really detrimental to our performance. So, A-B testing is the classic example of this. If you can imagine that you're running an A-B test and that decision is being made in the browser on the client side, you're maybe, let's say, trying to change a button from blue to orange to see if that impacts click-through rate. Well, what happens is the web page wants to load the blue button and then the A-B testing script comes in and says, but not until I change it to orange. And that makes sense sort of, right? We don't want the user to see the blue button and then see the orange button, but that also takes time. And so the performance fix for this is to try and move those A-B testing decisions onto the server side, which means that what the browser gets is actually the orange button, not the blue button and the instructions to change it to orange, but the orange button right away. This is Patrick Meenan explaining that in better detail. Tag managers is another one that Patrick described when I asked him what is the worst mistake that marketers usually make when it comes to creating a suboptimal website. Tag managers, he said that he often sees tag managers that aren't loading asynchronously and some of the stuff that they're doing is also not asynchronous, which means that they're blocking rendering. So if you're making decisions in your tag manager, they're going to impact the visual layout of your website and you're blocking the rendering on the browser side, that can be really labor-intensive. I'm going to move on to server side rendering. Again, Alexis kind of touched a little bit on some of the reasons why you might choose server side rendering for SEO. I'm going to talk a little bit about the page speed implications of these decisions. So server side rendering is a choice that you make sort of as opposed to client side rendering, which is maybe the default rendering solution when you implement a JavaScript-heavy website. You can kind of see the process here. I hope this is big enough for everyone to see. But basically what happens in client side rendering is that the server sends a response to the browser, the browser downloads the JavaScript, the browser executes the JavaScript, in this case React, and then the page is now viewable and interactable at the same time. That means that the user knows that it's happening and it's usable at the same time. If server side rendering, you can see that the page becomes viewable much more quickly, but then it becomes interactable only later once the JavaScript is downloaded and processed. And we have to be really careful about this because it looks really great for performance up front. It starts happening a lot sooner, but we need to remember that actually our time to interactive may be a bit more delayed. And so we have to be really careful about that uncanny valley in between when our website loads and when it becomes interactable. If you've ever come to a website where you've tapped on a button a million times until it finally clicked, you've been in the uncanny valley, and so we don't want to deliver that experience to our users. If you find yourself in this place where you are seeing a huge gap in between that viewable and interactable moment, I would recommend you look into something called route-based code splitting with your developers. Finally, I want to just mention resource hinting. This is when you notice we've got something maybe really heavy as an asset on a page, but most users are only coming to that page when they've been on another page. This is great for checkout processes and things like that. If you want to load your checkout page really, really fast and you know that that's the page that most users go to, you can do something called resource hinting to the browser, which is basically saying while the user is sort of lagging on this page, we want to load this asset in the background so that they can have a much more fast experience once they go to the new page. It doesn't have to load at that time. We can start loading it ahead of time. So it's a much better way of sort of prioritizing resources. UX, I want to make sure we get to this. So I talked a little bit about user perception and I think one of the best ways I like to think about this is with lines or if you're British, it's cues. And the reason I like to think about load times as cues is because my friend, Johnno, who you guys heard speak earlier, has told me about his friend who has the most interesting job I've ever heard about, which is that they're a professional cue designer. And that sounds like it's something that probably only exists in England, but I love the idea of this. And it turns out when you're a professional cue designer, you are designing the experience to be optimal. It doesn't mean that you're shortening wait times, but it means that you're making people feel like their wait times are a lot shorter. And sometimes what they do is try and put people in an active state. So if you've ever been in a cue, you know what that feels like? It means that you're walking. It means that you're moving. The cue feels like it's moving. And even if it takes the same amount of time as a cue where you're standing, it feels faster. And that's what tools like Slack try to do when they try and tell you, okay, you're connecting. Okay, now here's a quote. Okay, now you're in a different place. They're trying to keep you in that active wait state so it doesn't feel quite as long. This is also the sort of basic principle behind something like skeleton screens. When you see something show up and flash, it's faking that is it happening feeling for you, even though it's much less labor intensive than maybe loading the entire page. Now you might think, okay, but I am not Slack or Facebook. I can't possibly do this. How do I implement something like this on my site? It can be as simple as choosing the correct loading bars. If you know that it's going to take a long time to load your page, I understand a lot of people have to load very heavy applications for some of their products. You might just wanna be aware of the fact that not all loading bars are created equal. And it would be worth user testing to see if any loading bars you might design might feel faster or slower than others. This is a study by Carnegie Mellon that found that backwards-lined progress bars felt faster to users than ones without the stripes. But I've given you a lot of tips right now, and I'm a bit concerned that what you're going to do with this section is create a long list of things and then just hand it to your developer, which is not the way to talk to developers. Can tell you from experience. If you've ever had that frustration of, oh my gosh, my developers never do anything I ask, takes them forever to get to my projects, they seem to hate me. I'm telling you that it's probably not because you're not giving them enough beer or whatever every blog post tells you you need to know to talk to developers. It's because you're telling them solutions instead of problems. And if you instead go back to your developers with problem statements instead of this long list of potential solutions and you work on things together, I can guarantee you that they'll probably know a lot of this, but they'll also be able to find more creative solutions for you as well. So I appreciate the complete irony of me telling you to go a little bit slower to optimize your site for speed. That's exactly what I'm about to do. You're not going to be able to make these changes long-term and sustainable if you just go barrel forward and do them all on your own or handle this to your developer and then never look at it again. You have to build this into your business and into your process, which means unfortunately talking to people and building relationships. So I'm not gonna spend a lot of time on this, but I wanna give you some quick tips that I've found help organizations get their performance budgets approved and prioritize this work. The first thing is that you have to simplify those performance KPIs. So we talked at the beginning about setting your key metrics, make sure that you've made those as simple to understand as possible, you explain them to the business in a simple way. Then you wanna clarify how important they are to the org. If you can correlate them to your core business metrics like we did with Time to Interactive, then you can make a much bigger case for why everybody should care about this and watch this. And then if you can, you wanna associate that load time with real money. Remember how at the beginning of this presentation, I showed you guys some dollars and some pounds and that made a huge impression. You wanna do that with your business as well. So I wanna end today with what I sort of set out to do, which is tell you what all marketers can do about site speed. And what I hope that you'll do at the very least is leave here asking, can we afford it? Can we afford it? Is what the BBC tries to ask when their site is slowing down and they have to make a tough call. And they decide to remove some of their marketing material. That's a tough call. But it turns out that speed is much more important than the promo box. Because the BBC knows that one second added is 10% of their audience lost. Or it could be $300,000 in your revenue. Or 800 million pounds in customer spending. Sorry, I don't wanna offend any British people. It's been a rough day. So lastly, I just hope that all of you today are leaving with an immense curiosity for what are you leaving on the table by not investing in performance? And if you wanna answer this question, Google's already released a calculator that you can use to help estimate that impact in your org so that you can associate that load time with real dollars. Thanks very much. I've been Emily Grossman.