author
Emily Grossman
Marketing Consultant

About Emily Grossman

Emily Grossman specializes in app search marketing, with a focus on strategic deep linking, app indexing, app launch strategy, app store optimization (ASO), JavaScript-based web apps, and Progressive Web Apps (also known as PWAs). Emily has spoken about mobile application marketing at national and international conferences and has collaborated with major US brands on their mobile marketing and mobile app strategies. Emily was one of the original employees at Double Encore, Inc, one of the first native application development agencies (acquired by WPP’s POSSIBLE in 2014).

In her Learn Inbound talk, Emily will discuss how marketers should be measuring, auditing, and optimising performance for the greatest impact in their organisation. The speed at which users can load and use your website can have a critical impact on your marketing initiatives and your bottom line. Now that web traffic is dominated by mobile devices with unique connectivity issues, delivering fast web experiences can be more difficult than ever. However, this also presents an incredible opportunity for your business to distinguish itself from its competitors by investing in performance improvements.

Key Takeaways

  • Learn how to measure, audit and optimise site speed performance for the greatest impact
  • Why the speed at which users can load your site can have a significant impact on your bottom line
  • How site performance presents an incredible opportunity for your business to distinguish itself from competitors

Video Transcription

How are you doing? Excellent. I am so excited to be with you here today to talk about performance. Performance is a really interesting concept. Who here knows what performance means just from hearing that word? Not a lot of us. Right? A few us, maybe. Just to get us all on the same page and dive right in, performance is the speed at which pages are downloaded and displayed to people, to our users, to our customers. Why might that be important for us as marketers?

Let's throw it all the way back to Maslow's hierarchy of needs. Maybe a more modern version of Maslow's hierarchy of needs, thank you, internet, but I actually think that this version is not as accurate as this one. That's because slow Wi-Fi is actually worse than no Wi-Fi at all. I mean, it's on a T-shirt, so it must be true, but also just think about the pain of this Reddit user who says, "Slow Wi-Fi pisses me off." That's real pain. That's frustration. That's the language of somebody who never wants to be in that experience again. The truth is, when we're waiting for something to load, it is really, and I mean scientifically stressful. It's more stressful than watching a horror film. As marketers in general, we try not to piss off the people who make us money. So you can see why this might be a problem.

Even when we look at it quantitatively, this can be a really big problem. Like 10% of your audience lost kinds of problems. Luckily the flip side of this is when we do well delivering great experiences to our customers at a fast pace, they also reward us. They're delighted. We get increases in conversion rates and engagement. Decreases in balance rates, the real ones. We get interesting things like an increase in orders on eCommerce sites. Or an increase in conversion amongst new customers. Customers who have never touched our page before. This can translate or real money. It can be $300,000 in increased revenue, or it could be £800 million year in increased customer spending. Performance can be really valuable. Speed can be really valuable for marketing. Let's put a pin in that for second and think about why it might be valuable for SEO? If you're not in the SEO world, you may not be aware, but earlier this year Google announced something called the speed update.

It sounds really cool. It doesn't feature Sandra Bullock. Basically, what they're saying it does is it's a new update to their algorithm that's supposed to add a rankings impact to sites based on their site speed in mobile search results for the first time. They've been previously doing this for desktop, but not for mobile. This was a big announcement. The too long didn't read of this is that it would impact your rankings. So you could still be included in the results, but you might be ranked differently. Actually, it only impacted slow sites, not fast ones. The idea was that if you were really, really slow, you might get demoted. If you were super, super fast, it wouldn't impact you.

Google, as a result, said that they only expected a small number of results to be impacted by this change. You're listening to me say this and think, "Okay, well, I don't have to worry about it then. It's not a big deal." Actually, I would say, "Speed updates aside, your performance, your website's performance, is critical for searchers." That's because it impacts their experience in a really interesting way when viewed in a search context. If you imagine that all of the sites on Google are sort of like products in a grocery store, you'll know that your competitors are right next to you and waiting. If your product is broken and busted, leaking all over the place, nobody wants to deal with it. Not only will you lose that customer, but they'll probably put money right into the pocket of your competitor who's waiting and lurking right there.

