How to optimise your website performance for marketers and developers

WEBSITE PERFORMANCE

I signed up for a Learn Inbound Marketing event a few months ago and I must say the content of the Website Performance – A marketing priority presentation was outstanding! It also complements very well my previous blog post on how to understand your website traffic data with Google Tag Manager.

Website performance

This presentation delivered by Emily Grossman is divided into 6 topics:

  1. Definition and importance of web performance to marketers

2. Why might it be valuable for SEO (Search Engine Optimisation)?

3. Why do we suck at this?

4. Measuring performance

5. Auditing performance through Lab tests and Real User Metrics tests (RUM)

6. Optimising your site, your UX (user experience) and your Business.

If you prefer listening to a podcast than reading, please find the presentation recording below.

If you have a more visual memory, you will find the podcast transcript and PDF presentation further in this article.

PODCAST TRANSCRIPT

1.Definition and importance of web performance to marketers

  • Definition

What is web performance? Performance is the speed in which web pages are downloaded and displayed on the user’s web browser. Web Performance Optimisation (WPO) or website optimisation is the field of knowledge about increasing web performance.

  • Why is that important to marketers?

Let’s go back to Maslow’s modernised hierarchy of needs with Wifi access added to the pyramid. People feel that slow wifi is worse than no wifi at all. Waiting for something to load is stressful and annoying. And 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.

But even if we look at it quantitatively, this could be a really big problem, like 10% of your audience lost. Luckily, the flipside of this is that when we do well with delivering great experiences to our customers at a fast pace, they also reward us. We get:

  • an increase in our conversion rate and engagement
  • a decrease in bounce rates in orders on the e-commerce site
  • an increase in conversions amongst new customers.

This can translate to real money. It can an increase in revenue and in customer spending.  So performance can really be valuable for marketers.

2. Why might it be valuable for SEO?

In terms of SEO, earlier this year, people announced something called the ‘speed update‘. Basically, it is a new update to the algorithm that adds a ranking impact to sites based on the site’s speed in mobile search results for the first time.

However, this update only impacted slow sites. The idea was that if you were really slow, you might get demoted. If you were super fast, it wouldn’t impact you. Actually, I would say, the speed of your site performance is critical for searches because it impacts their experience in an interesting way when viewing a search contact.

If you imagine that all the sites in Google are like products in a grocery shop, you’ll know that your competitors are right next to you in breathing. 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 will probably put money right into the pocket of your competitors who are lurking there.

So, there are tons of reasons to care about performance. As marketers, you would think that the web would be blazingly fast but that’s not true. In fact, Nicola did this incredibly intensive 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 an interactive experience to the users in less than 10 seconds. Irish websites can be on this struggle bus, too, at getting a navigation up to users in a reasonable amount of time on different networks.

3. Why do we suck at this?

It’s hard. A developer evangelist posted a blog post detailing all the challenges that the developers are going through right now in 2018. A huge section is about optimising a website for performance.

I’d like to focus on 2 main issues:

  • Developers don’t know what the goals they need to aim for are.

Indeed, developers do not have all the information about their user base and the impact their decisions have on them. But marketers love user base data collection and impacts.

  • How do we fix slow web performance?

Today, I would like to talk about involving marketing in this conversation around measuring performance, auditing performance and optimising performance.

4. Measuring WEBSITE performance

Measurements are just actually a proxy for feelings. But how do we know what a fast experience feels like? Can we associate that with something else?

Google has done a good job at labelling what kinds of things users might be looking for, indicators that things are moving along quickly and fastly from experience.

They want to know: ‘Is it happening? Is it useful? Is it usable?’ If we understand that these are our users’ expectations, we can start to associate various measurements with those feelings. Those measurements might have interesting different names, things like ‘First Contentful Paint’, ‘First Meaningful Paint’, ‘Time to Interactive’.

But what we are really trying to figure out for these users is: ‘Do they know that it is happening? Do they know that it is useful? Do they know that it’s usable?’

As marketers, getting involved in these conversations allows us to make our measurements truly meaningful to us when we get them back to our engineers. It also helps engineers to know:

‘What matters at the 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 we have to make hand-in-hand with our developers.

5. AUDITING WEBSITE PERFORMANCE

We know what we want to measure but how do we do that? This is very tricky and in general in-performance optimisation tasks. For this, we are looking at and going to do two different kinds of measurements:

  • Lab tests or simulated tests
  • Real User Metrics tests (RUM).
  • Lab tests sometimes referred to as ‘simulated tests’.

There are lots of different tools that will allow you to do these lab tests. Basically, what you are doing is inputting a URL. Then, you are getting out some information from a simulated test environment. There’s a machine somewhere that says:

