searchmetrics email facebook github gplus instagram linkedin phone rss twitter whatsapp youtube arrow-right chevron-up chevron-down chevron-left chevron-right clock close menu search
1540115401

Google’s Approach to Technical SEO – Lukas Haensch // Pathmonk

Episode Overview: Knowing what technical SEO adjustments to make to increase your ranking is difficult when search engines consistently publish new algorithm updates and SEO itself is always in a state of flux. Join host Ben as he speaks with Pathmonk founder Lukas Haensch to discuss how Google views technical SEO and what reliable technical adjustments you can implement to significantly boost your ranking.

Summary

  • Decreasing page load times is one of the most important SEO technical optimizations to make.
  • Leverage tools like webpagetest.org to test your page speed and Google Think to see industry-specific performance benchmarks to help optimize your website.
  • One quick way to decrease site load time is to run a test on webpagetest.org and click the filmstrip view to see a step-by-step breakdown of how your page is loading and check for JavaScript files. Deferring them can prevent them from impacting critical rendering paths and keep users engaged on your site.

GUESTS & RESOURCES

Ben:                 Welcome to agency month on the Voices of Search podcast. I’m your host Benjamin Shapiro, and this month we’re focusing on understanding and optimizing the relationships SEO agencies have with their in-house SEO partners. Joining us is Lukas Haensch, who is the founder of Pathmonk, which is an AI-driven technology that provides an effortless customer acquisition channel to automatically grow clients from website and social media traffic. Prior to working at Pathmonk, Lukas also works at a company called Google, working in their mobile optimization team. Maybe you’ve heard of it. And today Lukas and I are going to talk about what agencies need to know about how Google views technical SEO.

Ben:                 Okay. On with the show. Here’s my conversation with Lukas Haensch, founder at Pathmonk. Lucas, welcome to the Voices of Search podcast.

Lukas:              Thanks, Ben. Thanks for having me. Pleasure to be here.

Ben:                 Excited to have you here, and excited to not only talk to you because you’re doing some interesting things in conversion rate optimization, but honestly, you’re an ex-Googler and we don’t get to talk to many people that are working at the mothership, being an SEO podcast. Tell us a little bit about you and your background.

Lukas:              Oh yeah, sure. So we’re just normal people, just to get it out the door first. Yeah, sure. So I’ve been with Google for about four years working in various teams, and one of the teams has been also the mobile optimization team and is probably one of the reasons why we were chatting here today. So, I basically spend time in Google working with some of Google’s … It’s funny actually. When I’m saying Google, my Google app goes off here, my assistant. One second. There you go. So basically spent time with Google’s mobile optimization team, which means we would be working together with Google’s larger advertising clients in order to optimize their websites from various angles from mobile websites, in particular, from a UX angle, as well as from a page speed, and performance angle given the different impact that it has on SEO. We’re going to chat about that, and obviously just purely conversions on the site.

Lukas:              Yeah, I’ve basically seen a lot in what goes into conversion rate optimization, what goes into getting more leads from your site, if you’re a lead generation company. And then I moved on to Workday, is another Silicon Valley-based company, as a UX lead designer for one of the products, spent there about a year. And then after all of those learnings and the time there, moved into being co-founder in the Pathmonk, which is into how you are able to qualify and convert more people from your website through artificial intelligence.

Ben:                 So, you’ve had a rich history working in some pretty notable companies. I’ll be honest, the one I care the most about is Google. And specifically, we don’t get an opportunity to talk to people at Google about how they think about SEO. And you were on the mobile team, so technical SEO is something that I specifically want to focus on. Give us the lay of the land, spill the beans. How does Google think about what we should be doing? What are the major ranking factors that matter? Tell us the secret sauce.

