Website Speed Optimization with Doc Sheldon

You can watch the webinar or to take a look at the transcription here:

Dido Grigorov : Hello, everybody, and welcome to the twelfth episode of our English series of SerpAsk. My name is Dido Grigorov and I’m Head Of SEO here at Serpact, with more than 16 years of experience in SEO and focus on technical SEO, semantic SEO and SEO strategies. Today we have a really great guest totally dedicated to the loading speed improvements. And his name is Doc Sheldon. Hello Doc!

Doc Sheldon: Hello Everybody!

Dido: We’re very happy to see you here. With nearly 40 years of professional writing under his belt and 13 years of constant studying, the complexity of the SEO, combining his deposit between SEO and Content Strategies seem to be a logical path. Now Doc is former owner of Intrinsic Value SEO, a CEO and co-owner, publisher of Search News Center, co-founder owner of Top Shelf Copy. And his specialties include site speed, Web site Security and on-page and technical SEO. Doc goes to great lengths to stay on top of the daily changes in the search. The newest developments in tools and techniques and any news that may help better serve his clients. So this is a very, very brief, brief presentation of Doc. Let’s start talking about you as a person and tell us how did you get into SEO and how did you start with SEO?

Doc: We’ll take a quick step back before actually getting into SEO. I was a business consultant for about 20 years.

But the nature of my business meant I was on the road for six months out of the year and I had a young teenage daughter and I wanted to start spending more time at home. So I looked at early retirement and finally, at about fifty five years old, I decided, OK, I’m going to retire early. And I did about the same time the economy went to crap and I decided, OK, I have to go back to work. So I didn’t want to go back on the road. And I had a history in marketing and publishing. So I thought, well, perhaps getting into writing, I’ve always wanted to write a book. I got back into writing and I looked OK. There was an opportunity to make some money online at copywriting. And I saw this thing I’ve ever heard of called SEO Copywriting. And I had to start investigating. What is this SEO? And I found it so interesting that I started paying more attention to that than to the actual copywriting. I did do some writing just to bring some money in, but I was spending more of my time studying SEO. I got involved with a group of some colleagues, David Harry and Terry Van Horn of the group “The SEO Dojo” started to spend a lot of time there and found some great friendships and learning opportunities there. And so I studied SEO for about a year and a half before I ever started actually practicing it. And it kind of went from there. I have gotten to the point now where my partner now runs the Top Shelf, the content agency where I handle Intrinsic Value. And I do some editing, but I don’t get involved much on the content side.

But I found it fascinating because it’s always changing. You know, each week Google and Yandex and Bing and there’s always something new.

So I find it fascinating to try to stay on top of that stuff. And over the last few years, I’ve focused more rather than organic. I now focus more on the technical side and security and site speed even before mobile-first became an issue. Was interesting to me. So that’s where most of my focus is.

Dido:Ok. What was your first challenge in SEO you have experienced in your practice?

Doc: My first challenge?

Dido: Yeah.

Doc: What in terms of the type of problems?

Dido: Yes.

Doc: Мy first biggest challenge… I guess it was one of the larger sites that I had early on was on “go daddy”, go daddy hosting. Well and that’s it has an adventure in and of itself that lasted about four months just trying to get the site satisfactorily migrated and functional.

Again, there was so much custom structure in there, so much custom coding that “Go Daddy” had done for them that they would not turn over. And we had to reverse engineer it and redesign some of it. And that was a major learning experience that was at that point in time. I still by no means was a coder. You know, I was able to cut and paste the script. If somebody who knows what they are looking at can say, yes, this will do what you need. I could copy and paste it, but that was about the extent of it. And I learned quite a bit. And I realized then that not knowing html was like trying to run a race with one leg. So I started studying html. So that was a nightmare, but it was a great learning experience. And it also taught me. Now any new client comes to me if I see their on “go daddy”, either tell them we’re going to change you to a different host or you’re gonna find a new consultant. Because I’m not going to. I will not go there.

Dido: Is like a nightmare for you?

Doc: The hosting. Yeah. I mean, they’re great as a registrar, but they’re hosting. It was a nightmare. And I have a couple of other platforms that I’m not wild about, but they were mostly simply because I didn’t like the limited control that I had. But “Go daddy” was one of the worst experiences I’ve ever had?

Dido: Yes. So two more questions before going straight to our main topic. We have seen here that you very often comment and participate in conversation on Facebook about Semantic SEO, Google patents or any specific thing surrounding how Google assesses the content. And though, what is your experience in this side? We’re seeing some really, really good and very knowledgeable and valuable comments posted by you.