‘We are going to try and simulate what a user might experience over various different connections or the connection that you set yourself. We will give you back some results.’

You might get back something like this from a Lab test. It’s a set of ‘timings’ that are going to indicate some of the measurement that we talked about before. You can certainly set those up yourself as well.

You might also get what looks like a film strip. The ‘film strip’ shows you what is visually happening while those calculations are made. In the case of webpage test, which is the tool I’m using to show you information.

Another alternative is to get ‘waterfall‘. It allows you to view large sites/pages. Those little bars show you the requests you made. You can see that in a lot of cases, there’s a lot of Javascript, some CSS and 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 request is taking.

So, there is a benefit in running lab test. There’s almost no set up required. You can input a URL and go, which means it’s also very easy to track your competitors.

Because you can test pages before they launch, you can see how certain pages are going to run ahead of time. You can also do interesting tasks with the controlled ‘variables‘.  So, if you want to test something before it goes live like adding or removing something, you can 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 changed when you moved to, say, a 4G network connection to a 3G network connection.

However, the problem with these lab tests is that they can be hard to scale and keep current. We are doing everything at the URL level. They can be automated but it takes some manual labour. You often have to run multiple tests to get some real results.

So, in webpage test, for eg, we’ll run 3 tests and take the median results, to get rid of our data layers. Because there are no variables, we have issues understanding the real impact on our users. If we are testing on 4G but 75% of our users access the internet through a 3G connection, how much is that telling us?

It can also be really difficult to measure these pages when they are dynamic. When they are having ads changing sizes, we are also not getting an understanding of how things look like for users. What we are testing with our users is their experience. It’s actually what we were talking about with Google Tag Manager (GTM) before. We want to track how far our user gets down our page with GTM.

  • Real User Metrics tests (RUM)

With Real-User Performance Monitoring, we want to check how far along the loading process our users are getting. So, the deal you get back gets a little bit different.

Suddenly, your performance metrics are not a single number but a widespread of numbers. You can break these down by dividers but there’s no real way around it. You are going to get a lot bigger spread of numbers when you look at real users.

Sometimes it’s easier to break down this data into a table. For eg, in this table, we can see that 10% of our users are struggling to get time to interact in less than 12.6 seconds. This is the kind of information we can use to truly understand what is going on with our user base in a real-world context.

There are pros and cons to this table.

  • Pros:

The pros are the inverse of the lab tests. It’s very scalable. It’s great for seeing the customer pains in real-time. We don’t have to run the test every so often, it just comes in as our users do.

  • Cons:

This is going to require a lot more engineering support to set up. You have to load some software, put some ‘event tracking‘ to understand what’s happening. You also have to deal with the ‘survivorship bias‘. This is an issue, where for us to understand how long it took somebody to get time to interact, you actually have to get to ‘time to interactive’.

If your webpage is so slow that people are willing to weed it out, you are not going to get these data points as they are waiting for the page to load. This is important to understand and measure against your lab tests as well. There are also some issues with variables. There are a lot more processes involved with this data in your marketing procedure.

But if you are thinking it may be nice to look at this RUM data and the lab testing together, then you would be right. In fact, most organisations that do some sort of ongoing performance optimisation will involve a cycle like this. Where they will write code, test it in the lab to make sure that it meets their standards. Then they’ll deliver it to their users, validate that data with RUM to make sure that users are experiencing the lift they predicted in the lab.

I also think it’s important to combine your lab and RUM test when it comes to auditing. And here is why.

When you think about what your developers can do right now, they can add it to a lab test data. They can understand what are the real users’ pains but also what we do think this website could be. Where are the potential issues that we are seeing in our lab tests? Remember that the developers could potentially do that and what they really need is information from ourselves about who our users are, what our user base looks like and the impact of their potential changes.

So, if you can, later on, look for the analytics information about:

  • the traffic to your site or maybe more specifically
  • the search traffic to your site
  • your conversion rates and maybe even your click-through-rate (CTR) from your search console.

You would then start understanding what’s important and start helping developers to prioritise. You could also develop with them an ‘efforts’ squad. This made-up squad will help you understand how much work it will take to improve your performance on those various pages.

Then, at the end of your audit, you have an understanding of how bad shit sucks, but also what are the most important pieces of content/page templates/URLs for you to try and fix first.

Today, I hope that you are able to understand that performance isn’t just about improving your site speed. This is only part of the performance optimisation process.

6. Optimising your  website – actual speed

I also want to open your mind to the idea that site optimisation can be about optimising your business and its processes. this will ensure that over time you develop a culture that is going to prioritise improving your performance metrics.