Lukas:              Yeah, so I have brought here a paper with all the ranking factors. Just kidding. Obviously, even being in Google there’s various levels of insights that you could have only to certain topics, and my focus within Google has been always on page speed optimization, performance optimization, as it is one of the ranking factors. So unfortunately I cannot come with the whole formula for you guys, but what I can do is I can share how we were thinking internally about page speed, what types of metrics to look at, how we could be measuring this, what is the main things you can be looking at, if you’re an SEO agency, maybe what is a quick check that you can do with the clients that you’re working with to maybe point them to one of the other things that it can be doing on their page to just increase page speed a little bit. So have to slightly disappoint. I don’t have the whole formula, but I would guess there’s actually not that many people in the world who would actually have a whole oversight on all of this.

Ben:                 I’m sure if they did, they wouldn’t be talking to me on this podcast but, boy, would I be grateful. So we all know that page speed is one of the most, if not the most, important ranking factors. And one of the biggest pieces of low hanging fruit when it comes to making drastic performance changes, when we talk about technical SEO, it’s always the first thing that we think about is how quickly are you loading your website to provide relevant content to your consumers from the inside? How does Google think about page speed? And is it really the number one ranking factor that they cared about while you were there?

Lukas:              So, it’s definitely an important factor, right? Is it the number one? I wouldn’t even be able to tell you because I don’t have even that full insights there. What I can tell you-

Ben:                 But yes, yes. Yes it is.

Lukas:              What I can say is that it’s definitely growing in importance. There has been an increasing focus on page speed optimization, and it’s actually, putting the SEO ranking aside a little bit, it is actually a very natural thing to do for Google, right? Because more and more mobile searches are happening. I think the mobile traffic has surpassed the desktop traffic quite a while ago and then basically the next step is to figure out, okay, how do the pages where the visitors land on, what experience do you provide when you do that in mobile? Do you provide an experience that is a blank screen for the next 10 seconds, or do you have a continuously good experience from the different search results into the different pages? So definitely it’s an important factor. Definitely there was a team internally in Google that was just focusing on identifying what can be gaps that Google’s clients are having in terms of page speed optimization, and sort of that’s where my learnings and my history come from, and the perspective on a very high level internally on how you can think about page speed optimization because there’s many ways to think about this.

Lukas:              But what we particularly looked at and focused at was how do you make sure that you serve a first meaningful experience in the fastest way possible, right? How does that above the fold content render the quickest and shows meaningful content? Meaning a hero image, a call to action, a headline, maybe one or two other images, your icons. How long does it take until all of this is actually being displayed on the mobile device? Because there’s tons of metrics that you could be theoretically looking at, right? If you’re looking at page speed optimization, there’s the low time of the page, there’s the time to first byte, there’s the start of the render, there’s the fully loaded. What we were continuously looking at was something called speed index. And speed index, it’s basically a metric that represents how long it takes until the above the fold content of your first visit is being rendered, right? How many milliseconds does it take?

Ben:                 Okay, so that’s an important distinction. While we’re thinking about site speed where you can look at various metrics to understand what your site speed is, from your experience, Google cares first and foremost about what’s going to be above the fold that’s going to load? So if you have heavy pages, you have to prioritize the top of the page to load first and make sure that you’re having that first glance being visible as quick as possible.

Ben:                 This is agency month, and so for the agency partners that are out there or for the in house SEOs that are thinking about how to work with their agencies, when you’re thinking about a site speed audit, it’s something that a lot of agencies are doing. They’re coming in, they’re going to say, “Hey, we’re going to evaluate and audit the technical aspect of your SEO.” What are the metrics that agencies should be thinking about, and what should the in house partners be asking for when it comes to understanding the site speed and the evaluation of their pages?

Lukas:              Yeah, I mean, obviously there is even Google tools where you can get your sort of ranking or your percentage points of how good your page is doing. I can tell you what we’ve been doing internally, even ask the team, talking with people. As I was describing this idea of the page speed index, I think that is a very, very good metric to look at because it describes exactly how long it takes until that first page above the fold is being rendered, and you can leverage tools like webpagetest.org, for example, which it’s not an official Google tool, but it was built actually by the Google cracks that are the super brains on that topic. Basically they were building these tools. It’s not really an official Google tool, but it’s built by Googlers and is heavily informing also internally. So webpagetest.org is a super good tool to run your page through and then checking the page speed index. And that speed index will be something around, it depends, obviously, how fast you’re loading, but it’s in milliseconds so it’s going to tell you a page speed index of around, maybe let’s say 5,000, if your first above the fold content is being loaded in five seconds. So that’s a really, really good place to start. And then from that first train of thought, there is a lot of questions kicking off from there, right, that could be asked.

