Google made an interesting announcement at Google I/O in early May 2019: they now prefer responsive sites more than mobile subdomains, and dynamic serving.
In this episode of the popular Here’s Why digital marketing video series, Google’s Martin Splitt joins Eric Enge and explains why Google now prefers responsive sites. Splitt shares some key metrics to consider when developing mobile sites.
Don’t miss a single episode of Here’s Why. Click the subscribe button below to be notified via email each time a new video is published.
Resources
Transcript
Eric Enge: Hey, everybody. I’m Eric Enge, and today I’m pleased to let you know that Martin Splitt is joining me from Google, where he’s a webmaster trends analyst based out of the Zurich office. Say hi, Martin.
Martin Splitt: Hello, everyone. Very good to be here. Thank you very much for having me, Eric.
Eric Enge: Absolutely. At Google I/O, you said something that was really interesting, that seemed different from what we’ve heard from Google before. Historically, there’s definitely been a sense that your recommendation is that people build responsive sites rather than mobile subdomains, and presumably also dynamic serving. But at Google I/O, something that you said really started to sound like you’re pushing the recommendation to go responsive a little more formally, and forcefully. Did I hear that right, and why?
Martin Splitt: Yes, we did say something along those lines. I wouldn’t say that the recommendation necessarily changes what we have been recommending with RWD. But as the last year went by, we noticed that many, many people are having issues or facing challenges or struggling with getting the M-Dot URLs right. It’s another moving target. So many things can go wrong there. You can canonicalize it incorrectly, you can forget your structured data in one of the two sites, you can forget to link your M site, you can get your hreflang wrong.
There’s just so much that can go wrong, and then you have to deal with two different moving targets. It seems to me that it is not just recommended to switch to responsive sites, but also that it’s probably a lot easier. We just wanted to highlight that, before you get yourself into hot water and struggle with the M-Dot domain. If you have one that works, okay. But before you do that, and if you want to become more mobile friendly, then probably consider investing in responsive web design.
Eric Enge: If you have it right, then maybe there isn’t a great deal of urgency to switch. But my observation is that maybe even if your mobile subdomain is working really well now, it’s just a little harder to maintain too, right?
Martin Splitt: It is.
Eric Enge: So, would you actually recommend that people who have mobile subdomains or even dynamic serving setups actually invest in converting to responsive?
Martin Splitt: If you have a working setup and don’t have any pain points, definitely do not change your running system. But if you are struck by the fact that there is an additional maintenance overhead, or you see that it’s like a hit or miss for you, then I would say it’s a good long-term investment to do responsive.
Eric Enge: Got you. There’s just one other mobile topic I want to bring up, which wasn’t really covered in Google I/O: the whole issue of speed. I’m sure that was covered in Google I/O, but I’m not pulling something specific out of it. Talk a little bit about the importance of speed in the mobile environment.
Martin Splitt: Mobile is usually using networks that have a higher latency, or are a lot more flaky than stable Wi-Fi connections or stable cable connections, so speed is a much, much more important factor. Oftentimes, we see that developers are not testing it on real-world conditions. It is sometimes just really hard to test it on real-world conditions on mobile phones. Mobile phones happen to have a different CPU architecture; not all of them, but some of them, and we do see that the mobile performance especially in graphics performance, as well as CPU performance, is just not the same as on desktop.
We think it is important to emphasize that you should make your website as fast as possible, especially because mobile would suffer if you don’t. When we say fast, then the question is, what do we mean by fast? Speaking of that, you don’t just want to make sure that your server delivers the bytes really quickly over network because basically, the problem might start once the bytes have left your server, and it’s the transmission path or it’s on the device that is slow to parse the data as it comes in.
You probably want to also look into things like time to interactive. How long does the phone hang until I can actually start interacting with the page? When do I actually start to see the content? If you’re using client-side rendering, for example, the problem is that your content is bound by the entire JavaScript having to arrive and be parsed, or is cycling the CPU. If it’s compressed, which it should be—that’s a very important factor—your compressed JavaScript needs to be uncompressed, which is usually pretty fast. But then it needs to be parsed. Is this actually JavaScript? Is this valid JavaScript? And it needs to be executed, and then it starts generating the content, which is again putting additional work on the CPU, which will also make the phone respond and make a website much, much later to input. So that’s not a good experience. You should definitely look into making your site faster. That’s generally a really, really good investment.
Eric Enge: For years now, I’ve seen people obsessing about things like time to first byte. What you said was time to first interactive—that seems a lot more interesting to me and also something like time to first meaningful paint, so the user gets some level of confirmation that things are happening. Could those be more important metrics in your mind?
Martin Splitt: These are definitely more important metrics. I mean, making your first server fast is a very good first step, but it’s not the end of the journey. If your server delivers bytes really fast but it’s just a lot of bytes, then this is going to also cost the user a lot of money. It keeps the radio alive longer, which costs more battery power. These bytes still need to be processed by the CPU. So the more data you’re pushing, the more strain you put on the mobile device, and the longer it takes for the user to be able to interact with your content. And that’s not a good thing.
Eric Enge: Absolutely. One last question on this. From my experience, it seems like one of the biggest things that people mess up all the time related to speed is images: too big, not loading images that are below the fold, stuff like that. That’s one of the most common, if not the most common problem, that we see people doing. What’s your experience with what the most frequent kind of problems are?
Martin Splitt: I think there are two problems. One is the image problem that people are shipping unoptimized images. I have been doing this and I think I still am doing this; I need to fix this on my blog. My blogs, basically, I just upload some random image that’s like, it just happens. Like I can’t be bothered too much but I should, and I’ll do as I say and I’ll fix it probably as soon as I have some vacation, I’ll probably look into that.
You can optimize images a lot. You can use progressive JPEGs; you can use webM; you can detect if webM is supported; you can use responsive images with the picture element. We are supporting that in search as well. You have plenty of opportunity to fix this, but lots of people are just skipping this very important step. The other thing is, instead of just looking at shipping fewer bytes for images, shipping less JavaScript is also a thing that people who are running JavaScript sites should definitely look into.
There is a technique called tree-shaking where you’re removing unused code before you’re shipping that one, and you can split your bundles. So if you bundle up all your JavaScript code for the front-end application, and the different code runs on different pages, you don’t want to ship everything in one go. You want to ship whatever is needed for the current page, and then basically pre-load or pre-cache the bits and pieces for the next page and not just ship it all in one big blob. Because JavaScript bytes are more expensive than image bytes. In image bytes, a 200-kilobyte image is a 200-kilobyte image. That’s fair, but a 200-kilobyte JavaScript causes a lot of CPU load afterwards because it has to be parsed and executed. I would also look into optimizing your JavaScript code.
Eric Enge: Awesome. Thanks so much for joining us today, Martin.
Martin Splitt: It’s been a pleasure, as always. Thank you very much, Eric, for having me.
Don’t miss a single episode of Here’s Why. Click the subscribe button below to be notified via email each time a new video is published.
See all of our Here’s Why Videos | Subscribe to our YouTube Channel
Who does not like responsive sites, or otherwise who does not like the usual pages on the phones 🙂 and here the whole question. In the world, where almost 80% of users use the Internet and telephone, everything is clear. Google is looking for places where there will be the greatest number of users, and currently only phones are such a place – and this will be Google for sure for the next few years. The second issue to UX, or the simplicity of the message !! We like ourselves the most to be clean and transparent around us, as well as to the parties. Haos does not transmit anything but only works the opposite way and rejects it. Pages as an undivided companion of the present years in almost every situation, and the most important thing is to look after this side of the world. RWD is the foundation and the celebration in business and life.