Okay, there are tons of reasons for us to care about performance as marketers. You would think that the web would be blazingly fast. But that's not true. In fact, Nicholas Dot, who I love, and I follow a lot of her work, did this incredibly extensive study in the UK. She looked at 1000 of the top UK domains and found that a lot of them were really struggling. They were struggling to provide interactive experiences to their users in less than ten seconds on a 3G mobile network. Irish websites can be on the struggle bus, too. This spans news and this is just actually getting a navigation up to users in a reasonable amount of time on different networks. We're seeing this also in travel and other different verticals.

Today I want to ask the question why do we suck at this? It's hard. It's really hard. But, seriously, it's super, super hard. One of the things I did early this year was I followed this incredible developer evangelist at Google. He works on the Chrome team. His name is Paul Kinlan, and he posted this interesting blog post where he basically detailed all of the challenges that developers are going through right now in 2018. A huge section of his blog post was devoted to struggles that developers have when it comes to optimizing websites for performance.

Now we can't go through all of these, but I wanted to focus on two where I think that marketing can really help where if we do our jobs we can give our websites an advantage over the other websites where there's less of a collaborative environment between the developers and marketers. The first issue I noticed was that developers don't know what the goals that they need to aim for are. I say goals, and I think, "We are great at talking about goals." We love goals. We even invented a whole new word for them. We call them KPI's. That's fantastic. Okay, well we can work with that.

Then developers don't have all of the information about their user base, and the impact that their decisions have on them. Well, user bases, we love to collect data about user bases. We just heard an entire talk about that. Also, impact. That's our job. We love to talk about impact. How do we fix this very slow web? Or how do we fix our slow experiences? Today I want to talk to you about involving yourself. Involving marketing in these conversations around measuring performance, auditing performance, and optimizing your performance.

Let's start with measuring performance. Measurements are just actually a proxy for feelings. Now, we talked about how a slow experience can often be associated with stress and anxiety, but how do we know what a fast experience feels like? Can we associate that with something else?
Google has done a really good job of labeling what kinds of things users might be looking for. Indicators that things are moving along quickly and fastly in their web experience. They want to know, is it happening? Is it useful and is it usable? Once we understand that these are our user expectations, we can start to associate various measurements with those feelings. Those measurements might have interesting different names. Things like first content, full paint, first meaningful paint, time to interactive, but what we're really trying to figure out for these users is do they know that it's happening? Do they know that it's useful? And do they know that it's usable? For marketing to be involved in these conversations allows us to make our measurements truly meaningful to us when we get them back from our engineers.

It also helps the engineers to know what matters from a marketing level. Does this content need a picture loaded for it to feel meaningful? Or is that image irrelevant? These are the kinds of decisions that we have to make hand in hand with developers. Let's talk about auditing performance. We know what we want to measure, but how do we do that? This is very tricky and in general in performance optimization tasks, we're looking at two different kinds of measurements. We're going to do lab tests, and we're going to real user metrics tests, otherwise abbreviated as RUM because it's easier to say, and it sounds delicious.

But let's talk about lab tests. Sometimes we call these simulated tests. They're lots of different tools that allow you to do these lab test. Basically, what you're doing is you're inputting a URL and you're getting out some information from a simulated test environment. There's a machine somewhere that says, "We're going to try and simulate what a user might experience over various different connections, or the connection that you set yourself, and we're going to give you back some results."

What you might get back from something like this, from a lab test, is a set of timings. Timings that are going to indicate some of the measurements that we talked about before and certainly you can set those up yourself.
You might also get something back that looks like a film strip. The film strip is going to show you what's visually happening as those calculations are being made. In the case of web page tasks, which is the tool that I'm using here to show you information, you might also get a waterfall. That's what this is down here. It will actually continue down for some ways. Particularly on large sites. What those little bars are showing you are the requests that are being made. You can see that in a lot of cases we've got a lot of JavaScript, we've got some CSS. We've got some images. These are the building blocks that make up your site. These tools can help you segment each individual request so that you know how long each part is taking.