Ben:                 So obviously there’s the site speed index, which is how long it takes to have that first top of the page load. What are the things that you can do to affect page speed when you’re … I just loaded the martechpod.com, a website that I run for another podcast, and I have a page load time of 5.2 seconds. What can I do to decrease that?

Lukas:              So, you mentioned the page speed index of 5,210 then, I would assume is what you’re seeing?

Ben:                 Mm-hmm (affirmative).

Lukas:              Yes. So there is a lot that you can do about it. I think the very first thing that I can say is how the browser actually deals with the page, right? And if you’re thinking along the lines of how the browser thinks about it, then I think you’re going to be on a very good track from the get go. So on the very, very high level, right? The browser is going through something called a critical rendering path. And the critical rendering path is basically what the browser is going through in order to get the resources that it wants to show, download them, and execute them. Right? And there is basically different steps. I’m just going to keep it high level, but basically the browser is going through the HTML parsings, it’s getting its HTML, the CSS, the JavaScript, and then it’s putting everything together, the CSSM and the Dom, which means it’s called the render tree. So it’s building up the page, step-by-step, and then it gives you the paint on the screen.

Lukas:              And basically, what now can happen is that different resources, your JavaScript files, your CSS files, your HTML files, they can so-called block the rendering path, right? And that means if you have, for example, a big JavaScript file, let’s say you’re loading a carousel on the top of your website, which is JavaScript based, it’s going to be blocking the rendering because it’s going to take time until this JavaScript is being downloaded, executed, and then basically ready for the site and ready for the router to start its rendering and layout and painting of the screen.

Lukas:              So, the core idea is thinking like the browser about this and looking at the individual files that potentially can affect your rendering, and from there on analyzing each of the files and then try to find solutions for the issues that will be occurring. Because for JavaScript, for CSS, for your images, for your fonts, for your icon fonts, there will be different issues playing in that in the end, make the picture that you see on the screen, and each of them can be optimized in a different way. So this would be, sort of from a conceptual level, how you could approach this.

Ben:                 So, the first thing to think about is what are the elements of your page and understanding what’s actually blocking. Do you have heavy files, JavaScript tags that are taking too long to load, image files that are a little too heavier, unoptimized? Is there any sort of benchmark that Google looked at while you were there to understand what is a performance page? Obviously they’re comparing all of the competitive pages against each other. Is five seconds good? Are they looking for everything under three seconds? Are there any sort of benchmarks that you should be looking at?

Lukas:              Yeah, there’s actually tons of benchmarks, some from a high level. Sort of the magic number that was always being used is this three second benchmark, right? 53% of users would leave a page if it takes longer than three seconds to load. So that’s been sort of the core numbers that has been used in that time. And since, a lot of research has been published, and there is an internal team in Google that is actually publishing on the Google Think website quite a lot of extensive research that are industry-specific benchmarks for the travel industry, for the financial industry. So whatever industry you’re in, check out the Google Think resources there where you can see very specific benchmarks for those performances.

Lukas:              But on a high level it was just three seconds or 3,000 page speed index that we’ve been focusing at. And then there is supporting data around that then sort of looks into, okay, with every second that you’re adding to a load time, the effect that it can have on conversion rates. And yeah, so that’s basically been sort of the base thinking in order to see, okay, how fast do we have to get pages? And then obviously Google started to roll up much more with accelerated mobile pages to be even much more faster than that. But three seconds or page speed index of 3,000 for your website is pretty decent goal to have, I’d say.