Now, when you are working on optimising your performance in your organisation, most of you are not going to be coding these improvements yourself. You are going to be working with a development team.

How to not motivate your developers:

The number one thing not to do with developers is just giving them tasks, assignments and they’ll resent you forever.

How to motivate your developers:

Remember that developers are problem-solvers. So, if you frame your request as a problem statement instead of a command, you have much more success with your development team. Let them in on your goals, give them access to your users’ information. That’s what they want and need to be empowered and successful.

But if you are worried about what they are going to do when they get their hands on the site and start working on this goal of improved performance:

‘it mostly boils down to ship less stuff to your customers and what you do ship, try and deliver it in an optimal order.’

I love this quote by Patrick Meenan, creator of webpagetest.org because you go and read decades-old books on performance optimisation, so much of them still hold true.

I also want to spend some time talking about some of the noddy requests that, we, as marketers, will make to our development teams. Because I want to make sure we are aware of the performance impact of those requests so that when we are making those requests, we understand what we are asking them to do.

Images are still the number one cause of bloat on the web because we love images. If you would like to know what it is like to optimise images on your site, please read this extensive guide. We read it all through and find all the different ways the developers have had to clean up after us in our giant image requests. It’s really interesting.

But let’s move to something called ‘Third-Party Scripts‘. They are translated as things like ads, analytics, widgets, things that can be embedded into any sites that come from a 3rd party source. We, marketers, love to pop things into a website.

But remember that asking developers to do this is like asking them to put a loudspeaker on a finely tuned car. You can optimise the car as much as you like. It’s not going to fix the fact that there’s a loudspeaker on top. So, the real question we need to ask ourselves as marketers is: ‘Do we really need the loudspeaker?’ Before we go and make supplementary requests, we need to be aware that developers can’t always control what it will do on the other end.

Now, a few days ago, someone in the SEO space made a great post about how we can go into the development tour’s part of Chrome and check how many requests from our site are actually coming from third-party scripts.  Through Chrome Dev, you can also run a site speed. You can see on a simulated test how much site speed improvement do we get from turning those off. When you do this, you’ll probably figure out just how much pain your users are feeling, not because of these extra scripts you keep adding to your site.

This is something you can also do on webpage test. You can see in side-by-side ‘film strip views’ how fast your site might get without your scripts. You can then go back and look out all the things you’ve requested on your site and clean them up.

The other thing that can be sometimes an issue with third-party scripts is when they are rendered blocking. ‘Render Blocking Scripts‘ are special. They prevent the webpage from being displayed until they are downloaded and processed themselves. They are like roadblocks that come in and say ‘Wait for me, I’m important’.  You might actually want your CSS to be rendered blocking because you don’t want your users to see a flash of unstyled text. You want them to see it the way it’s supposed to look.

But there are some other scripts we sometimes add to our sites that shouldn’t be render blocking, as they cause huge delays. Some of those are ‘A/B Testing Scripts‘.  Most A/B Testing tools will default to being rendered on the client’s side. What this means is your website says’ Hey, there’s a user here we want us to send the website test’. And then they go and get the website from the server. Then, the server comes into the browser and says ‘Hey, I’ve got the website’. The browser then edits the site. It inserts the Javascript it’s using to make changes to the site and then renders it for the user. This part can take some time to be executed.

The other option that you might have is something called ‘Server-Side Experimentation’. If you are doing A/B Testing, you want to see if this is an option for you because it can cut down substantially on load times. In this case, the experiment decisions are made. Then, when it gets sent back to the browser, the browser doesn’t have to submit extra processing time making that decision.

Another thing I want to briefly mention is that Google Tag Manager can also sometimes be rendered blocking. If you want to make sure that the decisions you are making in your GTM aren’t going to cause delays to your site, you need to make sure that not only is the Tag Manager loaded asynchronously (not render blocking) but also that all the things it’s doing aren’t  going to block render as well.

The other thing that you might come across as a marketer are these very interesting new websites entirely built with Javascript frameworks. They have fun names such as React, Angular, Amber, Preact… You might consider working with your developing team to figure out whether they should do something called ‘Client-Side Rendering‘ (CSR) or ‘Server-Side Rendering‘ (SSR).

  • Client-Side Rendering

I’d like to talk about the impact this has on loading. In a CRS situation, the servers are responsible for the browser. The browser downloads the Javascript and executes it. The whole page is now viewable and interactive.

  • Server-Side Rendering

SSR can be a little bit different.in this instance, the server is already sending some rendered HTML to the browser. The browser can then render. The browser downloads the Javascript executes it and now the page in interactive. It’s important to think about how you might perceive the SSR approach to be faster (image shows up sooner). But we have to remember that there is a potentially a delay between when the content is viewable and when the page is interactive. This means that you can get something that looks like a visually ready page but when you tap on a button, it’s actually not responding to you.

