The Secrets to Making Responsive Design Work on Smartphones
About the Webcast
Retail responsive design sites on average take 3.15 seconds to load on desktops, 2.80 seconds to load on tablets, and 18.24 seconds to load on smartphones, according to an exclusive, first-of-its-kind study from mobile and web performance management firm Keynote and Internet Retailer.
Needless to say, an 18-second page load time is a non-starter in online retailing.
However, there are many steps that can be taken to greatly reduce page load times on wildly overweight responsive design mobile pages, turning the pages into moneymakers.
Retailers with responsive design sites and retailers considering building responsive sites cannot miss this must-see webinar, where Keynote performance experts highlight the eye-popping results of the exclusive, month-long retail responsive design site test and reveal the secrets to making responsive design work in an increasingly mobile world.
Good morning, and welcome to the Secrets to Making Responsive Design Work on Smart Phones, an Internet Retailer webinar sponsored by mobile and web performance testing, monitoring, and analytics firm Keynote. I’m Bill Siwicki, managing editor, Mobile Commerce at Internet Retailer and editor of the Annual Industry Guide, the Internet Retailer Mobile 500. I’m just going to speak for a few minutes and offer you a glimpse of mobile commerce right now and set the stage for our featured speaker, Ben Rushlo, who is vice president of analytics at Keynote.
So not too many years ago, mobile commerce was viewed as a nifty sideshow. Something that was intriguing but not terribly important.
Today, mobile commerce is absolutely fundamental to online shopping. And it’s the direction all of e-commerce is heading. Today, 62 percent of all time spent with online retail occurs on smartphones and tablets. And that number is going to continue to get bigger and bigger. Based on preliminary research for the 2015 Internet Retailer Mobile 500, which will be published August 19, and which Keynote contributes extensive mobile performance data to, I can tell you that about 19 percent of total web sales are mobile. In the last year, we have seen milestone after milestone for mobility.
For example, take a look at consumers changing internet behaviors. These numbers on the screen are critical to our discussion here today about responsive design on smartphones. Consumers now spend far more time on the internet on a smartphone than they do on a PC. So 34 hours and 17 minutes a month on smartphones compared to 27 hours and 3 minutes a month on desktops and laptops. What’s more, the smartphone is now more popular than the American institution of television. Consumers spend 2 hours and 31 minutes a day on their smartphones and 2 hours and 27 minutes a day watching television.
Add on the 43 minutes a day they spend on their tablets, and mobile really trumps TV. There were many other milestones in the past year. So how do all these milestones and changing behaviors translate to online shopping? Mobile commerce platform provider Branding Brand offers a very current snapshot examining the web sales of 26 of its retailer clients who together hit $375 million in mobile revenues in May. Let’s just focus on smartphones since they are the heart of our discussion here today. May 2014 over May 2013, revenue from sales on smartphones soared 111 percent. Smartphone visits were up 69.4 percent.
Smartphone page views were up 85.5 percent. Orders on smartphones were up 98.2 percent. And significantly, traffic from consumers on desktop PCs was down 21 percent. When it comes to online shopping, there is an interesting new kind of shopper: the mobile-only shopper. This person never uses anything other than a smartphone or tablet to shop the web. Take a look at the retailers on Stream. A web measurement firm did a study of top retailers and found very significant percentages of these merchants’ online shoppers are mobile only. So for example, 33 percent of online shoppers at Wal-Mart.com only use mobile devices to shop the merchant online.
But guess what? Many mobile shoppers hate mobile optimized sites. In the retailer and retail systems research found that 49 percent of shoppers on smartphones who land on a mobile optimized site leave the M commerce site to shop a merchant’s full desktop site on their smartphones. Retail systems, research analysts, and other mobile commerce experts, as well as many retailers, came to the same conclusion. Retailers have been going too far in streamlining sites for use on smartphones. The mantra was always make things quick and easy. But retailers cut away many features and functions from desktop sites to make mobile sites quick and easy.
Many features and functions customers have grown used to having in order to make informed buying decisions. But that’s where today’s topic comes in because guess what? Many of those same retailers and mobile commerce experts believe the answer to better sites on smartphones, ones loaded with features and functions, is responsive design. Responsive design sites generally use one code base and one set of web content to deliver versions of the same site that fit the size of the screen of any device requesting a page. The thought of building one website that serves all devices instead of building a desktop site and a tablet site and a smartphone site is enticing.
And an increasing number of retailers are turning to responsive design to serve mobile consumers. E-retailer Skinny Ties, for example, offers a responsive design type. After launching responsive design, sales via tablets were up 190 percent. Sales via smartphones were up 231 percent. And sales via desktops and laptops were even up 99 percent. Brendon Falkowski, a top developer and the head of IT at Skinny Ties, said of Skinny Ties and responsive design, “Responsive design is directly responsible for our shoppers converting at a much higher rate than before.”
However, there’s a problem with responsive design: performance. Today’s retail responsive design sites load very, very slowly on smartphones. The average page load time on desktop PCs for 12 retail responsive design sites tested by Internet Retailer and Keynote was 3.15 seconds and on tablets 2.80 seconds. But the average page load time for the 12 retail responsive sites on smartphones was 18.24 seconds. So for a retail responsive design page to load on a smartphone taking 18.24 seconds is terrible performance and completely unacceptable. A 1 second delay in website page load time translates into a 7 percent loss in conversions according to Aberdeen Group.
So if an e-tailer makes $100,000.00 a day from its mobile site, a 1-second page delay could mean around $2.5 million in lost sales every year. So what does an 18-second page load time mean? It means trouble. And that’s where our featured speaker comes in. Keynote’s Ben Rushlo knows mobile performance like few others. I’ve worked with him on mobile performance stories and data projects for Internet Retailer. And Ben is going to talk to you about the results of the aforementioned Keynote Internet Retailer retail responsive design study and how you can make responsive design sites perform well on smartphones. So now, I’ll hand things over to Ben.
Thanks, Bill. Great introduction. A lot of interesting data there. I think the fact that smartphone and tablet usage has overtaken the TV pretty phenomenal actually. And I think some of your data probably, if you had included my teenage sons in that analysis, would have skewed even further in terms of how much time they’re spending on their phones and tablets. But I do think you really frame the discussion very, very well, which is clearly, we’re moving to a mobile economy, especially with e-commerce. Clearly, people are using mobile and tablet.
And as site developers, site owners, business owners, marketing owners of e-commerce sites, we like that. It’s a new channel. It’s a new way to drive revenue. It’s a new way to interact with our customers in even a closer sort of way. But how do we do that in a way that responds well? How do we provide good quality? And when we talk about quality at Keynote, we primarily mean performance, error free, etc. So I’ll go through a few ideas in the next few minutes. And then, of course, we’ll have lots of time for questions at the end.
So continue to submit your questions via the text box. Okay. I believe I have control. There we go. So I mean, I think really, at the end of the day, we think about ourselves in Keynote and in my practice as technical people, performance people. But really, what we’re trying to do is help our customers get their customers to have a great experience. And in e-commerce, that’s even more true. We want to show a site to the visitor where that content, that experience is just pleasant regardless of what device, whether that be tablet, smartphone, or desktop. And that’s much easier back in the old day.
In the early days of the internet, we had to struggle with maybe different browsers. But we really had a desktop form factor or even a laptop form factor where the screens did get bigger over time. And that was great. And most people sort of either scaled nicely or the screens were large enough that it didn’t really matter. I mean, everybody was sort of serving a similar size resolution site. And that’s really changed. I mean, I think that’s – the advent of the smartphone changes a lot of things, not just this topic, but a lot of kinds of big questions in our society and our culture.
But particularly for technical people, it’s like how do I build a site that is pleasant on both a big screen and on a desktop because people still use desktops quite a lot, and then also on a handheld device, and then the tablet sort of fits in between, or more people are staying more in line with the desktop. Do I build two completely separate versions, three separate versions? Or do I build a version that sort of adapts? And that’s really the promise of responsive design. This is an interesting fact. So kind of juxtaposing to Bill’s great data is that mobile is still, for a lot of sites, an afterthought.
And so as much as we’re going mobile as a society, I think all of us use mobile devices, 60 percent as of 2012, it’s a little dated, right, of the top 100 e-tailers, only 60 percent had mobile sites. So 40 percent did not. And on many of these sites, and this is true, actually, on sites even as of today, only a part of the site is optimized for mobile. So as you go through the maybe home page, search and product pages, maybe that’s mobile. And then you go to check out, and you’re actually pushed to a non-optimized site. And so there’s a need I think just to begin at the beginning, which is to say we have to make mobile a priority.
We have to make sure that mobile is offering a rich experience. And then to do that, there are really some cultural things that have to change. One of those things is, I think Bill said it very well in the beginning, was that mobile used to be this afterthought. It used to be sort of this separate little skunk works project. And so that meant either outsource development or limited development, limited operational monitoring, not a lot of internal expertise or best practices that were being built up. And that hasn’t really shifted tremendously, even though mobile usage, mobile revenue, mobile commerce have shifted.
And so I think there’s a – before we even talk about the technical challenges, there’s a cultural challenge in organizations where we really need to begin to treat our mobile platforms, our mobile experiences, our mobile development teams and operational teams as integrated and as fully functional teams so they’re no longer kind of separated in this closet. But they’re actually part of the core business because mobile is key. And I don’t think you can succeed as an e-commerce site if you’re not taking mobile seriously. So this is just some statistics in addition to Bill’s great data that supports that.
I mean, mobile shouldn’t be an afterthought, right? I mean, Amazon has 29 percent of those visitors that only use mobile devices. And I’m actually one of them. It’s sometimes easier just to order right there when you’re thinking about it. And Target as well, 43 percent of their visitors only use mobile devices. And so if you’re not doing a good job of optimizing mobile in a case like this, you’re missing a massive part of the market. You’re missing a huge business opportunity, revenue opportunity, conversion opportunity. So there are kind of two schools of thought in terms of how you build a mobile site.
And this is more conceptual than down at the technical details. But one idea is this graceful degradation, which is “give them everything.” And then build for the best possible scenario, best connection, assume everybody has LT4G. I can’t tell you the number of customers that I hear tell me that that everyone has 4G. And I’m thinking have you ever actually used a mobile phone out in the real world? Build for that. Build for the highest resolution retina display. Build for maybe even a desktop display, the biggest resolution. Build for the fact that there’s never any internet issues, etc., etc. And then just hope that this will sort of work and accommodate around the shortcomings of any device.
The other approach, which I think, clearly, you can probably tell based on my comments is a bit better, it’s progressive enhancement, which is really that you design the best possible experience for the most basic devices or for the lowest common denominator, obviously within reason. I mean, so you can’t take this and say “well, design your mobile site for a flip phone.” OK. Well, it doesn’t probably work.
But keep in mind that people do have older phones, smaller screens, that there are real issues with cell connectivity in the US and worldwide, that there’s tower congestion, that there’s weather-based congestion for towers, and then gradually work up from that. So enhance the user experience for those sites, devices, screen resolutions that have greater capabilities and fewer constraints. So I think it’s a little bit challenging because if you talk to marketing folks, or you talk to folks who are in design agencies, they like to start with the top one, right? They like to show the most immersive, highest resolution, most amazing site, and that’s great for sort of selling the concept.
But in terms of implementation, we have to really take that concept and translate it into the real world. And in the real world, there are lots of challenges. There are lots of variables. And people don’t have the best possible situation all the time. So what is a responsive website? You know, responsive design is really a skill set. It’s an approach aimed at creating an optimal user experience across multiple devices and screen sizes. And it’s something that a lot of folks are looking at, a lot of folks are using, or permutations of responsive design are being used. Ideally, a responsive design site requires a minimum of scrolling, resizing, or panning.
So it’s adapting, or it’s perfectly kind of formatted for the screen size. There’s no need to have a separate desktop and mobile site. It’s one site. And then from a code base and a cost perspective, you can maintain a single version of the code base on the site. That code base might be actually more complex. But at least it’s a single version, single set of infrastructure, servers, etc. And here’s an example. So this is a site in the UK. They’re selling denim, which I don’t know if you’d quite notice that by looking at the site. It’s a very cool kind of design. But what we’re seeing here going from left to right is desktop, tablet, and smartphone.
And you can see that desktop and tablet look very similar. There are some differences I think in terms of the pull-down menu at the top probably taking advantage of the touch capabilities of the tablet. But then as you go to smartphone, it’s quite different. But the functionality of the site is basically the same. And they’ve done a good job in terms of providing these three screens, a consistent look and feel, and this is an example of a responsive site. And as I said, what are the benefits? I’ve kind of mentioned some of these. But there’s only one URL. There’s not an M dot, a T dot, though I don’t see many people doing tablet sites separately.
But search engines only need to index one URL. You can kind of track better both for social media, analytics, and you can innovate a little bit faster. You have a common code base operationally, I think. I didn’t call that out here. But there are operational benefits in terms of cost of management and server structure, etc. And so how do we do it? Well, most of you probably know how responsive design is done. But you’re using flexible grids. You’re using flexible images. Some of that is vector images. You can use HTML5, which has a lot of features and functions that work well with the responsive design.
You can do CSS tricks. And really, all of it is about adapting very nicely to the resolution of the screen to the width and size of the screen. So up to that point, you would say hey, sign me up, right? I want to make my site responsive. But is there a downside? And I think yes. I mean, one of those downsides is that performance can be a big issue, particularly on the smartphone, in the smartphone resolution. We all expect pages to load very quickly. And I think I’ve been doing this at Keynote, I almost don’t want to say how long I’ve been doing it, but about 14 years. And I remember the days of 8-second desktop load times.
And we started thinking about how that’s the goal. And then I remember dialup. Very few people remember that. And we were always sort of saying, okay, things are consistently – the expectations are consistently moving downward. People want a faster and faster experience. And I think that’s definitely true in the mobile space as well. So for web pages, people want 2 or less seconds. People are abandoning sites that take more than 3 seconds to load. You know, 80 percent of shoppers who are dissatisfied with site performance are unlikely to return. That’s a big deal.
We actually did some research recently in the cruise area, which is kind of analogous to e-commerce. They’re actually selling cruise bookings online. And the data about this was really surprising. We asked people, how often do you abandon sites when there’s poor performance? And it was quite high. It was like 15 percent said always, 30 percent said sometimes. And performance is a big part of the user experience. And I think sometimes, it’s been relegated to the IT guys who are down in the dungeon who no one talks to. And the business people and the marketing people, they’re very focused on analytics and on UX and about brand and about conversion.
And I think that’s actually been a very big negative in our industry. And the sites that, to me, get it right actually integrate all of those pieces together. That’s where business and marketing people are able to kind of say performance is a key piece of the user experience. If you don’t have a site that performs well or has high levels of errors, which is another factor of performance, you’re not going to have people convert. You’re not going to achieve that business outcome. And so I think we do a lot in our speaking and coaching with executives to talk about how to integrate performance into the overall user experience sort of dashboards.
But it is something that really makes a big difference. And so we need really fast mobile page loads. I mean, I remember in mobile even when we had 2G or early 3G. People were saying a good page load is 8, 10, 12 seconds. But now, with LTE, we’re talking about 2, 3, 4 seconds is really what’s acceptable. And so the user expectation of performance is probably moving faster than most sites are able to keep up with. And part of that is because either they have their head in the sand, they don’t actually know how their site performs because they’re not using a service like Keynote, or because they’ve said well, we want to give them such an amazing experience that they’ll wait.
And I don’t always think that’s true. And Bill had some data about this about any sort of delay and its effect on conversion. And so the bottom line is that page performance affects abandonment, loyalty, and revenue. And so why do we have issues with responsive design? I mean, I think on every site that’s really built with responsive design, most sites load all the content that a user with the largest displays can use. And then they sort of scale that back to the small screen. So you can sort of think about it as if you were sort of moving let’s say from one apartment to the other.
And what you really wanted actually was not all of your stuff but just your stereo. And so what happened is, okay, I’m going to send the moving truck up. And instead of just getting my stereo, they grab everything. They load it all up. They go across town. They unload it. And then finally, they get my stereo. Well, not very efficient, right? I mean, you don’t want to take everything that you don’t need and then shove it in this moving truck and then just to get one thing. And that’s effectively what we’re doing here, right? We’re taking all the content for all customers, all screen sizes, and then just displaying for my screen. Very inefficient.
And you can imagine that if what really drives performance is how much stuff is being sent back and forth in that moving truck or, as we like to call it, over that network, then that can actually be a big issue. And so for example, 1 or 2 megabyte home page with 50, 60, 70, 80, 100 assets might be totally reasonable on a desktop but will never work very well even over the best 4G LTE connection for a smartphone. And this is the other thing I think most people don’t understand about mobile. And it kind of goes back to the old days where you would have developers testing website performance on corporate 100-megabit connections inside the network.
And they would say oh, this is really fast. And then they would launch the site. And their managers and their business owners would complain, man, it’s really slow from my home, or it’s really slow from the Wi-Fi café or whatever. And it’s like yeah, no kidding. You can’t test your website on the best possible right-next-to-the-server network. And I think it’s similar for mobile. It’s actually much worse because, for mobile, the variables that affect cell performance are massive. And I kind of mentioned some of those earlier in my talk. But it’s worth sort of going over them again. It’s about distance from tower. It’s about tower congestion.
It’s about weather that actually affects the signal. It’s about the tower back haul network and how well they’re connected. It’s obviously about your phone capabilities. And believe it or not, not everybody has LTE capabilities either in their phone or in their neighborhoods. And so there’s this huge variation of latency. All of that affects latency, right? How long does it take to go from my phone to the tower onto the internet to the e-commerce site and back? And there’s a lot of things that affect latency and much more in mobile. And so there’s sort of this fallacy of oh, it works on LTE right next to my server.
Or it works on LTE in this – or on Wi-Fi even on my phone. It doesn’t mean it’s necessarily going to work very well when the connection degrades. There are some other issues with responsive design. For sites that do ad display, and, of course, lots of sites do that, ad brokers sometimes are struggling with displaying ad content that actually is fluid and instead is more fixed. And therefore, it’s going to look weird when you sort of are moving things around. And then the development cycle. I just want to mention this, but there are some cost savings in hosting a single set of code and infrastructure operationally.
But for developers, this might – it definitely probably means more complexity. So because you’re having to test, does it work on all of these screen resolutions? Is the code flexible? There’s more complexity in that code probably, which can be challenging. So let’s look at some real data because we’re a data-driven company. We’re an analytics company. We don’t want to just talk about our opinion. Though, as you can tell, I am happy to do that. But let’s actually look at real data. So in late – in the winter of 2014, I think that’s actually 2013, but we conducted a study where we looked at 12 sites, responsive websites, and this was in partnership with Internet Retailer.
Oh, yes, it was early 2014. And we looked at 10 in the US and 2 in the UK. And the idea was let’s measure them using desktops, smartphone, and tablet. Desktop over a typical high-speed connection like you’d have at home, smartphone over 3G/4G networks because we wanted to see best case/worst case, and then tablet was also over Wi-Fi connectivity. So let’s look at how did they actually fare in that study. And so what’s interesting is of these 12 responsive sites, none of them met the performance target for the smartphone experience.
And so this goes to Bill’s point earlier, which is there’s a big problem that no one is talking about with responsive. And so we recommend, typically in the UK with the connections we were using, 3 seconds. And we only had one site, the one I mentioned earlier, selling the denim that was able to get close to that, and that was 5.7 seconds. So they were almost double what we would recommend. And in the US, we were recommending 4.5 seconds. And you might say why are you using different metrics? And the reason is the connections were slightly different. And Sweet Water was the only US site that was faster than 10 seconds at 8.7 seconds. So it was almost double what we would recommend.
And so if the best sites are double, then, clearly, you have some challenges. Digging a little bit more into this, and this is where you really clearly can see the difference between how the site works on the desktop and tablet and then what happens over a 3G network or a 4G network. So you can see the averages. So the desktop, 3 seconds. Not great, but not bad. Fastest site was 1 second, which is actually quite phenomenal. And then the slowest site was 4.6 seconds. So most of those folks are in the range. We’d recommend something like in the 2 seconds for the best sites and so pretty close. Tablet, similar.
What we do find is we’re using kind of an optimized tablet immolator. I do find in the real world that typically, tablets are a little slower, and that’s because they have less processing power typically than a desktop. And so from a network performance, the responsive design sites perform very similarly on tablets. So excellent job there. But now, as we have a smartphone, wow, 18 seconds for a response time for the smartphone. And the fastest site is 5 seconds. The slowest site, which is crazy, is 46 seconds. And so that’s clearly not going to fly for real customers out there. And so yeah, 18 seconds is the average.
Even the best performance responsive design sites fail to meet our target. And the takeaway here is you need to really optimize for smartphone if you’re going to use this technique. The other thing, and this was an interesting one, and this really speaks to the value of ongoing measurement. And as I said earlier, investing in mobile as you would invest in any other channel. One of the sites of the 12, we couldn’t even render the home page on one carrier. And you might say well, how is that possible. So on other carriers, it rendered. But on this one particular mobile carrier, and these are all the major carriers.
And the reason is because a lot of the carriers still are doing things to try to optimize or proxy the sites themselves. And this really comes out of the legacy of 2G and slow 3G where sites were so bad that they couldn’t really be displayed. And so the carrier said we’ll step in and kind of create this behind-the-scenes optimization without even getting permission, of course. They kind of just do it on the fly. And in some cases, that optimization can really have bad results. We’ve seen this many other times where they’ll try to combine Java scripts automatically or change compression, and it will actually break the site.
And of course, they don’t know that because they’re just doing this for all sites or all traffic that’s coming through. And the site will be broken for potentially 30, 40, 50 percent of the market, if it’s a big provider. So this is just kind of a side note about why you really need to measure over real devices, real carrier networks, so that you really get an understanding of is my site actually working, which is kind of the basics for performance is just working on these carrier networks.
So what is the big issue? What is actually driving why smartphones average 18 seconds? It’s really about load. We recommend 20 or fewer requests, 200K in page load and in page size, and none of the sites met that. The two fastest sites were the only two that were below 300K and 30 elements. So this is shifting. As we see more LTE penetration, I think you’ll see us kind of lighten up these recommendations. But they’re never going to be the same as desktop because of the issues that I mentioned with carrier networks. So let’s look at some data. We look at how these sites actually compare kind of cross-correlating size and response. And you can see that there’s a really strong correlation.
I mean, almost every case, the bigger the page, the slower the page. That’s actually not the case on desktop sites. Desktop sites are more driven by number of requests. But for smartphones, because we’re on a higher latency/lower bandwidth connection, size does matter. And so it’s important to sort of optimize, and we’ll talk a little bit about how you do that. And then element count also matters. Element count, kind of for the layperson, is number of requests. And it’s really how many requests are leaving my phone, as I said, going to the carrier network over this magical air connection, going to the back haul internet, and then going to the site and back.
And we kind of don’t even think about that. But when you think about how long that could be in terms of physical distance and how many devices are being touched, it doesn’t make sense that as you add more requests, things are more delayed, right? And so this site L, which I can’t tell you who this is, had almost 250 requests on their home page. And so clearly, that is not going to work. And the response time was 30 seconds. You cannot send 100 and 200 requests over a cell connection, through the internet, and back and expect good performance. So how do we improve? What’s the takeaways?
Are we just sort of left with things are lost, and let’s move to another technology? I don’t think so. I think all technologies, and I’ve been around long enough, whether that was Web 2.0 technology, Ajax, Flex, Flash, all technologies and approaches are sort of agnostic. Really, it’s about how you implement them and the culture that you create in your company around monitoring and improvement. So I don’t think responsive design as a technology is good or bad. I think it’s all about how you do it. And so let’s talk about how we can do that. Well, here is some basic stuff. But it’s really the basic stuff that makes a difference.
No. 1 is reduce the number of requests. Well, how do I do that? I combine Java script. I combine CSS. I sprite images. I make sure that I don’t have a lot of third parties. This kind of goes to as few domains as possible. I don’t want to have on my smartphone site, I was just meeting with a client right before this call, they had on their smartphone site something like 60 requests. Of those 60, 30 were third-party analytics calls, double click, social calls. We can’t do that on smartphone. It just doesn’t make sense. So when you have business owners tell you we have to have social media and smartphone, OK, but then maybe we don’t need to have 20 ad tracking calls and 3 different analytics trackers, etc.
We have to limit the number of domains because each domain actually requires additional overhead without going into the technical details. But it requires new DNS and new requests. This is a big one, but load content that’s most visually impactful first. I cannot tell you the number of customers I talk to when we look at their page load, that big banner, visual image, hero image that everybody – you know, and the marketing team spent so much time and effort on, it’s loaded last. So there’s all this other stuff that’s loaded first. There are tags that are loaded first. There’s Java script that no user cares about because they don’t know what that even means.
And then finally, at the very end, 60 requests in this hero image, this big image. That’s ridiculous. I mean, it does not make intuitive sense whether you’re technical or not to delay what is most important to the user visually to the last moment. That’s crazy. Remove re-directions, try to paralyze downloads, how do you increase paralyzation using asynchronous tags, getting asynchronous tags from your venders, etc. Manage third-party calls. I talked about this. I always say that the best practices for third-party tag management is really about a process and a culture. So every quarter, audit your third-party tag usage on all your key pages.
What I mean by audit is look at how many calls we have from double-click, how many calls we have from high perceptions, how many calls we have from Facebook. Do the business owners who wanted that on the page a year ago still need that? I can’t tell you the number of customers I talked to where they have campaign tags, media tracking, media by tags on their pages for campaigns and events that were a year ago. So you’re effectively kind of leaving this junk around in your yard that’s no one has bothered to go out and actually use a broom and sweep up, and you’re hurting performance.
And so there’s a whole process about just auditing that has nothing to do with technology and can be driven by a marketing person to make sure that you’re only using those tags and analytics that you actually need. Look at cash control, and make sure you leverage far future expire headers, limit SSL. I don’t know why, but I see people doing crazy things like loading some SSL content on their home page. I only use SSL in E commerce when I get to check out. From the cart to check out, that’s when SSL should be enabled. Using it before that does not provide people a sense of security and only usually screws up performance.
Optimize images, that’s a big one. I worked with a customer who was building a Super Bowl site. So pretty high priority. It was linked to a Super Bowl media campaign that was going to run on the day. And they had built a responsive site. And the images that they had chosen, and this was outsourced to a marketing company, were 300, 400, 500K images, which will not even perform on a desktop site, and they were going to shove that on the smartphone site. It just won’t work. So for images on smartphone, they should be 50K or less at most. Now, tablet and retina display, there’s some debate.
It may be the one image that’s really the hero image maybe could be bigger than that. But generally, you do not want to shove 100K or 200K images over a – even over a desktop, but certainly not over smartphone. And then use persistent connections, which is kind of the basic idea. So there’s another approach. And that is to sort of mix a bit of responsive with a server side detection. And so this is another thing to think about. And this is basically instead of sending all content to all users and then sizing it, it’s really about identifying who that user is ahead of time when they first come into the site.
Usually, it’s through the user agent string because that identifies the browser and some of the device information. And then sending just a packet of content for them. And so it’s, again, the difference between sending a big image and then scaling it and actually just sending the right image the first time. So as a performance person, I love this approach. There’s some complexity here. There are some reasons people don’t do this. But I think if you can do this, it’s actually a pretty slick approach. So, again, responsive web design might be the future. And I think we said that about every other technology that’s come before us, so I’m sure it will be part of the future.
But we have to keep in mind that it’s really important to look at smartphone performance. You cannot just say it works or it works in my office or it works on Wi-Fi, or some developer that I’ve outsourced told me it works. You actually have to measure that it works on the smartphone, work with a company like Keynote or other folks out there, set up real measurements over real carriers throughout the US or throughout the globe, and make sure that the smartphone performance is acceptable. And again, acceptable to us is 3 to 4 to 5 seconds at most per page. Mobile performance needs to be baked in from the beginning.
It’s much harder to reverse engineer performance. That goes for all performance but mobile particularly. And then best practices. Work with your developers if those are in house or outsourced. Work with your hosting or marketing providers if they’re the ones creating the content to have a standard set of best practices. I think people fear best practices because they think it will be limiting that, oh, if we set up these guidelines for how many elements, image size, number of Java scripts, tags. What if the business wants something that doesn’t fit within that? Well, of course, we’re humans. Guidelines are guidelines.
No one is going to get fired over them. But let’s start with a common language and a common culture using a best practice document or process so that then we can flex, and we can make decisions based on good data. So we can go to the business owner and say oh, do you really need that 600K hero image? That’s outside of our best practice. Tell me why you need that. Is there another approach to optimizing that? And so I think there’s a lot that can be done process and culturally that actually solves many of these issues. So I guess I think we left at least 15 minutes for questions, 10 or 15 minutes.
And hopefully, that was useful. As always, if you have questions that you don’t feel comfortable putting here on the webinar and you want to ask directly, you can reach out to Bill or myself.
Excellent. Well, thank you very much, Ben. We’re going to move on to questions now. We’ve received a number of questions from the audience. And the first question is we use a content delivery network, a CDN. Shouldn’t that take care of my site’s performance?
Well, probably according to the CDN salesperson it should. But yeah, I mean, I think the challenge is – for those of you who don’t know what CDNs are, and that’s okay if you don’t, they’re effectively content delivery networks. And what they’re doing is they’re putting content closer to the end user. And so in the web environment, in the desktop environment, they actually have a really big effect on performance because the distance between my desktop and where they can kind of sit their content is very small. So they have a big effect. They don’t solve all problems, and there are lots of sites that use CDNs that have bad performance.
But in the mobile space, and particularly the smartphone space, it’s even more challenging because, again, if you think about the fact that I have to go from my phone through the air magically, I like to think of it as magic, I know it’s not, to the tower, down the tower to the internet, the CDN cannot overcome the phone, air, tower issue. And so they can do some things. And if you’re talking about very sophisticated CDNs, they can do mobile optimization on the fly, which is still kind of a new concept. But in terms of a traditional CDN solution, the answer is no. They can only do so much, and they can do much less in mobile than they can do in desktop.
And you still have to follow best practices to leverage – to make a site faster, even if you have a CDN in place.
Okay. Our next question is what is the best way to run AB and multi variant tests when using responsive design?
So I think responsive design is not really different in that way, right? I mean, I think if you think about tests and target solutions, whether those are from Adobe or somebody else, they work very well. They leverage Java script. They’re kind of commonplace on the desktop. I don’t think there’s really a need to sort of approach that differently on smartphone. I will say, as much as I like the idea of the tests and target or AB testing sort of methodology, one of the challenges of that sometimes is that it actually requires rewriting the page on the fly. And to do that, there’s usually a third party like M Box or Adobe integrated very high on the page.
And if they have performance issues, they can actually slow down the entire AB experience, whether or not you get the A version or the B version, it will still be slowed down. So one of the things that I would recommend is if you’re thinking about using AB testing, particularly on a responsive site, and we know smartphone performance is an issue, that you measure that first before you even implement it in QA or something and make sure that even in the normal scenario that that rewriting and third-party injection is not actually causing problems.
All right. Our next question is why invest in responsive web design if it can have such a large impact on performance and thus conversion rates?
Well, I think it’s really because it’s costly and hard to – and I think, Bill, you mentioned that actually a conversion rate can go up when you have responsive, right? And I think the reason for that is in the old days when people were designing M dot sites, and they were doing it from the ground up completely disconnected from the desktop experience, you don’t get the same kind of content. You don’t get the same kind of branding across all three screens. You don’t get the same sort of integration across all three screens, functionality. And so there are lots of reasons from a business marketing perspective why it makes sense.
I think there’s a pretty strong case there, to be honest. I think the benefits probably outweigh the negatives if you do it right. And so just to be clear, I’m not saying responsive design is bad. I’m saying it needs to be done like any other technology with the right level of testing, best practices, and monitoring so that you leverage the best of the technology, give the customers the best experience without having any of those negatives that we talked about.
And I’ve written about quite a few retailers that have gone responsive very successfully, and they do it right. They’re able to maintain a fairly good page loading time. And it doesn’t negatively impact their conversion rate. In fact, it positively impacts their conversion rate. So like you say, when it’s done right, there’s a great reason to invest in it.
And I think there’s a lot to be said about consistent UI and branding and all those other things. And yeah, so I think you can’t – this goes to my point earlier, not to go on too much, but we think about all these things as siloed. Oh, performance is the IT guys’ or the CIO’s responsibility. And usability and branding is the CMO’s responsibility, and they never talk to each other. And I think that’s changing. And I think the more that that changes, the more that you sort of will see these really great sites emerge where they’re looking at how does branding, usability, conversion, business outcome correlate to performance.
And obviously, performance is not the only metric. There are lots of other metrics about engagement and about user and MPS and whatever. But as you start to look at those as a single thing, which is how do we delight our users and drive business outcomes, things start to change. The more siloed, the more disconnected they are, they have dysfunctional sites that have 30-second performance times, I think.
So the next question is very interesting, and this plays to – this question plays to the evolution of responsive design. As we see today, there are a lot of hybrid formats of responsive design where some are mobile-specific to tablets and smartphones and such. So this attendee asks my company designed our website without a responsive design. Is it possible to improve my site’s mobile compatibility without having to completely start over? Can we somehow leverage responsive techniques to accommodate for all the different devices?
Yeah. So a little bit outside of my direct wheelhouse, but I would say yes. I mean, if you think about responsive as just a high-level concept, it’s basically about the right content adapted to the right screen size. And so you don’t have to go wholesale into a single site code base and a single solution. You can actually say well, let’s take the best and learn from what responsive does well, which is the right content for the right screen size. And yet keeping the branding consistent. You could do that and actually have three separate code bases. So that’s not the greatest solution. But you could do that in three separate code bases with an M dot and a T dot and a WWW.
You could also do what I mentioned, which is leverage more server-side detection. And there’s even some CDNs that do that, because somebody mentioned a CDN, where you’re looking at what the device is coming in, and then you’re serving content that’s more tailored for that device. That’s not responsive per se. But the result is very similar. So I think there are lots of approaches where you can learn from the best without having to say oh, we have to have one code base, one URL. I don’t think we’re there yet, and I think you can leverage best practices and still create a really good site, even if it’s not truly responsive.
Here’s a good question about one of the solutions to help quicken websites, and the question is you have an article on your website regarding Wal-Mart using URI to deliver static content. Could you speak a little to what URI is and how to use it?
Yeah. That’s an excellent question. Was that a seeded question or was that a real question?
No, that was a real question.
Excellent question. So I wish I could think of the example, and maybe if you ping me afterwards directly, I will – in fact, I will if you do. But there’s a retailer in the UK, and we were doing some work doing a competitive study. And we were comparing the e-commerce flow, which is when we do competitive studies, we typically look at home page, search, category filter, product, cart, and check out. And I was looking at the analysis or the data that was coming back, and I was like this doesn’t make any sense. Everyone else’s home page had 50 elements, 60 elements, 100 elements.
I think the average on the internet desktop site is probably 110 or something. And this site had four. And I looked at the site visually, so I bring it up on my browser. It’s super rich. Visually, you could not tell. It doesn’t look like Google. Google we can tell only has four images or four requests. This site had four or five requests visually super, super interesting. And what they were doing is data URIs. The other kind of technique is CSS sprites. But effectively, what you’re doing with data URIs is you’re basing coding content. So you’re taking all of your images and all your files, and you’re kind of encoding it and sending it in one request.
Another approach, which is more commonly used, is, as I said, CSS sprites where you take all your images and actually put them in a sprite file and then place them with CSS code. But you can imagine, in either case, you could take 50, 60, 70 images, put them in a single file, and then, obviously, there are some limitations to file sizes and how far you want to go here, and that one file is then fetched, which is very fast typically. Much faster effects for one file than 50. And then it’s kind of unpacked and placed on the site.
And so this retailer, and it’s one of the UK grocery shops, and I’ll have to remember it, is an example I use over and over again because, visually, they create an amazingly on parity with their competitor’s site or page, but they’re using three or four requests. And in their case, they use data URIs. I see more people using CSS sprites, which is another, again, technique of that than I do data URIs. But either is useful. And if you just go out and Google data URIs, you’ll kind of get more information on how you could actually do that on your site.
Okay. Here’s a good question. Why do in-house versus contracting a business like Branding Brand?
Well, that’s a loaded question. I mean, I think it depends. So when you say contracting, I think of it as there are multiple levels of outsourcing. One if I’ve outsourced my marketing content, so I use a design agency, and they actually do development as well. Or maybe I just outsourced my development. Or I use a total e-commerce. I don’t know Branding Brand. I should, but as much as I – like GSI, EBay, e-commerce, or I kind of outsource everything. And the platform, the hosting, everything. I mean, I think this is not a new debate. This is sort of back in the day client/server debate, in source/outsource.
People were selling data centers, and they were buying data centers. They were giving data centers to IBM, and then they were taking them back. I mean, it’s really, to me, a cultural question. If you don’t have the expertise internally, and financially it makes more sense, then outsource. You could leverage probably best practices. You can leverage some execution and scale that you might not be able to have, especially if you’re a small retailer. But I think if you have the ability to, and you have the revenue from that channel, and this is just not Keynote. What’s the disclaimer? That the views of the speaker don’t reflect the company.
This is my opinion having been around a long time: I think doing it yourself is better. I mean, I think there is a value to building up a culture or an expertise, a sort of Marketing Department and a Development Department that you can use internally. But that’s just my personal opinion. I have sites that I work with that are fully outsourced that are awesome, and they perform well, and they delight their customers. And I have sites that are fully insourced that perform well. So I don’t think there’s a clear, at least not from my perspective, winner. But personally, I think you can probably be a little bit more nimble, a little bit more flexible internally.
So we have time for two more questions. The first question is, and they’re talking about the study. I believe they’re referring to the Internet Retailer Keynote study that we did this year. Did you study the effect of actual browser performance, i.e., some mobile browsers render certain content more efficiently than others. So can you factor out that effect versus network speed effect of downloading of bloated sites?
Good question. I mean, I think to cut right to the answer, browser performance on mobile – so the difference between browsers has such a smaller effect than the network that I’m not clear that that would need to be done. I don’t know all the details of that study. It was done by my team. I don’t think we use different browsers. So I guess my answer is no, we didn’t. And it probably doesn’t matter that much. That being said, any good QA testing shop, which is not what Keynote does, should be using different devices, different browsers. That does matter, right? I would say more than the browser, device CPU, memory capability, antenna, I mean, there are a lot of reasons to use real devices for testing.
I think if you’re in the ongoing monitoring space, and you’ve already launched an M dot site or a responsive site, you probably could choose one or two browsers. And the difference is not going to be that big, and then maybe scale back even to one because you have to kind of balance cost versus value there. So yeah, I mean, I think doing that testing in the QA development cycle makes sense. But once you move into a launch site, maybe, but I don’t think you’ll find that there are that many differences in terms of browser performance, especially when you compare it to actual device configuration performance or device CPU or versions or OS, things like that.
So Ben, we only have about a minute left. I saved kind of the ultimate question for last. All of the features and functions on my desktop site exist for a reason. To convert shoppers into buyers. If I start hacking away at what appears on a smartphone version of the site, customers won’t have all the tools they need to make buying decisions. So how do I balance features and performance?
Yeah. So I mean, I think it’s a great question. It’s a question we get regardless of device, which is always that there’s a business requirement and that there’s – and then on the other side, there’s a performance requirement. And I think that’s where performance gets a bad rap because people start to think the only way to have a high performing site is to limit user interactivity, features, tools, visual impact. And the reality is that’s just not true. So you can build a highly performing and yet visually interesting, satisfying, converting, driving business outcome site, that’s a horrible sentence I know, and those two things are not mutually exclusive at all.
And in fact, I would say the work we do every day with hundreds and hundreds of customers says that’s not the case. Most customers can take a bloated site and make it a very optimized site without changing any of the features and functionality. And if people doubt that, then I would say reach out to me, and we’ll see how we can do that on your site.
Excellent. Well, I would like to thank everyone who attended the webinar today.
Duration: 59 minutes