Doc: Well, you know, I was early on when I was studying SEO before I started practicing. I spent a lot of time on forums. And you can pick a lot of brains there. And of course, you have to be careful what you read. You know, there’s people on the Internet can say anything they like and they can pretend to have all sorts of knowledge and experience and find out they’ve been doing it for three months. I found out that I made some some friendships and I learned how to differentiate between the two, the good information and the bad. And you get bored with forums after a while because, you know, you learn only just so much. But I learned the value of listening to others and having some good open discussions about thing. And I was lucky. I met a few people in those forums that I’m still close friends with who were open minded enough, they would give me feedback. They would. They weren’t impatient because I was ignorant. They were willing to share and teach. And found that very rewarding. And so when I got tired of forums or fell, I had learned as much there as I was going to. Then I started looking for private communities. And of course, blogs and Facebook groups, that sort of thing. And over the years, I’ve gotten to know some of these people.

Although I’ve never met the vast majority of them face to face. You get to know people pretty well when you have a lot of interaction with them. And I’ve found some people that are very knowledgeable that enjoy sharing. And that’s a philosophy that I enjoy as well. You know, a lot of these people helped me over the years to an extent that I can never pay them back. So my philosophy is pay it forward. I enjoy working, you know, mentoring younger SEO’s and helping them learn. And it’s just that I can’t pay it back, so I pay it forward and I still enjoy some of those two groups like the SEO Dojo is one that I’m still active in. And I’ve made some very good friendships there. I’ve been participating a lot. So you can’t help but learn something knowledgeable, you know, something worthwhile just has been in five minutes with him.

So that sort of thing. Steve Gerencser, my partner and mentor on tap is another one. Who is one of the best SEOs I know and very low key. Nobody knows who he is, but it’s because he’s out there doing it and writing about it. I was trying to do some branding. He also goes, I was starting an agency, so I did a lot of writing. And that was not the direction that some people took. But it’s that to me has been the most valuable aspect of it. Interacting with others and finding those people that are knowledgeable and willing to share it.

Dido: Yes. And if we forget for a second that you’re a loading speed specialist in SEO, What is the next most favorite thing in SEO for you? Well, or the things… maybe, I don’t know.

Doc: Well, I’m also interested in site security, particularly because WordPress, which is my primary source of work, is very, very subject to attacks. You know, it’s open source and hackers love going after WordPress sites and there’s plenty of them to go after. But I’m still learning a lot of this security and I have a couple of other contacts who are very knowledgeable in it. Shout out to Jim Morris with Sailfish. He’s extremely knowledgeable. He’s taught me a lot over the years we’ve known each other. But I’m still very early in my learning on security. And recently I started doing a lot of work with GDPR compliance. And of course, you know, you’ve got to CCPA, the California Consumer Protection Act, which is very, very similar to GDPR. New York is about to pass one that’s going to be even more stringent, probably more stringent than GDPR. From all indications, Nevada is in the same thing. Several states in the United States are ready and the Federal Congress is even… There’s a couple of acts being prepared to present before the Congress for a federal standard that is supposedly going to be very similar to GDPR. So I’ve been putting a lot of work on that, as I think, you know, the first time I saw the GDPR. It scared me because it seems so demanding.

Dido: Yes.

Doc: But then I realized when I get into it, they’re trying to write a bill there that will cover all potential scenarios. My first glance, I thought, my God, I’ve got to do all this. Well, no, you don’t. Most sites don’t. If you’re Amazon or Facebook. Yeah, you do. But for most of us, very little of it actually will apply. It’s basically just the parts that are common sense and common decency. Somebody shares their data with you. They deserve to have you protected. And there are certain criteria and it’s the right thing to do. So I don’t have a problem with GDPR in terms of most of my clients because I do most of my work with SMB. I don’t have large enterprise stuff. So. I think it’s an interesting area for me, and I’ve been highly focused on GDPR for the last several months. That security and speed and of course, responsiveness. I don’t think that there’s any excuse for any site not being mobile friendly.

Dido: Yeah. Exactly.

Doc: Those are the four areas that I focused mostly on. And you’ll notice they’re all basically technical under the covers as opposed to I don’t do any of my PPC work. Well, we pull PPC work, Steve does that because that’s what you’d really be good at. And I don’t do much organic. We do some content stuff. But I like the technical for basically anything it’s under the cover, under the hood. It’s what I enjoy working on.

Dido: Ok, let’s start off with our main topic today. The loading speed. The site speed improvement of a Web site. But before jumping into the different aspects and let’s talk a little bit about the importance to all these speeds. Why do you think there are so many rumours on the Web, especially on Twitter or Facebook, you name it, about the loading speed and its impact on the rankings on the website. Do you believe that the loading speed is impacting the ranking severely or it depends on the mid-race where any specific queries or cluster of queries? What’s your opinion here?