There is some benefits to running simulated tests. There's almost no setup required, which is great. You can input a URL and go, which also means it's really easy to track your competitors. Because you can test pages before they launch, it means that you can see how certain pages are going to run ahead of time. You can also do interesting tests because you've got controlled variables. So if you want to test something before it goes live, and you want to add something and then remove it and see what happens, you don't have to deal with other variables in the real world. You can also test for things on multiple networks and compare how things change when you move from say a 4G network connection to a 3G network connection.

The problem with these simulated tests is that they can be hard to scale and keep current, right? We're doing them at the URL level, and they can be automated, but it takes some manual labor. You often have to run multiple tests to get some real results. In web page test, for example, we'll run three tests, and we'll take the median result to get rid of outliers. Because there are no variables, although that makes for a great debugging condition, we have issues understanding the real impact on our users. If we're testing on 4G, but 75% of our users are accessing our website on a 3G connection, how much is that really telling us? Then also, it can be really difficult to measure these pages when they're dynamic. When they're having ads change in and out all the time. If those ads are changing sizes, then we're also not getting a real understanding of what things are looking like for our true users.

Let's jump over to real user performance measurement. Lots of tools again can help us with this. But this is a bit of a different sort of set up. What we're testing with real users is actually what they experience. This is kind of what we were talking about with the Google Tag Manager before. We actually want to track how far our user gets down your page and Google Tag Manager with real user performance monitoring, we want to track how far along the loading process our users are getting. Data that you get back looks a little bit different. Suddenly your performance metrics might not be a single number. There might be a wide spread. You can break these down of course by device, but there's no way around it. You're going to get a lot bigger spread of numbers when you look at your real users.

Sometimes it's easier to understand this data when we break it down into a table, and we looked at different percentiles. For example, in this table, I can easily see that 10% of our users were struggling to get to time to interactive in less than 12.6 seconds. This is the kind of information that we can use to truly understand what's going on with our user base in a real world context. The pros and cons are here, too. The pros are the inverse of that lab test. It's very scalable. We can look at those real low times, and it's great for seeing that real pain of our users in real time. We don't have to run the test every so often, it just comes in as our users do.

On the minus side, this is going to require a lot more engineering support to set up. You have to load some software or put in some event tracking to understand what's happening. You also have to deal with something called survivorship bias. This is an issue where for us to understand how long it took somebody to get to say, time to interactive, they actually have to get to time to interactive. If your webpage is so slow that people are not willing to wait it out, you're not going to get those data points as they wait for that page to load. This is really important for you to understand and sort of measure against some of your lab tests as well.

There are also some issues here with how variable this data can be and so it can be a lot more process involved in your marketing procedure. But if you're thinking that it might be nice to look at this RUM data, and the lab test data together, then you would be right. In fact, most organizations that do some sort of ongoing performance optimization will involve a cycle like this, where they'll write code, they'll test it in the lab to make sure that it meets their standards. They'll release it to users and then they'll validate that data with RUM to make sure that users are actually experiencing the lift that they predicted in the lab. I also think that it's important to combine your lab test data with your real user data when it comes to auditing and this is why. When we think about what developers currently do right now, they can look at that RUM data, and they can add it to their lab test data, and they can understand what is the real user pain that our users are having? Also, what do we think that this website could be? Where are the potential issues that we're seeing in our lab tests?

But remember that developers could already potentially do that. What they really need is information from us about who our users are, what our user base looks like and the impact of their potential changes. If you can layer on some of your analytics information about the traffic to your site or maybe even specifically the search traffic to your site. Also, your conversion rates. Maybe even your click to rates from search counsel and start to understand more about what's important. You can start to help devs prioritize.

Also, I would recommend if you can collaboratively work with your developers you can together develop an effort score. This is a score that you will make up as a team, and it will just come magically out of your brain. But it will help you to understand how much work it would take to improve your performance on these various pages. Then, at the end of your audit, you not only have an understanding of how bad shit sucks, but also what's the most important pieces of content. The most important page templates, or the most important URL's for you to try and fix first.