This is the problem we sometimes run into with SSR content. To solve this, we need to do something called ‘Code splitting‘, which essentially breaks out that Javascript into small pieces. This will focus on executing one piece of inactivity at a time so that we can load something much faster than that whole Javascript file.

The other things you can do are optimising for that ‘Repeat Views‘. So, if someone hits your website for the first time, there’s not a lot of things you can do to serve them. But what if they are coming back for the second time? It is possible for us to change things so that we don’t actually have to go back to the Internet every single time we want to get ‘assets‘? can we actually save that information on their device?

There’s a new technology called ‘Service Worker‘ API.  It is about to be supported in Safari and allows us to do just that. With the ‘Service Worker’, you can actually intercept those requests and store some items in your Service Worker cache. Then, if the user needs them again, we can just go to the cache. This can save a lot of repeated load time.

The last thing I want to leave with you in this section is a process called ‘Resource Hinting‘. It is using our users’ downtime to start downloading assets we know they are going to need for the next page.

So, imagine you own a business that sells cat toys and you have a giant page of cat toys. You know that at the end of that page, the user is probably going to click on your check-out page that contains a giff image. You like that image and don’t want to sacrifice it. But you think nobody is getting to my check-out page from anywhere else. They have to be on the resale cat toys page first. So, while the user is spending time browsing back, can I start to download that cat giff for the next page and just save it until they click that button? Yes, you can and that’s through something called ‘Resource Hint‘. If you can predict where the user is going to go next, you can actually start downloading assets for that next page ahead of time and save them.

7. Optimising UX – user perception

I talked about how measurements are proxy for feelings and in some cases, we may have difficulty influencing those metrics. But if we can impact the user’s feelings, that’s still ok. We may bypass the proxy but we can still read the end results., the improved conversions and engagement…

So, I want you to think about two different kinds of queues you have been in your life. There’s a queue that moves really slow and another one that moves really fast. I think about two processes.  I think about when I am at Dublin airport and have to wait for an hour and a half. There’s a painfully long process versus when I go to a restaurant in London. In fact, the quoted waiting time is the exact same in the airport and in the restaurant.

The difference is that at the restaurant they shuffle you in different places: outside, sitting down in a place inside, then going to the bar to have a drink. Then they send you to a different bar before sitting you at a table. By the time you are done, you think ‘Hey, that is really fast’. but isn’t. It’s just that you are constantly in an active state. Things are still happening. If you are still walking and moving into that queue, you feel like it gets fast, even if you are waiting just as long. You can use this same tactic when it comes to your users.

So, the next time you log into Slack, think about what Slacks does when they shuffle you through different states. When they put you in an active state, they are making you forget how long it’s actually taking for their product to load.

This is also the same principle behind skeleton screen, you get this kind of flash of something that looks like content and it changes our mind. You start thinking ‘Hey, maybe I’m ready for content now’. It gives you just that extra to time to get users into a state to make them feel they are not waiting that long. But on an even more practical level, your standard progress bars can feel slower or faster depending on how they are designed. There’s a great study with stylised different progress bars. They track users ‘ perception based on those progress bars. They found out when they animated backwards bars on the progress bars, they felt faster to users than the standard progress bars.

8. Optimising your business – priorities and process

The last thing I want to touch on is how to optimise your business for future success. It’s really important for your business that you rally everyone behind this effort.

So, that means you have to simplify your Key Performance Indicators (KPIs). You must understand everything you want to measure. But what are the two KPIs that really affect your bottom line? When you associate them with money, to make sure that everybody in your organisation understands how important 200 milliseconds really means. Once you have this culture of everybody in the organisation knowing how important these 200 milliseconds are, you will find that people will start asking questions like ‘Can we afford it?

When the marketing team wants a script implemented, everybody wants to know ‘What does that do to our load time? How much is that going to cost us in users?’

When you have those situations where you can’t compromise, you have to compromise on something that isn’t performance. That can be really challenging. But ultimately when you are able to tie your performance decisions back to your bottom line, that’s something you can do. Even the BBC says that in peak use times when their servers are overloaded and things are getting incredibly slow, they are willing to sacrifice a lot of marketing features on their site for the sake of performance. Tha’s because they know that one second added is 10% of their audience.

So, I hope you can start thinking about what time can mean to you. Does it mean 300 000 $ in revenue? Does it mean 800 million £ every year in increased customer spending? How much are you leaving on the table by not investing in performance?

Finally, for those who would like to download the PDF document containing more visuals and her contact details, click on the link below:

Web performance PDF presentation

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.