Ben:                 So I think that as we’re reframing this in terms of agency thinking, when you’re vetting an agency if they talk about what your site speed goals are, the three second benchmark is one thing to look at and understanding if you’re working with an agency and they’re not necessarily focused on page speed or if they’re trying to get your page speed down and they can’t get to that mark, they might not be the best agency. And obviously this depends on what your website is doing as well.

Ben:                 One other thing I noticed looking at webpagetest.org is that at the top of the page they go through a couple of different categories of, and they actually give you grades, what was the first byte time, keeping alive, enabled, compressed transfer, compressed images, cache static content, and effective use of CDN. It seems like that if those are the five categories that are at the top of the page and you get letter grades A, B, C, D, E, F, that it’s worth thinking about page speed in terms of those categories. What can you do to optimize any of those five categories, and are they the ones that you should be paying attention to?

Lukas:              I think it’s a really great question, and I think it comes down to the concept of page speed optimization does not necessarily have to be a huge task, right? I think it’s probably one of the biggest learnings that it took from all of those years, which was that you can have a big meeting, a board meeting, you look at those metrics, and then in reality what it comes down to is that there is potentially just an old fun file loading in the old fun file format, right? And therefore you don’t see the letters on the screen for quite awhile.

Lukas:              So to answer your question, obviously they only have their reason for existence, but there’s also different level of effort required in order to actually being able to optimize them. And speed index has a very interesting characteristic, which is that you basically just have to look at the files that you’re loading, that you’re sending, in order to be able to optimize this, which makes it much easier to work on this. So the experience was we would have had Google hackathons where we invite companies, we spend an afternoon, and the page speed would be dropped by three seconds, six seconds. It was even competitions around that, how much do you get done in a couple of hours? Because this concept of the critical rendering path and the effect that each individual file can have can be so huge in some circumstances that it sometimes it’s just a matter of, okay, looking at the JavaScript files, which ones do you actually need when you’re loading above the fold content? And then you defer the rest of them.

Lukas:              And I’m sort of sliding now into speaking about of couple of tips and tricks. I’m happy to move into that, but I think to answer your question, yes, all of the categories have the reason for existence in OCD and optimization. It’s something really important. But page speed index is something you can do sitting down in a couple of hours and find the major flaws and push it down quite a bit.

Ben:                 The last question I’ll ask you today is give us some tools and tips that you recommend for ways, if brands can quickly lower their page speed, what are some of the ways that you’ve seen do that? Give us the secret sauce.

Lukas:              Sure. I’m going to give you a couple of tips that we’ve been using again and again to optimize the pages. So number one, you go to webpagetest.org, you run your test, and you click on what’s called the filmstrip view and you see a step-by-step breakdown how your page is loading, which gives you sort of the ammunition to know into which files to look at. And you will be seeing, for example, that you have a lot of JavaScript files at the top.

Lukas:              First step there, if you have a lot of JavaScript files, have a look, which ones do you actually need? Right now at the beginning when the page is loading, sometimes it’s the JavaScript that is responsible for the checkout at the very end of the user journey. Those JavaScript files, they can be deferred, what’s called deferred, or they can be loaded asynchronously. There’s two ways to do that. Which means they’re just being basically pushed back a little bit in the loading time and because they’re deferred, they’re not going to be impacting the critical rendering path. So that’s one thing. Check for your JavaScript files, can you defer some of them?

Lukas:              Then there is obviously stuff like images, right? I mean, a lot of stuff has been talked about images. Only a few small pointers that I want to give there. So if you are loading images on your page, what you can be doing is you can be loading the image size that is matching the device size. All right? So you have an image that has a size of maybe 450 by 400 and 768 by 400. 1,200 times 800, so different versions of your image and you load it depending on which device the user’s coming from. So there will be source set in CSS. That’s something you guys can be doing in order to decrease the load time of the image. Obviously compressing images is another thing.