Let's move on to optimization. This is usually where a lot of excitement happens. Today, I hope that you guys are able to understand that optimization is just not about improving your site speed. That's certainly part of it. Improving your actual site speed is one part of optimizing your site. But I also want to open your mind to the idea that site optimization can be about optimizing your user's perception of load time and also optimizing your business. Your business has processes to make sure that over time you developed a culture that's going to prioritize improving your performance metrics. Now, when you're working on optimizing your performance in your organizations, my guess is that most of you are not going to be coding these improvements yourself. You're going to be working with a development team. The most important thing that you can learn about how to work with a development team is how not to motivate them. The number one thing to not to do with developers is to just give them tasks and assignments and have them go off and resent you forever.

Remember that developers are problem solvers. They crave problems to solve. If you give them a problem, if you frame your request as a problem statement instead of a command, you will have much more success with your development team. Let them in on your goals. Give them access to your user's information. That's what they want. That's what they need to be empowered to be successful. But if you want to know what they're probably going to do when they get their hands on the site and start working towards this goal of improved performance? It mostly boils down to ship less stuff and what you do ship, try and deliver in an optimal order. This has been true for some time. I love this quote from Patrick Meeman because really if you go read these decade old books on performance optimization, so much of them still hold true.

But I also want to spend a little bit of time talking about some of the naughty requests that we as marketers will make of our development team because I want to make sure that we're aware of the performance impact of those requests. So when we go into make those requests, we understand what we're asking to do. The first one is that images are still the number one cause of bloat on the web. This is really important to know as marketers because we love images. In fact, lots of websites have giant images on them thanks to us as marketers. If you're really interested in what it's like to optimize images on a website, please read this extensive guide. It's easy to find. It's at Images.guide. You can go through and read all of the different ways the developers have tried to clean up after us, and our giant image requests.

It's really interesting, but let's move onto something called third party scripts. Third party scripts, I've done a little Google translate from developer English for us, are things like ads, analytics, widgets, things that can be embedded into any site, but actually come from a third party source. This is a really interesting thing because we as marketers, we love to request these. "Oh, so and so said go use this thing. You can just plop it into your site." But remember that asking a developer to this is like asking them to put a subwoofer on a finely tuned car. You can optimize the car as much as you like, but it's not going to fix the fact that there's a subwoofer on top.

The real question that we need to ask ourselves as marketers is, do we really need the subwoofer? Before we go and request all this razzle dazzle on top of our website, we need to be really damn sure that we want to fight for this because the developers can't always control what it's going to do on the end. Now, a few days ago someone in the SEO space, Hamlin Batista, wrote a great post about how us as developers can go into the dev tools part of Chrome and test and see how many requests from our website are actually coming from a third party scripts. This is really cool. Basically you can go and see how many scripts are third party scripts and then you can run a site speed audit on it and you can see on a simulated test how much site speed improvement do we get from just turning those off.

When you do this you'll probably figure out just how much pain your users are feeling. Not because of what your developers are doing, but because of the extra scripts that we keep adding to our sites. This is something you can also do on webpage tests, and you can see in the side by side film strip views how fast your site might get without these scripts. So if you want to go backwards and look at all the things you've requested on your website and clean some things up, this is a great way to look at it.

The other thing that can sometimes be an issue with third party scripts is when they are render blocking. Now, render blocking scripts are special. What they do is they prevent the webpage from being displayed until they are downloaded and processed themselves. They're like the roadblock that comes in and says, "Wait for me. I'm important." Sometimes they are important, right? You actually might want your CSS to be render blocking because you don't want your users to see a flash of unstylized text. You want it to look the way it's supposed to look.

But there is some other scripts that we often add to websites that shouldn't be render blocking. They cause huge delays and one of those is AB testing scripts. How many people are doing AB testing right now on their websites? A few of us. Okay. Most AB testing tools will default to being rendered on the client side. That's this one. What that means is your website says, "Hey. There's a user here. We want you to send the website to us." They go and they get the website from the server and then the server comes into the browser and says, "Hey, I've got the website." The browser then edits the site, right? It inserts the JavaScript that it's using to make the changes to the site, makes the changes and then renders it for the user. This part can take some time right where the experiment is executing.