Doc: Well, if you recall, when Google first started talking about loading speed, being an issue, they said early on if you’re 3 seconds versus 2 seconds, don’t expect that to make a big difference in your rankings between two sites. But if you’re out there in a 17 to 20 second page load, yes, it’s going to affect your rankings. But more importantly, I think we see impact because of the impatience of the standard user. We see impact from the users. If a mobile site particularly is taken seven or eight seconds to load, you’re going to lose people.

You know people, they just don’t have the patience. There are faster sites or there are many other choices to look at. Even if you’re the fastest of five or six potential sites to visit, if you take in seven or eight seconds, they’re going to have to visit the other seven or eight sites before they’re going to finally give up and come back to you.

So you’re going to lose business or readers or or conversions. So I think that the biggest impact is, is for your client base to not lose them.

And and the other aspect that I think that some people don’t pay enough attention to, there’s a psychological aspect, just like when you’re building a sales funnel, any conversion funnel, every single step in that funnel is an opportunity to either, you know, you’re setting the mood, you’re either making them satisfied subconsciously with how easy and fast this was or how how well that your your site search, for instance, showed them exactly what they’re looking for or how it is only a one step click through process rather than three. This affects their mood and it makes them more receptive to the next step in the fall. So everything that you can do to make that process all the way through your funnel easier and smoother and faster is going to be beneficial to your conversion. So, you know, nothing anymore is early on in FCL. You know, 50 years ago, 20 years ago, you could do a thing that would have a dramatic impact. You could change your titles or change your you know, at that time, you know, the keyword better descriptions. You could do things that would show you an immediate impact that no longer happens. Now you have to do as you say, “all the things” you’ve got to do, many improvements to have a discernible impact. And I think that speed is one of them, and most particularly for mobile. Now, when Google came out and made their mobile first declaration, it becomes even more critical because now they’re looking at your site in terms of how fast it loads for mobile.

So if you’re not responsive and you’re slow, you’re not going to be a player. Period.

Dido: Yes, absolutely. And about the loading speed, you see the speed of all the people i’ve been talking about the connection, really big and strong connection between loading speed and user experience. If we just forget for a second what to say. We are just very variable… How do you think the world is being connected to user experience?

Doc: Well, again, I think satisfaction is going to be the biggest thing if they feel like this. Their feet are stuck in the mud trying to navigate their way through your site. And every time they click on a link, they’re waiting five or six seconds. The frustration will pay. So they may get to a point where they just decide. This will probably be easier someplace else and they’ll go back to the search engine and try to find a different resource or there they may force themselves to continue with the process, but they’re they’ve taken on a negative mindset. So they’re less receptive. They’re more resistant. This makes that the ability to to convince them at every level that much more difficult. So, you know, user experience is critical.

Dido: Do you believe that there is a connection between the number of elements on a page and its loading speed. This is something that is kind of made from the Web. Let’s break it.

Doc: I’m sorry, the number of what on the page?

Dido: The number of elements of the other page.

Doc: Oh, that’s a tough one. I would say, yes, there is a connection. I would say it’s indirect. It’s not the sort of thing that I think you can actually change and expect to see the immediate impact because the impact to page load for a different request may be very slight or it could be great. You know, some requests, for instance, one that a lot of people use Google fonts. OK, that’s a very quick response. But it’s a very lengthy download. OK. Yeah. So, you know, adding that request to your page really doesn’t have much of an impact. But if you’re using two of those fonts and you’re downloading the entire base, that has a tremendous impact. As you know, it’s an indirect thing.

Dido: Also, a lot of people started talking about it because it’s the new Google page speed insights too above the OM objects and requests problems and see issues related to the loading speed. What’s your opinion on these types of issues? Are they really critical and what can we do to improve the loading speed when it comes to these types of issues?

Doc: That’s you know, I do think that’s something that needs to be minimized as much as possible. It’s not always easy to do, it depends on the nature of the page, obviously. For instance, this is one of the areas where when you start combining your objects just like you like you combine your JavaScript in your CSS calls. You can combine these things and achieve a lot of benefits. Sometimes, just like back in the old days, we would use sprites. A lot of times to try to speed things up. And I think that could have an impact. So, you know, you definitely want to watch that, just like you want to watch the number of calls. You know, I recently added a plug in, but the client’s request to a page, we had thirty six calls on a speed check. I had this plug in and it went to one hundred and eighteen calls.

