Shawn O’Neill, founder of SpeedSense Web Performance, is a web performance guru who works with ecommerce brands at the enterprise level. If you’re wondering whether to optimize your website, Shawn is the person to ask. Because the faster your website is, the easier it becomes to hold the attention of your customers. On this episode of Subscription Radio, Ben and Shawn chat about how to speed up the loading time for a webpage, whether or not to go headless, and when to build a custom landing page.

Show Topics

  • Make pages as static as possible
  • Show the customer the page is working
  • Load the most relevant content first
  • Run analytics as early as you can
  • Create a façade for videos
  • Make up your mind on headless
  • Know when to build a custom landing page
  • Don’t make a monolith
  • Be mindful of carbon emissions
  • Own your site

Show Links

Key Takeaways

26:19 – Make pages as static as possible

If you want to speed up the way your page loads, make it as static as possible. That means adding in fewer dynamic elements and fewer calls.

“Say they've got a thousand different category pages. Which of these do you have ad spend on? And let's prioritize inlining CSS. I could go through a half dozen different tactics that you would use to speed that page up, but one of them for sure would be make them as static as possible, fewer dynamic elements, fewer calls. And if you're going to make dynamic elements, do them asynchronously, not like before. So there's a couple of ways to do this. You could have the server do it, build up the page, render the HTML. Or you could build a page with some placeholder elements for your shopping cart, quantity, or whatever, or the inventory, and do asynchronous API calls after that so that the user sees that they're in the right place. They're like, ‘Okay. Yeah, the journey is continuous. I clicked on an ad that looks like this. I see that thing in front of me.’ And then as they're reading about it or flipping through photos, you backfill other API calls and requests.”

28:49 – Show the customer the page is working

When you’re designing a web page, focus on the user experience. Give the user a sign they’re on the right page right away, whether that’s a header, a logo, or even just a spinner.

“We just talked about designing around the user experience in general. And so the first is like, is this even working? If I clicked on an inbound link, are you showing me something that would be our first paint time? Is there a header? Is there a logo? Is there literally anything onscreen? Maybe it's just a spinner, worst-case scenario, but at least I can see that my phone isn’t locked up. So paint something as quickly as you can. Render blocking scripts, usually delay that. And that is the biggest offender because everything that comes after that is then also slower. And then there's like, am I in the right place? Do I have the right thing? So, like I say, if you clicked on a cliff bar ad, and you're like, ‘Oh, I might want to get these bars every month, a protein bar or something.’ If you land on a page, the next thing you want to see is, am I in the right place? So it's working. Am I in the right place? That's usually your largest contentful paint element.”

30:22 – Load the most relevant content first

Browsers can only do one thing at a time, so make sure it prioritizes loading the most important elements first.

“Browsers are inherently single-threaded. So they can really only do one thing at a time. And we're now used to a world where you can do a hundred things at a time, but a browser can only render Dom or process JavaScript or paint images to the screen. It can load stuff in the background, like the CPU and network are sort of decoupled, but if you are running a tracking script or booting analytics, then it can't be painting to the screen. And so we want to get in front of the user the most relevant stuff right away, and then defer stuff like user-generated content or your help widget that pops up in the bottom corner. That stuff is secondary to the reason that they've gotten there. So first, let them see that they're in the right place and consume the content, and while you've got that couple of a hundred milliseconds even of the person looking at an image, do something else then. So get out of the way.”

37:45 – Run analytics as early as you can

Don’t defer your analytics. Instead, run analytics as early as you can so that you have extra visibility into what your true bounce rate is.

“I wouldn't defer analytics, actually. That's one that probably sounds like low-hanging fruit, but deferring analytics, say it's now running at three seconds. Your page view event happens three seconds into the page load life cycle. If you push that out to eight seconds, then anybody bouncing between zero and eight, you're not even going to know they visited. And so for every brand, there's always this ratio of an invisible bounce rate that you're not even aware of, which is, they landed and they left before analytics even fired. And one thing we recommend is run analytics as early as you can so that you have extra visibility into what your true bounce rate is. So I wouldn't defer that one, but other stuff like a help widget, trust pilot reviews, anything that you can defer, and especially anything below the fold. If you've got something in your footer, don't even load it until they've scrolled halfway down the screen.”

38:42 – Create a façade for videos

Loading videos directly into your webpage slows down the loading process unnecessarily. So just use a façade so the video doesn’t add to the screen loading time.