The other option that you might have is something called server side experimentation. If you're doing AB testing you want to look in to seeing if this an option for you because it can cut down substantially on your load times. What happens in this case is that it's on the servicer side that the experiment decisions are made, then when it gets sent back to the browser, the browser doesn't have to spend that extra processing time making that decision. This is a great video if you want to learn more about this. Patrick Meeman spoke at a conference in Boston, Massachusetts earlier this year where he talks about this, but basically you want to tell your devs, "Can we move all of our AB testing decisions to the backend?" Looking into seeing if your AB testing provider can do this for you. It'll make your sites a lot faster.

The other thing I just want to briefly mention since we just saw a whole presentation on Google Tag Manager is that Tag Managers can also sometimes also be render blocking. If you want to make sure that the decisions that you're making in your tag manager are not going to cause delays to your site, you need to make sure that not only is the tag manager loaded asynchronously, which means it's not going to be render blocking, but also all the things that it's doing are not going to block rendering as well. Really, really critical. It's possible with GTM, but you just need to make sure that that's what's happening.

The other thing that you might come across as a marketer are these very interesting new websites that are built entirely with JavaScript frameworks. They have fun names like React or Angular or Ember or Preact. If you've heard of these names or if your website is built with these JavaScript frameworks you might have come across a decision that the development team tries to make. Hopefully by consulting also with the marketing team about whether they should do something called client side rendering or server side rendering. It's abbreviated here as CSR and SSR. I want to talk about the impact that this has on loading. If we just look at the visuals here, you can see that what happens in a client side rendering situation is that the server sends a response to the browser, the browser downloads the JavaScript, the browser executes that JavaScript and now the entire page is viewable and interactable. Right? We get it all at once.

Server side rendering can be a little bit different. What happens is that the server is already sending some HTMLs to the browser. The browser can then render. Then the browser downloads the JavaScript, executes it and now the page is interactable. Right? It can do all the fun stuff that was sort of hidden in that JavaScript later that we kept back so that we could get the HTML out there. The interesting thing about this, and this is important to think about is that you might perceive the server side rendering approach to be faster, right? You've got the image sooner in the process. That's exciting and that's really good. A lot of people might go for something like server side rendering with the purpose to improve performance.

But, we have to remember that there is potentially a delay between when the content is viewable and when the page is now interactable. Which means you can sometimes get an Uncanny Valley experience where you've got something that looks like a visually ready page and you're tapping on a button or tapping in something and it's just not actually responding to you. This is the problem that we sometimes run into with server side rendered content. To solve this, we need to do something called code splitting, which essentially breaks of the JavaScript into small pieces that are focused on executing one piece of interactivity at a time so we can load something much faster than that whole giant JavaScript file.

The other things that you can do are optimized for repeat views. So if somebody hits your site the first time, we've already talked about a lot of things that you can do to serve them, but what if they're coming back for second time? Is it possible for us to change things so that we don't actually have to go back to the internet every single times we want to get assets. Can we actually save that information on their device? There's a new technology called service workers. The service worker API is supported in Chrome right now and it's about to be supported in Safari, that allow us to do just that. In the old way of working, the website would have to go to the internet for every single request it needed.

With a service worker, you can actually intercept those requests and you can store some items in your service worker cache. Then if the user needs them again, instead of going back out to the internet, which takes a long time, we can just go to the cache. That can save a lot on repeat load times. That why sites that have implemented service workers will have a huge difference between their first view and repeat view load times. You can see this in webpage test as well. The last thing I want to leave with you in this section is a process called resource hinting. Resource hinting is really interesting. Basically, it's using our user's downtime to start taking, just start downloading assets that we know that they're going to need for the next page.

Imagine with me that you own a business that sells cat toys and you have a giant page of cat toys and you know that at the end of that page, the user is probably, if they're still sticking around, going to click on our checkout page to go buy some cat toys. You know that on your checkout page you have a heavy gif image and you like that gif image. You don't want to sacrifice it, but you think, "Well, nobody's getting to my checkout page from anywhere else. They have to be on the We Sell Cat Toys page first."