Doc: One hundred eighteen requests from thirty six for one plug in. Now when you see something every time you add a particular request and you see a big jump or you add a particular function and you see a big jump in call. You need to get down into the waterfall or see what’s really happening. And what I found was there is a loop, it’s a faulty design and the plug it was calling the same thing over and over and over again. The longer the TTFB had on that every test. The more calls it had because it was calling three and four times per second. So that was a weird thing. It was caused by a faulty plug in design that but it still has had a tremendous impact that that one plug in was adding 18 seconds page load. By adding 80 more or 70 some more calls to it now obviously has a direct impact. Imagine what that impact would have had if we had not noticed that they had not tested and had gone to somebody on their mobile phone. They would have lost every visitor they had. From that point. So, you know, yes, it could have a difference. But again, it isn’t always black and white. It depends on how it’s being handled.

You know, there are a few people out there designing WordPress plugins, for instance, and add ons, your chrome add ons and things of that sort that are very, very good at what they do. And they’re very speed conscious.

They’re very bandwidth conscious.

They’re trying to minimize the impact. And those are the ones I look for. You know, because sometimes you’re little like Google fonts show that it’s a great resource. But most people using Google fonts are using only one or two of their fonts and they’re downloading the entire package every time. Google has done a fantastic job of compressing that package and making it as fast as it can reasonably be. But why would you download the entire alphabet when you have all you want? Is the letter A?

Dido: Yeah. Even John Mueller… I remember telling us that Google is trying to cash and compress the CSS in JavaScript resources as much as possible while during the process of rendering. That’s why I wanted to confirm what you said. If we can make it so much easier for Google, let’s do it.

Doc: Absolutely. And I think, you know, there’s a lot of things you can do there to make it easier for them. One of the things I think it’s important from a search engine standpoint is simply to keep it as clean as possible. For instance, minimizing, compressing your files. There is an indistinct to perhaps indirect impact to your crawl budget as well with how fast these things will load. So, you know, the bots are pretty quick, but if they’re having to render things that are slow. Then you’re going to be in trouble.

Dido: Yeah. Or there are maybe too many.

Doc: Yeah. They’re only going to spend just so much time. You know, there’s a lot of discussion and none of us really know how does the board limit its time? Its the number of steps is that the amount of time is the amount of bytes. What determines how long it will crawl? None of us really know outside of Google. I like to take the worst case approach and say, okay, what’s the most I can possibly do to impact my worst case situation? And I want to make it, like you say, as easy for the search engines as possible. Google obviously is our biggest target because they’re there the majority of most of our marketing effort. But fortunately, the things that Google looks at are not that different from the things that Bing looks at or the things that Yandex looks at or even Baidu if you play that field. So, you know, they’re looking for the same sort of thing. So if we’re working to satisfy Google or probably not hurting ourselves with the others.

Dido: You’re absolutely right. And thanks for the great explanation actually. Share with us the most common patrolmen when it comes to the loading speed. Let’s say … this year. What are the most common problems you experience, and you have solved on a regular basis this year? When it comes to improving the loading speed of a website.

Doc: The biggest problem I see with a new client is usually images. OK. They’re trying to display a 300 pixel wide image. So they upload a 20,400 pixel wide, you know, six megabyte image. And they don’t downsize the file size.

They don’t scale it to the size that they want to display or, you know, if you’re displaying something as a thumbnail and as a 300 wide and as a 500 wide word, press core for instance does a pretty good job of extracting a thumbnail from a three or four hundred pixel image.

It’s not that big a deal. So you don’t necessarily have to upload three different things to your video library. If you upload 500, you’re probably going to be OK, but uploading a 3 megabyte image to display something like that is foolish.

So, you know, that image is the biggest area that I see. And then the fact that I see so many of them, they think that they’re compressing images because they’ve loaded G-zip. G-zip is great at compressing scripts. Your JavaScript and your CSS. In fact, it’s probably gonna do more harm than good with an image. It’s actually going to make the file somewhat larger in most instances. So, you know, things like “Smush” is a great plug-in for it for image compression. And I think images are the biggest issue. Loading, sequencing… I think particularly users that site owners who are not particularly technically oriented are a little leery to even look at if they’re aware of the ability to do things like deferred loading you that they don’t know if there’s two different kinds. You got conditional loading. You don’t have to be a code monkey to do these things. There are plugins that will help you do these things.

Dido: Can you share some names of plugins, besides Smush?

Doc: For images. You know, I’ve tried several of them. That’s the only one that I really liked. Tell you the truth. I’ve been very pleased with Smush. There are some others that I have tested and I just wasn’t impressed. But I can’t say that I analyze them enough to be able to make a fair call.