Lukas:              Another thing that we’ve been doing quite a bit with the images, it’s a little bit debatable, but it’s the idea of Base64 encoding. You take one hero image, you Base64 encode that, Base64 encoders are all around online, which means you turn your image into a code string, you take the code string, you place it into your HTML, which means it’s going to be pushed with the first request because you said just before, in a critical rendering path, the HTML is the first file that is being pulled and parsed. So that’s when I think through.

Lukas:              And then there’s, lazy loading is another way. You load your pictures on demand basically. Somebody’s scrolling the page, and if you can work with libraries such as … Lazysizes is a nice one to load pictures on demand, and not pre-loading them. Because most of the pictures on your page are images you only need once the user starts interacting, and not in that first couple of seconds. So that’s a really great thing to check.

Lukas:              There’s tons more of this next small things. Some things that really fascinated me was the fonts, the font files. Super easy trick if you’re not particularly worried about which phones you’re using, it’s recommendable to use something like Open Sans or Roboto. Why? For the very simple reason, they are the most used phones on the internet, which means the likelihood that a user has already has downloaded and cached that font is super high. It’s something like 70-80%, about that, which means they already going to have, per default, your font ready on the screen and don’t have to wait for a load. Another small one, and I can go on and on and on-

Ben:                 Don’t stop now.

Lukas:              Another small one will be, okay, you’re loading your icon fonts, right? What have been seeing again and again is you’re using something like IcoMoon or any other packages of icons and you actually use three or four icons on the above the fold screen, but you’re loading about 600 icons in the package for that first load, right? Because you just put in that file, which means, again, here you’re loading something that you don’t need. So you can take those three or four icons that you need for the above the fold content, Base64 encode them as well, and send them with the first request and then later load or the other icons that you don’t need. So it’s really all about pulling the layers and layers of files that are sort of blocking the rendering that you actually don’t really need at the very moment.

Lukas:              And let’s say the standard example has always been the carousel that you have on the top of the screen. A lot of e-commerce pages did and still, to a degree, are doing this to have a carousel of flicking images at the top on mobile, and you come in here to a situation that most of the time this is a JavaScript based so it’s going to be blocking the rendering by default, and it’s going to be several images loaded at the same time, which is, in a way, a recipe for disaster from a page speed perspective, right? Because you have to get the JavaScript first, you have to load all those images, which is going to then take quite a while until you have that first render being done. And on the flip side, the effectiveness of those carousels is really highly doubtable on whether somebody actually interacting with those third, fourth, or fifth image.

Lukas:              Yeah, so there is a lot of things that you can do. I think the key perspective is to have a look into your own waterfall from webpagetest.org, see how your files are effecting, what files have been loaded when some screen is still blank, or your screen is there but just the hero image is missing. So it’s really down to that level, and I think that makes it a little bit more tangible and a little bit more actionable. So a page speed optimization can be done in a matter of couple of hours.

Ben:                 Lots of great advice, lots of low hanging fruit for our agency partners, for our in house SEOs as well. And that wraps up this episode of the Voices of Search podcast. Thanks for listening to my conversation with Lukas Haensch, founder of Pathmonk. We’d love to continue this conversation with you, so if you’re interested in contacting Lucas, you can find a link to his LinkedIn profile in our show notes, or you could visit his company’s website, which is pathmonk.com, P-A-T-H-M-O-N-K.com.

Ben:                 Just one link in our show notes I’d like to tell you about if you didn’t have a chance to take notes while you were listening to this podcast, head over to voicesofsearch.com where we have summaries of all of our episodes, the contact information for our guests. You can also send us your topic suggestions or apply to be a guest speaker on the Voices of Search podcast. Of course you could always reach out on social media. Our handle is voicesofsearch on Twitter, and my personal handle is BenJShap, B-E-N-J-S-H-A-P.

Ben:                 If you haven’t subscribed yet and you want a regular stream of SEO and content marketing insights in your podcast feed, in addition to part two of our conversation with Lucas Haensch, founder of Pathmonk, we’re going to publish episodes multiple times during the week. So hit that subscribe button in your podcast app and check back in your feed soon. All right. That’s it for today, but until next time, remember, the answers are always in the data.