Make Improving Page Speed Your End of Year Goal
Earlier this week, I received an email from a software provider that we use saying, “starting November 1st, we’re entering a code freeze.” The logic was simple. Since so much commerce takes place in the last two months of the year and next week there’s a major election here in the United States, pushing new code could cause bugs that interfere in the overall product.
That doesn’t mean, of course, that the company stops working. My guess is that they take this time to recalibrate, identify any issues that should be fixed and deployed in the New Year and focus on some work that they might not have had the chance to get done in the rest of the year.
We can do this too. Rather than spending the rest of the year working on new initiatives, we should take stock of what we’ve already done and identify opportunities to set the business up for a stronger 2021.
One area I’d like to see more media companies focus on is page speed.
Back in 2010, Google started telling site owners that site speed was becoming a ranking factor. At this time, this was only for desktop, but the message was clear. If it comes down to two sites—a fast one and a slow one—Google would likely prioritize the fast one if all else is equal.
The logic made sense… Google’s users are looking for information and they don’t want to wait. To ensure that the users think of Google as a helpful tool, Google wants to help users get their information as fast as possible.
In mid-July 2018, speed a ranking factor was rolled out across all mobile devices as well. Google was going to prioritize the fast pages over the slow pages because that’s what users wanted.
When I was interviewing Dotdash’s Neil Vogel, the words “speed” or “fast” came up multiple times. That is a fundamental priority that never changes for the company. If users are going to build a fond relationship with your brand, they need to enjoy the experience. Speed is critical to that.
I want to focus on two areas of improvement that can really help. You can obviously do things like image compression, but these two things can make huge contributions to your speed time.
Let’s dig in…
There’s something really special about the ad tech space. Each year, many new ad tech companies launch promising to help publishers increase their revenue. They all promise more and more money.
And yet, ad revenue at media companies has been dropping for years. No matter how many new providers there are out there, it hasn’t prevented a drop in ad revenue for many publishers.
But there are some publishers that are actually seeing increased revenue from advertising that runs counter to the whole “Facebook and Google are taking everything from us” narrative.
One reason? These publishers have focused on a philosophy that less is more with ads. And when it comes to page speed, this couldn’t be more true.
For a long time, we’ve all operated on this idea that we need to add more advertisements to the page and more SSPs to the stack. This way, we’re getting every last penny out of the experience.
The problem with this is that every additional advertisement and every new demand partner contributes load time to the page. I remember a time when we had 15 different demand partners on CoinDesk. I would watch as each of those partner bids came back. It took time.
But what was so interesting is that AdX won 65% of the time. One partner; 65% of the won impressions.
We did an analysis and found that five of the partners that were in our stack were contributing less than 5% of our total revenue, but were adding upwards of a second in load time. So, we removed them from the stack. We saw no discernable decrease in revenue, though.
There are two reasons for this. The first is that other partners, who were bidding just slightly less, filled those impressions anyway. And the second is because we saw a slight increase in the number of pageviews per session. Between those two things, revenue didn’t take a hit at all.
And the user experience improved, which is what we should always be aiming to achieve.
Here’s what I would recommend you do for the rest of the year…
First, analyze each and every demand partner that you currently work with. Which are contributing the least revenue? Keep a list of them. Then look at all of the demand partners and see what their latency is. Find the slowest ones and keep a list of them. At minimum, if the lowest earning demand partners are also the slowest demand partners, cut them.
Second, analyze each of your ad units on the site. Determine how much money they are making for you. Take the lowest ones and look at where they are. My guess? Toward the bottom of the page. You can do one of two things here. First, cut them, which will absolutely increase page load speed. Or, you can introduce lazy loading to these units. In this case, the ads won’t call until it’s in view.
With this second one, you’ll get two immediate benefits: increase in page speed and an increase in revenue. Why publishers think advertisers would want to pay for out of view advertisements baffles me. Alas…
Clean up 3rd party trackers
I was having a conversation with Ben May, the managing director of The Code Company and the guy rebuilding A Media Operator from the ground up, about page speed. As a developer focused solely on media companies, he’s constantly tasked with increasing the speed.
One of the greatest misconceptions is that moving this code from your website to Google Tag Manager (GTM) will somehow fix the problem. It won’t. You’re simply moving that problem to GTM.
Fortunately, Google has a solution to this that many publishers likely don’t know about yet (I didn’t until I was talking with Ben).
Back in August, Google introduced Server Side Google Tag Manager, which fundamentally changes how these various tracking tags are deployed on the website. Let me explain what that means…
As I said above, because GTM typically loads in the browser, when a site loads, those tags fire. With server-side, though, it’s a lot faster because the loading doesn’t take place in the browser. This explains it more elegantly:
Server-side tracking works by creating a custom endpoint for the analytics calls that your website makes. This endpoint is on a server that you control and have provisioned (e.g. analytics.yourdomain.com)
With client-side tracking the analytics hits (events, transactions, pageviews, etc.) that your regular GTM container are usually sent straight to your analytics tools (i.e. Google Analytics and Facebook). In server-side tracking these hits are first sent to your server, which then figures out what to do with that data.
So instead of having multiple streams of data going to multiple places, you have one stream coming to and from your website.
One important note… It does require work to actually switch from client-side to server-side delivery. Google has details on how to do it here. I would absolutely encourage you to look into doing this, though, because if done right, it could dramatically reduce the amount of loading that takes place.
When we think about audience development, we spend so much time thinking about off-site tactics to bring users to the site. However, we don’t spend as much time thinking about what happens when a user lands on the publication.
By increasing page load speed, you can directly impact the number of users that visit and, just as importantly, keep them on the site longer.
Reducing the amount of ad tech partners and doing a better job managing your analytics tags are both great ways to help increase the speed of your site. This is just the start, however. Identify other parts of the experience that are slowing you down. As a hint? Look at your images and video.
Give your users a fast experience and they’ll appreciate it. So will Google and that’ll drive more users for you to convert into owned audience.