So this is a good one or not a good one? I would be hesitant to say that. I found Smush early in my search and was so pleased with it. I stuck with it.

Dido: Yeah. That’s great. OK. And what are your main tips for image optimization when it gets to the loading speed improvement. I mean, can you share some actionable advice to our audience – what to do and what to preserve.

Doc: For the entire page speed or just in images?

Dido: Just for images for now.

Doc: Well, for images, I would say. First of all, look at your file type. You know, .svg is beautiful because they’re so small, but it’s only really appropriate for things like logos, you know, basically consider, you know, good, clean. There’s no gradiention. There’s strictly a three or four colors and an ideally line arc, you know, fantastic. But for images, like for a portrait or a headshot, it won’t work.

Doc: So you’re gonna go to then typically you’re going to look at a webp, a JPEG or PNG. PNG files are typically larger than JPEG. So unless you really need transparency, go with JPEG. JPEG is lossy. But if you’re working your images up properly, and particularly if you’re starting with a high res image, you can scale it down to what you need and you’re not going to lose that much. I think a lot of people forget the fact every time you do something to a jpeg, regardless of what you’ve done to it, every time you save it, you lose some resolution.

Dido: We are seeing that so many people are using PNG massively today, even for the thumbnails and so on. So this is not a good practice, as you said, if you had a chance to use something with a background like a JPEG especially, withe backgrounds? So go and use it so it can reduce the size of the file. If you need something without the background, then go use the PNG. But be more careful with that.

Doc: Yeah. The other thing that I see a lot of with images is a misunderstanding of resolution. You know, people are uploading three hundred, six hundred, even twelve hundred dpi Images and they don’t understand that browsers aren’t going to display that, you know. Ninety six is the best DPI you’re going to see through most browsers. You know, if you’re selling images, if you’re selling high resolution images, then your download file might be a twelve hundred. That’s fine, but that’s a download file. What you’re gonna display, make it ninety six dpi. If that’s the most that you’re going to get any benefit of uploading a three hundred dpi which you can make for a much larger file at a much slower download and display. It’s a waste of time and it’s a waste of bandwidth as well. And it’s certainly a waste for your mobile users. You know, increasingly we’re seeing more and more even for the type of site that was traditionally not considered, typically something good a mobile user would go for. More and more people are sitting at home and I mean, I’m sitting here in front of my desktop and I got my phone here. There’s many times I don’t want to change many of my three monitors. I’ll look up something on my phone. So it needs to be understood. There are many things besides just smushing photo to make it proper scaling, you know, to setting it up to approximate the size of what you’re going to need some time if you’re gonna display one at fifteen hundred pixels wide and other at 300 pixels wide, you’re probably going to need to upload to versions to that to the library.

Dido: Yeah. And what do you think about the hottest trends in 2019?

Doc: In terms of do I think that it’s a good process? Certainly!

Dido: Yeah, well, do you think it’s a good practice?

Doc: I typically like to start loading them initially. I don’t particularly want to wait until the user scrolls down unless I know that I’m going to be a fast loader. If I’ve got an optimized image, I can probably get away with it. But even if you’re not looking for the images, you know, when you’re on your phone, particularly if you’re scrolling down to the page, let’s say you want to get to the photo you want you’re looking for a privacy policy lake with the footer. OK. You’re scrolling down. All you’re seeing is a few empty boxes as you scroll.

Dido: Exactly.

Doc: You don’t care about those images, but it doesn’t leave a good user impression on you.

Dido: Yeah. That’s why I’m asking this question, because so many people started to be frustrated with this kind of practice, especially on their mobile phones, because as you said, you see just the small or big box with a spinner and you have to wait until all of the images are loaded up, for example, the image on the bottom and you see up almost, almost partially a blank page, which is not a good idea. But if we want to use lazy loading, what is your advice there? Maybe we have to tweak a little bit the loading speed of how fast the images are loading?

Doc: It’s I think I’d say it’s going to depend much upon what else you’re doing. You know, it can vary. And of course, what’s the site? You know, if this is a page that has got 16 images on it now perched, for instance, a blog page. Every single blog post has a hero image. And I’ve got 10 posts listed on my main blog page. Then that’s gonna be a different situation than if I’m going into a post that has the hero image and one or two other images on the post. So typically I’m going to try to start loading the images immediately. I typically don’t like lazy loading, but if they’re very simple graphics, for instance, a screenshot of Google Analytics. OK, there’s not, it’s not a portrait. It’s not highly detailed. It’s not a heavy file size. That is probably not going to be a concern because it’s still going to load in, you know, then a couple hundred milliseconds. But if it’s an image of let’s have a photographer it I’m showing even if it’s just a low resolution, 300 pixel image of a scenery. That’s going to be different if they get down. If they scroll down to their page and it just starts loading when they get there. Even if it only takes a second and a half. That’s going to have an impact on my conversion. You know, it’s going to impact the impression of the user. So I should have started loading that, you know, initially on page load. So this is ready when they get there.