So, while the user is spending time browsing that, can I start to download that cat gif for the next page and just save it until they click that button? Yes, yes you can. That's through something called resource hints. If you can predict where the user is going to go next, you can actually start to download assets for that next page ahead of time and save them. Now, I want to talk a little bit about optimizing for user perception. I talked about how our measurements are just proxies for feelings, right? In some cases we may have difficulty actually influencing those metrics. But if we can impact the user's feelings, that's still okay. We've maybe bypassed the proxy, but we can still reap the end results. The improved conversions, improved engagement, etc.

So I just want to invite you to think about two different kinds of queues that you've been in, in your life. There's a queue that moves really, really slow and there's a queue that moves pretty fast.
When I think about those two queues I think about two different processes. I think about when I was at the Dublin Airport yesterday and I had to wait like this for an hour and a half. Basically like one step forward. It was an awful long painful process versus when I went to a restaurant in London called Dishoom. I'm sure you guys have all been there. No? Maybe not?

Anyway, they have long lines, too. In fact, the wait time that I was quoted was the exact same amount of time that I spend waiting in the Dublin Airport yesterday. But the difference was that they shuffled me into different places. So first I waited outside for a little bit. Then I got escorted inside. I sat down in a place inside. Then I went to the bar. I had a drink. Then they sat me at a different bar. Then they put me in my seat. By the time it was done, I thought, "Hey, that was really fast." But it wasn't. It's just that I was constantly in an active state. Things were still happening. If you're still walking and moving in that queue you feel like it's fast even if you're waiting just as long. You can use these same tactics when it comes to your users. The next time you log into Slack, think about what Slack's doing when they shuffle you through different states. When they put you in an active state, they're making you forget how long it's actually taking for their product to load.

This is also the same principle that's behind Skeleton Screens or things like that. Instead of looking at this spinning wheel for a long time, you get this kind of flash of something that might look like content and it changes your mind for a minute and you think, "Maybe I'm ready for content now." It give you just out about of extra time to get users in an active state to make sure that they don't feel like they're waiting that long. To put this at an even more practical level, even your standard progress bar can feel faster or slower depending on how they're designed.

There's a great study, this is from Carnegie Mellon, where they stylized different progress bars and they tracked user perception based on those progress bars. They found that when they animated backwards bars on the progress bars they felt faster to users than just the standard progress bar. The last thing I want to touch on in my last minute and two seconds is how to optimize your business for future success. It's really important when you think about your business that you have to rally everyone behind this effort. That means you have to simplify your performance KPI's. You understand everything you want to measure, but what are the one or two critical KPI's that actually really impact your bottom line? Can you associate them with money to make sure that everybody at your organization understand how important 200 milliseconds really means.

Once you have this culture of everybody at your organization knowing how important those 200 milliseconds are, you'll find that people start to ask things like, "Can we afford it?" When marketing comes to the table and says, "Hey. We need to implement this really cool script that I found." Everyone will want to know, "Well what does that do to your load time?" Can we afford it? How much is that going to cost us in users or money? When you have these decisions where you can't compromise you have to compromise something that's not performance and this can be really, really challenging. But ultimately, when you're able to tie your performance decisions back to your bottom line, it's something that you can do.

Even the BBC was able to say that in peak use times when their servers were overloaded and things were getting incredibly slow, they were willing to sacrifice a lot of marketing features on their site for the sake of performance. That's because they know that one second added is 10% of their audience. If you leave here with nothing else today, I hope that you'll start thinking about what time can mean to you. Does it mean the $300,000 in revenue? Does it mean £800 million a year in increased customer spending? How much are you leaving on the table by not investing in performance?

If you want to kind of answer that question, Google just released this interesting little widget tool where they try and estimate the potential revenue impact of your performance on your site. It doesn't support every website, so you might have to include somebody else's website and play around with the numbers, but this can give you an idea of what you're leaving on the table.

Thanks very much. I've been Emily Grossman. If you're interested in performance, tons of books you can read. If you are interested in following more interesting people than I am on Twitter, here are some fantastic intelligent folks in the performance optimization space.

Thanks very much.

you might also enjoy

Share your email address and we’ll keep you updated on all upcoming marketing related events and news so you never miss a beat...