This is our first Dispatch Discussion, where we discuss something that’s happening in content marketing with our host David Brandon, our president Ed Bardwell and a guest. This one included our DevOps manager Lucas Hillebrandt. You can find clips of the discussion on our socials at LinkedIn, Facebook, Threads and BlueSky.
David: Welcome everybody to our first Dispatch Discussion. Today we’re getting together with a group of us; we’re going to discuss something that’s happening in digital marketing right now that’s applicable to you.
I’m David Brandon. I’m a copywriter for Rainmaker Digital Services. And today I have with me two people. I have Ed Bardwell, President of Rainmaker Digital Services; he has over three decades of digital marketing experience, and we’re really happy to have him here with us. Ed, thanks for being here.
Ed: You bet. Good afternoon, and three decades just makes me sound old. [laughs] I’m not that old.
David: [laughs] Fair enough.
We’re going to have a different guest each time. Right now we have Lucas Hillebrandt.
Lucas: Thank you for inviting me; I’m glad to be here.
David: He’s the Dev Ops manager for Rainmaker Digital Services; he’s spent over a decade dealing with site speed challenges on the front and back end. He manages hundreds of live sites on Rainmaker Platform, he knows site speed inside and out … and if you haven’t guessed, that’s what we’re talking about today, site speed.
What do we mean by site speed? Lucas, I think you’re probably the best one to answer this.
Lucas: All right. If you try to load a website and your website takes 15, 20 seconds to load each click, you’re probably going to lose that customer, that potential profit to your business, so this becomes a very important topic for anyone who’s trying to build a community and share and sell and do anything on the Internet.
Ed: Let me jump in — let me jump in real quick, David, on something that Lucas just shared. For so many marketers, site speed is like the boogeyman under your bed. It’s like “oh my gosh, the site is slow, oh, if we’ve got one more second of delay then we’re going to increase bounce by 30%.” We’ve probably all seen those kinds of reports.
Site speed for most people comes down to two very different things that have to be connected in order to avoid this race to the mythical … you know, super site. And that is the difference between site speed as a user perception and site speed as some number on a report. And a quick illustration of that in terms of “what is site speed” … I’ve got my favorite tool, I’m sure you guys have your favorite tool, but in preparation for this conversation I did the same site speed test five times on five different site speed reporting tools. On one of them I got a 99.
Now, first of all, I don’t believe any site’s going to get a 99 or 100. On the opposite end of the spectrum, I got a 70, and in the middle I had a 83, a 92 and an A. So site speed in terms of this reporting score is something that we also need to keep in context in order to avoid wasting time, talent, and treasure pursuing something that may have some diminishing returns.
So I guess I’m going to be the wet blanket in our conversation here today.
David: Yeah, that’s fair. That is a great point, Ed, and I think one of the big things that comes out of what you mentioned is these site speed reports. A lot of people are getting those, and they don’t necessarily know what they’re looking at in practical terms.
So if I’m running a site, when I’m looking at it, I want my First Contentful Paint — so the first things that are loading on the page — I need that to be quick.
I need my Largest Contentful Paint to be quick, so I want to make sure that the biggest thing on my page is not that big.
I don’t want my layout to be shifting around so my interaction’s bad, and I don’t want a bunch of things loading that are going to block other parts of my page from loading.
Does that seem right, Lucas?
Lucas: Yeah, yeah, okay. Sounds very good.
David: So what can we do to impact these things? What can we do to change our site speed?
Lucas: The first thing I want to bring up is related to the Time to First Byte (TTFB). If you’re too far away from the server it will be backed [up], because every single request that you do to your website, it has the content itself to load and then another two or three seconds just to reach the server. You say “okay, I need this content,” then you wait three seconds, and then the server start looking for your content. So that matters a lot especially if you’re running a business that runs in multiple countries then you might have issues worldwide.
If you’re focusing only on a specific country you might not care that much as long as your server is placed in the right location.
David: So broadly, just kind of breaking in a little bit here, you’re looking at distance and kind of the actual physical hardware, right, of the server, the size of the pipe in between, like those are physical things that have an effect on this and there’s only so much you can do about that, right? Like you’ve got Content Delivery Networks (CDNs), you’ve got ways to work with the distance and the hardware, but those things are fairly set in stone, right?
Lucas: Yep, I would say so.
Ed: Well, let me jump in on that … because I think one of the things that you kind of glazed over, jumped over there, David, is at the beginning of Lucas’s description about the hardware and the infrastructure: depending on where you want the content to be served. You know the Internet is a global environment, but the fact of the matter for most businesses and B2B sites in particular [is that] most of us have, even though it’s not required, a geographical target audience. You know, for Rainmaker, we are fortunate to have clients on every continent except Antarctica, and we’re working on that. But the fact of the matter is the majority of our clients are in the U.S., Europe, and Asia. But in general, the question that I would challenge any person concerned with site speed [with] is “where’s my audience.” That will really help them determine whether they need to take any of these steps that Lucas is mentioning.
So something to keep in mind again … this isn’t about sight speed as a pure number. It’s a relative experience that we need to keep in mind when it comes to things like that investment, whether we need a CDN or whether we need some type of load balancer solution.
David: Yup. Makes sense.
So continuing on, Lucas, there’s some other aspects of this too. You know, when we talked about this earlier you talked about PHP and some of the back-end stuff as an admin. Can you talk about that a little bit?
Lucas: Yup. So let’s visit hardware a little bit.
So we talked about the distance between you and the server, but actually the server resources are also important. If you’re buying a very cheap server with low RAM, one CPU, you can’t expect that site to be able to handle 1,500 clients using the site at the same moment. So we need to also take in consideration that even if you have a big server — you have 100 CPUs, you have 64 gigabytes of RAM — if you don’t know how to customize your server stuff, optimize your PHP, optimize your MySQL to accept more users, to use more RAM, to use more disk, because all of them come with default settings … even if you have the greatest hardware available, if they’re not customized for you, you will not see a difference.
So if you don’t know what you’re doing, you should probably hire a tech guy or talk with your hosting provider. They should be able to assist you with that. It is relative based on your audience, and this is when cache comes in.
You can try to optimize the best you can on the server by doing cache. Cache is basically — you are optimizing some parts of the request or sometimes even the whole request on the server, so whenever resources act accessed multiple times, instead of needing to generate that page over and over again, you generate it once, save it on a on a physical file that we can serve so it saves processing from the server. So cache is very important, not only on small servers but on big servers.
Ed: For all of this section that you’re talking about, Lucas, I think the bottom line is having that conversation with your tech team, whether that’s internal IT or a hosting partner, and saying “This is what we’re trying to serve. Is the server, is the hardware configured to properly present that content to the internet?” That’s what you’re suggesting. This isn’t just some type of cavalier “Hey, optimize your PHP.” That’s going to mean different things for different people.
I do think — to what we were just saying about the infrastructure — that it’s very important to separate what a site admin or a marketing guy can do or should do versus what physically or what technically is possible. Those are two different items and we do need to keep them in mind.
But for most folks, site speed reporting, a score will be most impacted by looking at things that the site admin themselves can control. And I would suggest that breaks down into content, which would be media, you know, the size of images, things of that nature, and then what we’ll call scripts, which would be CSS, JavaScript and things of that nature. So I would say that there’s those two big buckets.
In general, when we get a report about site speed, David, one of the things that we always do first is we look at folks’ images. In fact, I had the opportunity to do a site audit last week, and the site was very well constructed. It didn’t have any extra CSS, no JavaScript, the site was amazing, and yet its scores weren’t very good. And so I, a little bit befuddled, went and looked at their homepage hero image — which was simply a static image — and that static image was 8,000 pixels wide. Clearly somebody had taken a picture with their iPhone and simply loaded it to their server, and that site was loading the full image and using code to resize it rather than using some type of optimization. So though it was being shown on my monitor at 1,920 pixels wide, it was still loading 8,000 pixels of data, or a minimum of four times as much information as needed.
So on the content side there’s a lot we can do: optimize images, don’t load scripts multiple times, if the page isn’t using the script don’t load it.
David: Lucas do you have any other input on things that as a site admin people can affect?
Lucas: Yes. Site admins should be worried about cache. I know I talked about cache on the server side. There are some cache [settings] that are exclusive for the server guys, but there are some other kinds of cache.
Because customers usually, at least on a WordPress environment, they are allowed to install their WordPress plugins, and there are plenty of plugins that will help you. Install cache plugins to optimize your JavaScript, your CSS. There are even plugins that whenever you upload an image it will automatically optimize the image for you so you don’t have to remember about it, and so you just install the plugin, configure once, and moving forward whenever they upload an image it should be optimized.
So not just for images, but they should be doing that for CSS. Usually when you’re building a site you add a lot of CSS, and some of that CSS is not really related to the page that you are looking at, but it’s still being loaded because the file is there. So there are plugins to remove the CSS that’s not being used — they basically read the HTML, they look for the references and see “Okay, there isn’t any reference for this on this page, so let’s remove it.” And with that removal we can save space on the network that you need to download, and you can improve speed. So they should be looking at plugins. And this is not just for WordPress, but I’m most familiar with WordPress, so this is where I’m bringing the subject. But any tool has cache plugins that can help.
David: So from your perspective, we talked about kind of what you can do from your side as a back-end admin, Dev Ops guy. For me, you know, the things that I can do as a site admin who’s working on the site and has access to the front end of things, there’s a lot that we’ve gone over here. The big question for me is: how much time, how much effort should I be investing in my site speed? How much of this actually matters? and in what context does it matter?
Ed: Well, I’m going to jump in on this. And I think it’s very important with all aspects of digital to balance time, talent, and treasure with the marketing objectives.
I can remember a thousand years ago we were working with a major league baseball team. And as an email guy in those days, all I wanted was an email address, and I felt really good if I got email address and first name and last name. But the marketing guys at this major league baseball team wanted over 20 different data points — and I said “No way in hell! This thing is going to crash.” And you know what? I was wrong. Because what they had said on the form is: “you fill this out, we’re gonna give you access to the clubhouse, we’re going to give you discounts on merchandise.” It was an insiders’ club, and their bounce rate on that form and on form completion was very, very low.
Well, site speed’s exactly the same deal. All things being equal, faster is better. But faster as a condition for worse content will fail, so better content will beat slower content. Faster with equal content, faster will win.
So to your question, David, I would say: keep everything in context. Look at your competitors. If your site’s loading in five seconds and theirs is loading in six seconds, and the content’s about the same, I would suggest to you that you’re doing okay. There are many surveys out there that look at — for example, I like BrowserStack — they will say the average e-commerce site, the average retail site, the average B2B site. See how your site compares performance-wise with those industry or those vertical metrics. If the average retail site’s loading in five and a half seconds and you’re at four and a half seconds, you’re probably okay, and you shouldn’t invest a lot of incremental time into trying to get faster. Certainly if your primary competitor’s at three and a half seconds, you have an issue, but you need to keep everything in context.
You need to make sure that you’re looking at things relative to other components, and the most important component is your content. if you’ve got a great message, if you’ve got a meaning, if you’ve got a reason for people to wait, they’ll wait. If you don’t, they won’t.
Lucas: Just to add to the conversation, it is important to say that it’s not really important that, all of the pages on your website, the score is good on those speed tests. Let’s say you are selling online courses. If you had a 10 minutes video on that page, it will score zero. 10. And the value on that page is not the site speed, but the content that is there. So you shouldn’t worry too much if you have other kinds of value on that page.
You should probably value more talking about the site speed on the pages that you are putting as landing pages for customers to click and buy stuff, or on the forms where they really can reach out.
Other than that, I just wanted to say that one other important item that you need to worry about is related to how many people you expect to be on your website. Because while you can run a report in the middle of the night and the site performs great, whenever you are doing a sale and then you plan a launch for a product and you have a thousand people reaching a website, it might break. Because your server is not prepared for it. So usually if you’re trying to do a launch or something, reach out to your technical guy, to your hosting. Try to get some advice, maybe even bump for a higher tier on your server for a few days so you can guarantee you will not lose revenue.
David: Makes sense.
So kind of summing up: site speed’s important because it affects your user experience and can impact your search rankings. But it’s the experience for the users — it’s the content that matters the most. As we’ve kind of gone through here, there are some things that you can do on the front end — changing your caching, making sure your content is small and optimizing your scripts — that can make a real big impact on your site speed with only a little bit of effort, but it’s important not to chase diminishing returns with this.
Site speed is good, but it’s only part of a bigger picture.
Does that sound about right, guys?
Lucas: It does.
Ed: Well concluded, and obviously there’s a reason why you’re the marketing guy. That was really well done. Exactly right from my perspective.
David: Thanks, Ed. Well, thank you guys both for being here. Thank you Ed, thank you Lucas. Appreciate you coming on this Dispatch Discussion, and hopefully for you out there in the audience you found some value in this.
Thanks for reading. If you enjoyed this, sign up for the Dispatch to get digital marketing knowledge in your inbox every week.