Dido: Yeah. Thank you. So let’s continue to the next hot topic when it comes to the loading speed. And let’s talk about the JavaScript and CSS resources. Many people started talking about them, about caching them, about minifying them or maybe any other of the techniques like cleaning of the unnecessary CSS selectors, or a loading any specific resources just on a particular pages and preventing some other resources not to be loaded to any other pages than when they’re not needed. So what are the problems you see here and what kind of approaches do or why? When it comes to making Google pagespeed insights happy. And Google, respectively.

Doc: Well, this is one of those areas where I think that going back to what I said earlier, that it kind of plays along with many other aspects. For instance, you know, combining CSS and JavaScript files is generally a good practice. Minification is definitely a good practice because it means absolutely nothing to the search engine. It just speeds things up for the users. The search engine does not care about those white spaces. OK. If you’re a developer trying to get in there and troubleshoot a problem, there are tools like demystification, your online tool where you can drop it in there and demystify it rapidly so that it’s easier to find what you’re looking for, but it only has an impact on page load. It doesn’t hurt the search engines, the leaf. But when you start looking at things like again and deferring comes into play too. One of the things that I look at with CSS is first of all, is this CSS going to be used on several pages? OK, now my caching comes into play in a big way because I don’t want to download it four times when the user hits four pages. I want to download it once and play it out of cash. And if the aspect that’s being modified on a particular display is, let’s say, just text color or size, why would I download a whole script if that’s going to be just that one item? Those are the kinds of things that I’ll break out and put in light.

Doc: Because a line of inline CFS has essentially no such a negligible effect on page load that I don’t care. I could do that 12 times and I won’t care. It’s going to add 60 milliseconds, you know. So it’s the sort of thing that I think when you start looking at combining. And possibly breaking out in line. Very, very small snippets. You know, those things could have a big impact. Minifications can definitely have an impact. And particularly what I’ve seen some CSS files that were thirteen fourteen hundred lines and literally there are tools that you could run this thing through, run the page through and find out if it was using I think it was here 14 or 17 lines out of thirteen hundred that were used on that particular page. So I immediately broke that out and put it in line. It just chops several seconds off the page load because that was an internal page, but it was actually getting linked to from externally. So it was the first download of that script. It just made no sense at all. And you know, you can defer your JavaScript that can have a major impact. Know the JavaScript is really not typically terribly slow type of file to download and implement, so it’s usually going to be a benefit with few exceptions that I’ve seen where it’s not a benefit to defer it and out and download it when the user scrolls down to that point, make it a condition.

Dido: Yeah, absolutely. And we see that people are talking more and more about the size of the files of JavaScript and CSS. Do you think this plays a major role when it comes to the loading speed? For example, even Google Page Speed Insights started showing us that, for example, just because that’s JavaScript is X kilobytes, or X megabytes large. This is slowing down the loading one, two or three seconds, unfortunately. So what is your advice here?

Doc: Well, yeah, there are some that I have seen that were extremely large files. Where I normally see that is in things like a lot of custom WordPress themes. And in the theme they’re trying to offer the users 36 different options.

They think they’re doing you a favor by consolidating all of the options of possible functions into one script. So you’re downloading a massive file and you’re only doing one thing. And there’s a number of themes out there that do this. So where you’ll have a 3.2 megabyte CSS. Yeah. But that’s massive. This thing, it was like 4000 lines and if you call, for instance, there’s some builders out there, DIVI is one that I viewed, DIVI has a CCS file. For let’s say for the text size in a particular module, they have, you know, if you’re using this module, they have that CSS file that lets you set the text file if you’re using a different module. They have another almost identical, sometimes actually identical CSS file. OK. If you’re using both those modules on the same page, you’re downloading that same file twice. OK. It’s two separate calls, two separate file names. And it would make this a real pain in the neck. From a modification standpoint, if you’re trying to go in, if you’re not familiar with, maybe you’re trying to go if you want to change, let’s say the text color, guess what? You’re gonna have to go to 16 different places to do it.