“One more that bites people a lot is video obviously sells like crazy. Video is a must-have, but we’ll presume not 100% of the videos get played that get rendered to the screen. So the default way to embed a YouTube video is you just grab the YouTube embed code and paste it in. And what that does is when the browser is parsing the Dom, it encounters the YouTube JS, it goes and gets that, it builds a YouTube player inside your page, and then does the rest of the stuff it was doing. But a lot of people, non-zero people, and maybe a lot of people if it's really low below the fold, aren't going to play that video. So loading that player was a complete waste of time at the expense of something else that they probably should have seen sooner. So there's a pattern where you just insert basically a picture of a YouTube player. When the user clicks on that, on the fly load of the YouTube video, embed it, and play it. It's just called a facade. You load YouTube with a façade, and you can do that with a lot of stuff. It's really, really powerful.”

42:20 – Make up your mind on headless

There are many pros and cons of going headless, so make sure you’re ready to undertake the project before you make the switch.

“There’s a lot of hype in the industry about building a headless ecommerce platform or migrating to headless, and I would say there are pros and cons to that. It's not something to undertake lightly. It's much more technical. If you didn't like what we just talked about, you're not going to like a headless build. I mean, you're not going to like the progress or the project of having to implement it. You want an implementation partner. It does empower some really nice experiential stuff where shopping isn't necessarily the primary focus of your site anymore. It's a thing that you can do anywhere. And I think you alluded to that around your subscription product. You can integrate subscription in maybe a blog post or something like that.”

43:26 – Know when to build a custom landing page

The best time to create an optimal landing page is right after you’ve raised a round of funding and have extra cash on hand.

“If you're going to spend a ton of money on acquisition, if you just raised a round and you're like, ‘Okay, we’ve got to deploy this 500 grand on ads,’ that is the time to build a very custom, very fast landing page to support that campaign. And so there's a lot of strategies to make that insanely fast. And if it's going to live in isolation, then trying to keep it as static as possible is for sure the go-to, as few calls to external services, and really the holy grail here is building such a static page that you can stuff it in the CDM so that the user never even makes a call to your server. Your server can scale infinitely in that case. And when we start talking about Black Friday and Cyber Monday and flash sales and going viral, the fewer calls to your database, the more performant. The worst-case scenario for web performance is down. That's as slow as you can get is a 500 error.”

46:28 – Don’t make a monolith

If you decide to go headless, don’t make it a monolith. The whole point of going headless is so you can independently replace things as needed.

“I would say what's probably more important is the decomposition. If you're going to undertake a headless endeavor, don't get the monolith. The reason you would do it is to make things independently replaceable over time so that you don't get stuck on this forever from now on. And usually, what I've seen so far is that, what historically the ecommerce engine, the ecommerce platform, would've been the center, the brain of the website. In a headless world, it's not necessarily the case. Ecommerce functionality is just like a CMS, is just like reviews engine. It's one more thing that you plug in. And so that takes it away from being the bottleneck insert in terms of site speed.”

47:52 – Be mindful of carbon emissions

The more servers you require and the more data you send over the wire, the more carbon your business generates. But the faster your website is, the less carbon you emit.

“Something that we are really looking at and I've started having conversations around is very off-topic here, but it's the relationship between running a fast website and the carbon emissions of that site. Because the more servers you require, the more data you're sending over the wire, the more carbon you're generating, and so there's a bit of a triple bottom line play in terms of site speed, where the faster it is, the less carbon you're emitting. Granted, in the world where you're building something in China, you're shipping it into the U.S., and you're distributing it around the country, the emissions of your website are negligible. Just a drop in the bucket basically, but yeah, we're investigating that relationship and want to build a model where we can correlate CO2 emissions and site speed, just like we do now for conversion rate or bounce rate or other engagement metrics and site speed.”

49:10 – Own your site

A slow website is often a sign that no one within the company is taking care of the site. That’s where Shawn’s business comes in.

“The pain is most often felt by a product manager who sits near a development team and is fed requirements by marketing and ops. So often, companies in that tier of a hundred million or so, usually omnichannel retailers, if we're talking to ecommerce, there's also SaaS companies that we've worked with, but omnichannel brings more complexity with it because you've got inventory everywhere. You’ve got store pages and maps and things to deal with. But yeah, usually the person that we help the most is that product owner or product manager. Unfortunately, a slow website is a sign to us, generally, that no one's owning it internally. It’s not falling in IT. It's not falling in marketing. It's not falling in ops. It's just between the cracks. And so our ideal client, honestly, is an institution where that is the case, because we help bring that all together and just own that for them as a fractional team.”