It’s not going to be a one off script. So there you know, it becomes from a developer standpoint, it becomes a real nightmare to have to to have them all broken out. But a five or six line CFS file, you might as well be in line. You know, it is very fast. So it’s something like a Divi site. It’s not worth trying to go in there and pull that little script apart and make a deadline if it’s not having a major impact on page speed. It’s an issue from a modification standpoint in my mind, but it’s not slowing the page down. It’s quite functional. It just seems because that file isn’t a big deal. So downloading it twice versus once, I’ve added 12 milliseconds. Big deal. You know, I just don’t think that enough attention gets paid to the real impact of the script files to page load. And, you know, people thinking that they’re doing you a favor by putting it all in one. No, they’re not. You know, it needs to be from a functional standpoint.

Dido: Yeah, absolutely.

Doc: To a degree. I think the same is true with JavaScript. But to a much lesser degree.

Dido: Ok. Another question. We have started seeing it on the web, especially with the plane and the pure template section of HTML and CSS and JavaScript. So the question is: HTML, CSS and JavaScript or a PHP based solution? What do you think is better? Do you believe that WordPress can achieve the same performance as a pure HTML, CSS and JavaScript web site. And why?

Doc: You know, I’m going to really tick off some from friends with this answer because I know they have very strong feelings of the opposite. I do think that a straight HTML site can be extremely sleek and very fast. OK. Probably faster than any WordPress site. If speed is the intent for both of WordPress developers’ desks and from an HTML developers desk, the HTML is probably going to be faster. However, how fast is necessary? I have yet to work on any WordPress site ever that I haven’t been able to eventually get down to consistently load in 2 seconds or less. Not out of the box, obviously, they took a lot of tweaking and then sometimes hours and hours of tweaking was with some sites to really get them that quick. But it can be done. And if its site is loading in one second versus 2 seconds, I don’t think that that’s going to have an impact on either rankings or customer satisfaction. So at that point, two seconds or even three seconds is probably fast enough. So the difference is slight. And I’ve done e-commerce sites that were medium, not large sites, but they had several hundred products and I can still get them all to load in under 2 seconds consistently, regardless of the tool that was used. Well, the exception of Google’s page load tests, you could put us all over the map. But they know they can be done is just not out of the box. So HTML is certainly very, very fast. And you can do basically anything that you can do with a WordPress site. You can obviously do it with HTML. And it’s just a matter of preference. I think that WordPress has delivered something to the world at large that enabled an awful lot of people to get a site online, even if it’s just a hobby blog who would not be able to to bring themselves to learn HTML in order to do it, or they wouldn’t have been willing to try. So to me, WordPress deserves major kudos for opening the doors to millions and millions of people who would not have ever had the opportunity if they had learned HTML to do it.

Dido: Yeah, exactly. So I see we have four questions at the moment from our own. Let’s start with the first question right now. What is one of the most popular and most useful tools for Page Speed analysis, in your opinion?

Doc: You know what I’m looking at? We’re on page speed. I never use one. Always run typically three tools multiple times, three, four or five times. Because even if I’m using webpagetest.org, for instance, is what I use a lot. If I use that thing five times, I’ll probably get at least one or two tests that are outliers. There’ll be a second or so different from the others. gt.metricks.com is another that I use all the time. Lighthouse in the Chrome developer tool is great. Another one I’ve recently started using that I kind of like because I like the drill down data it gives you is this Sucuri load time tester – set performance dot security dot net. That’s a good one. Now page speed insights is not one I have been impressed with.

I see more variety in consecutive tests with that than in any other tool. It might tell me one point two seconds and then 5.6 seconds and then three point four and then eleven point two, all in a period of four rapid consecutive tests. And that just makes no sense. And that’s without any big variance in time to first bite. Even on downloading a particular file, it will show me radical differences. So I have very little confidence in the pace speed insights tool.

Doc: Another one I use is Kingdom on occasion. Usually only when I get into a real sticky one, when I’ve been when I’m really having to tweak the dickens out of a heavy page. But I always use GTMetrics, Web page test and Lighthouse, often adding the security load time to that. Those are for I have a high level of confidence in their output and they all have different ways of displaying their data. They all have a waterfall type where you can look at individual file impacts and get a quick visualization. And they’ll typically don’t disagree much. Sometimes the fact that one of them and I have this a lot of time, something GTMetrics might say this is a problem when a Web page test or didn’t see it as a problem. And that makes me go take a second look at that file and I’ll find out something that can be tweaked because there may have been a higher level of sensitivity on GTMetrics sparked to that particular type of file. So, you know, using multiple tools is always a plus.

Dido: Okay, and what do you like most when it comes to GTMetrics? Why do you use it? Because this is one of the questions.

Doc: I like GTMetrics. I like the way that they display the results. I started using webpagetest.org first, so I got used to their display. And so I’ve heard people say that they find things easier to find on GTMetrics because they’ve been using it all along and now they’ve looked at Web page test stories. They got spoiled because GTMetrics from a UI standpoint I think did a nicer job on making it easy to get used to easy to learn and webpagetest.org is a little bit.

It was a little bit more of a learning curve. They give you some good drill down and GTMetrics as well. But the vision is displayed. It’s a little bit more… What’s the term I’m looking for? Intuitive, I guess.

Dido: Yeah, you’re absolutely right. And our fourth question here, what is better between Lazy load and Infinite scroll, especially for products in a category page?

Doc: I would very, very aggressively shy away from an Infinite scroll for that sort of a page. I’m not fond of it for most pages. Unless it’s a very small site, you know, five or six pages. And you can get that entire thing down. You know, you’re definitely going to want to go to Lazy load on if you’re going to infinite scroll. But when you start looking at if you’ve got 60 products, you’re having to load a lot of things into that page before your first product description and image are going to display. So your initial is going to be very impactive. Now, you may be OK when you get down or product 12 because you’ve got the majority of your bulc is already loaded and functional. And now you’re worried about that particular product. But the initial page load I think is going to be heavily impacted when you’re dealing with that sort of thing because you’re going to have many different files you’re trying to download down to that page. Very different calls, the idea that there are calls again is an issue there because you’re calling a lot of different images or cooling a lot of different text blocks. Depends on the design criteria. What sort of platform are you using? But in most instances, I guess I focus so heavily on WordPress sites. I would be very leery of going in for a scroll.

Dido: Yes. As a good practice. And before going to the fun part of the final webinar, just a small question as a summary of what we discussed. Can summarize your tips for our audience. And where do you think you’ll go in the future of the loading speed of Web sites when it comes to these improvements? Do you think that machine learning would be built there? When it comes to calling, search engines can understand it. What are your beliefs actually?

Doc: Well, before I touch on the machine learning part of your question, I would say that in general speed is going to continue to be important and perhaps even more so for a while. But now we’re looking for five 5G is probably just around the corner for mobile. So again, at what point does it become an issue… If your page will load in seven hundred milliseconds and my page loads and one point five seconds, will the average user care? OK. I don’t think that is going to be. I don’t think it is going to have any impact for either one of us. And as the ability of the networks and phones begins to be capable of handling more speed. I think that for you and I as developers or SEO’s page speed will become somewhat less important. Now, looking at the other aspect, you know, machine learning. I don’t see… I don’t know that I see a connection there. Maybe you could expand on it a little bit bigger. I don’t really see how that is going to affect us in terms of page load.

Dido: I mean, if you believe that machine learning, what will be part of assessing a Website quality in terms of the loading speed? And do you think that it will play a major role when it comes to assessing the site’s quality at all? Even we in the machine learning era and how did you think this will be changed in the future? Do you see any changes to when the machine learning will be implemented more aggressively to this area?

Doc: I think machine learning is definitely upon us. It’s coming. It’s developing very strongly and I think it’s going to become increasingly more important. Things like schema markup, for instance, I think are going to continue to yield tremendous benefits for us and that can help in rankings and in search ability. But I really don’t foresee any impact to machine learning on page load. I think that, you know, the two or I don’t see them coalescing at all. I see, you know, page letters can become more important. Machine learning has certainly become drastically more important and communicating. You know, we’re not looking at keywords anymore. We’re looking at entities. We’re not looking at it so much as the keywords and the content as we are the context. So it makes it more important rather than hitting, you know, let’s not try to stuff 80 keywords under a page. Let’s try to find one and focus on it and make it obvious. The surgeon, you know what that page is about. So we’re contextually focused. I think that’s going to have an impact. And that’s where schema markup can really come into play with machine learning, because if you have schema markup on a page on six different things, then you’re confusing the search engine. It doesn’t know what the page is about. Which one dominates?

Dido: Yeah. So it’s time for a fun box and. Now, let’s say thank you for being our guest today. Thanks for accepting our invitation and thanks for sharing your great variable knowledge and experience with us, because as you sayid, the loading speed will continue to be important when it goes to the good user experience, the good rankings. I would like to say it’s that time. Thank you to our sponsor called Serpact, thanks to our team and to Doc Sheldon. Thanks for being with us today. Thanks for sharing with us. And don’t forget to follow us on YouTube. We will very soon announce our next guests in the next month. Again, thank you for being with us today and for sharing your 60 Minutes here with us.

Doc: Thank you for the invitation. I enjoyed it.

Dido: Yeah. Thank you for the great explanations and discussions. We’ll see again in the next months and see you friends, Bye Bye!