Two weeks ago I told y’all about the concept of mobile friendliness vs mobile speed and how I’d been losing all this traffic because the speed of my sites stunk even though all of my sites were considered mobile friendly. Well, I’ve been on a major quest to rectify this, and I’d like to share with you what I’ve been doing.
First, let me remind you that on the above post I showed that my friendly score was 100/100, and my mobile speed was 58/100. What I didn’t share was that my desktop speed was 61/100 at the time. All of my blogs were between 54 to 58 on speed and 58 to 61 on desktop before I started. Let me show you where I stand now, and I have to admit that I’m kind of proud, even if I’m not perfect yet:
That’s not bad, right? I’d have to say I’m fairly proud of what I’ve been able to accomplish… so far. I’ll explain some of the things I’ve done to get to where I am now, while realizing that not everyone will be able to do some of these things unless you’re pretty technical and not afraid to experiment.
First off, let me tell you that upgrading my hosting package to a new one did absolutely nothing for my speed. I waited the 5 days like they recommended, nothing worked, and I contacted them again, only to have them send me the same Google link I’ve talked about previously. I was fairly irked at the time, but after a day I realized that some of what I still had to do wouldn’t have worked if I hadn’t upgraded. So, even though they kind of misled me based on my beliefs, it still turns out I had to do the upgrade anyway.
Why?
Back in 2006 when I purchased my package along with my friend Kelvin, compression wasn’t a big deal for websites. There was talk about making sure your website didn’t take forever to load, but most of us never paid much attention to that because, except for those who used a lot of Flash or tons of pictures it didn’t affect us that much.
These days if you run the Google speed test one of the things it recommends you do is set up compression. If your hosting package isn’t up to date, then it’s possible that no matter what you do as it applies to coding your site either isn’t going to speed up at all or it’s going to look like you broke something.
I ran into both problems. First, I created a php.ini file and I added this bit of code to it:
upload_max_filesize = 40M
post_max_size = 8M
zlib.output_compression =1
zlib.output_compression_level =9
Initially I was doing all my testing on my Syracuse Wiki blog and this one. The theme I use for this blog is fairly old, even though I’ve made lots of changes to the files, whereas my newest theme is on Syr Wiki. Adding the compression code in the php.ini file made IJS disappear, while it didn’t affect Syr Wiki whatsoever. After I upgraded, both sites stuck around but increased speed by only one point.
There was another part of compression that had to be performed, and this time it was messing with the .htaccess file. See, even though I was on the new package, it didn’t do the compression unless you told it to. Research talked about turning on what’s known as GZIP compression. Frankly, after reading all about it my head was spinning and I still didn’t understand anything about it except what it was supposed to do. I found this code and tested it, and it helped give me a bit more speed:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
By a bit more speed, I mean that both of these pages were now in the 60’s, both sitting at 62. That’s still considered as poor speed, but it was an error message I wasn’t getting anymore and it was moving in the right direction; yay!
Next I decided to try a caching program because I saw a lot of people recommending it. I was hesitant because back in 2008 I had tried WP Super Cache and it pretty much shut this blog down. Still, I decided to try it again, this time using W3 Total Cache.
The initial problem I had was that it conflicted with the WPTouch Mobile plugin, which actually makes all blogs mobile friendly but doesn’t do anything with speed. I found some adjustments I could make and made them, but nothing I did helped to increase my speed. I’ll admit that I don’t fully understand how caching programs work, but as I looked at the Google recommendations caching wasn’t a problem it was talking about so I decided to remove the plugin and try something else.
Before I tried another plugin I decided to address a different issue that kept coming up, that being something about CSS files and javascript files slowing things down above the fold. I know nothing about javascript so I decided to tackle CSS, something I did know about.
Once again, CSS has modified from when I first learned it some years ago. Back then, the idea was that you put everything that you wanted to modify on multiple pages all the time into your CSS files so you didn’t have to individually code each page. These days you can still do that, but certain types of code are considered as secondary code. By Google’s “definition”, any piece of CSS code that begins with “.whatever” is code that doesn’t need to be loaded immediately along with everything else, and that it need to be put into the
area of your HTML coding using < style > codes.That blew my mind for about a day, and I finally decided to test it on one of my static websites first. When I got a mobile speed of 90 I figured I was on to something. lol Still, this was WordPress template software that I was about to mess with; what if something went wrong? Well, fortune favors the bold, and as long as the bold is careful things usually work out… right?
I opened two Notepad files. In the first one I pasted the entire CSS code into it and saved it onto my computer. In the second I copied and pasted every single CSS code that began with that dot into it and spaced them all apart. Then I added the < style > tag at the beginning of each of these things and < /style > (if you decide to try any of this don’t put the spaces in the code like I did here; it seems that without the spaces it alters the blog post; go figure…) at the end of each one… trust me, there’s a lot of these in each of these CSS files.
I went back to the original CSS file in the blog software and removed all of those dot files, then saved it. After that, I went to the Header.php file and, under the
area, near the end of that tag, I added all of the new < style > codes and saved that. By the way, I’ll be coming back to this process in a little bit because it led to something else that was eye opening.I tested my speed again and both sites were now in the 70’s. I felt pretty good about that but I didn’t think it was good enough. Although I had conquered the CSS issue, the javascript issue was still there, and oddly enough a couple of the scripts messing things up belonged to WPTouch; that was freaky.
I went back into the deep research and tested a bunch of different plugins, but almost none of them did anything for either blog. I temporarily added Zara4 as a photo compression program which affected a file here or there, but it would have been a bit pricey to go back and compress all the images that really needed it. I decided against that for the moment, although I did shrink a couple of images, which includes my image to the top right and the images for my books on the left and that helped a little bit but not much.
The plugin that finally worked for me, along with all the other stuff I did, is called Async JS and CSS. It didn’t come up as an option for me until I came across it on a forum and searched specifically for it to add it as a plugin. The first changes I made to the settings, which were recommended, brought the speed of both blogs up to 100/100, which would have been fine except it erased the content of both blogs from the internet; oops! Realizing that not all settings will work on all blogs, I did a little tweaking and actually had phenomenal speed on both blogs, both over 90; Syracuse Wiki is still over 90, and I’m ecstatic about that. By the way, here’s my settings:
Your question is probably why IJS isn’t still above 90. Well, this brings up back to all that stuff I did above with the CSS code that I talked about above. For whatever reason, on all my blogs I have to disable the majority of plugins if I want to make any changes to those files, otherwise I get a “not found” message after trying to save anything. The reason I had to go back in was because there was still one thing I had to add to the header, that being the code that corrects the Configure The Viewport issue that all older themes and websites will have.
In a previous post I talked about how the recommended coding by Google never seemed to work for me. Well, it still doesn’t! Not on my blogs and not on my websites. I figured out how to modify it, so my code now looks something like this: < meta name=viewport content="width=525” >, where I specify a width size. Google still doesn’t like this, but your speed will improve after you add it.
Because I had to go back in and add it, I did it first on my Syr Wiki site and hit that magic 98; wow! Then I came to this blog and added it and was up to 91; yeow! However, when I added all my plugins back, I dropped down to 72.
You know what this means. One or more of the plugins were messing things up. I decided I had to add them back one at a time to see who the culprit was… or who they were. I don’t have a lot of plugins on Syr Wiki since that theme is newer, but I have tons on this blog. So the process began…
The big culprit turned out to be my Readspeaker plugin; oh no! I added it to my blogs back in 2009 as a way for people to be able to listen to my posts instead of having to always read them. I was kind of an early adopter, and it was a free plugin at the time. What I hadn’t paid attention to is that they’ve never added an update to it, and when I went to their site I learned it’s because now it’s a paid model, and the paid model is updated and coded totally different than the one I have.
By removing it from this blog I jumped from that 72 to where I’m now at 86; sigh… Since I have no idea if anyone was still using it these days I guess it’s time to call it a day; oh well…
That’s how I’ve achieved the new speed on both of these blogs… kind of. It turns out that speed only applies to the main blog page. For each individual blog post, the only way to achieve that speed is to compress any images you might have on those pages. This is partially problematic for me because most of the images I use on the site come from Compfight, which is a plugin I use that searches for Common Creative image files I can use for free, but since those images aren’t actually in my files there’s nothing I can do about the size of those files.
I did test it on a post that had my own files, which is the first one I linked to above. The first image was already small, at 22kb, but the one with my picture on it was 614kb. After I did my own bit of compression by reducing the pixel size, it fell to 65kb, which increased the speed a bit:
Frankly I can live with that! 🙂 Course, now I need to go back and alter images that I uploaded on my own. I’m also learning a bit about image quality and how, if my initial file isn’t all that big to begin with, once I compress it the quality drops somewhat drastically (look at the images on this post; they’re all small now but they weren’t all that big before I compressed them).
It seems all this stuff works pretty well, and now I have to go to my other blogs and complete all the things I’ve done with the first two, and if I can get them all into the 80 range I’m going to be a pretty happy guy. However, I have some caveats for you:
First, if you make changes to your .htaccess file and your main page stays but your individual posts go missing, all you have to do is go into your Admin area, Settings, permalinks and reset them.
Second, make sure you save your originals of everything in a place where you can access them in case you need to remove some code that’s not working if you already have that file. As a matter of fact, save everything you’re going to touch, both before and after stuff.
Third, realize that not everything works for everyone. Just like I said about the Async JS plugin above, the recommended settings removed all my content from the web (my files were still intact but no one would have been able to see anything) so I had to test and modify to find something that worked for my blogs.
Fourth… don’t kill yourself shooting for 100/100 for everything across the board because you’ll never sleep well again. I turns out that the two separate links from Google for checking mobile speed don’t even agree all the time; what’s that about? Truthfully, “fair” is probably pretty good, but the higher you can get your score without going overboard the better.
Fifth, image compression the easy way can be achieved by shrinking the pixels of some of your image files if they’re overly big yet probably won’t change how they look on your blogs or websites. If you have any images over 600 pixels on your website or blog, those are going to hinder your speed.
Sixth, if you use WPTouch, you might need to go back into the settings and fix your phone theme colors once you do all this stuff. I had to do that because it made my backgrounds white with all print black until I did. I’m not sure what changed it but it’s an easy fix if you need to correct it.
I’ll stop here because this might boggle some minds. I’ll answer what questions I can because I still have a lot of work to do. The lucky thing about blogs is that once you alter the CSS files and the Header.php file it takes care of all the previous posts going forward. For a website however, you have to make the header change on each and every single page; ouch! Still, it’s better to have a solution that works and only takes modification rather than still trying to figure it all out… at least that’s how I see things.
Respect!
That’s some mad testing skills, Mitch. I know I won’t be doing all that. Screw Google. LOL
Cheers,
Mitch
LOL! I’d love to say that but acknowledging that they might be right in the need for speed has eased my mind just a bit.
Hi Mitch,
You sure tested things with a fine tooth comb. Wow…you really worked out those kinks.
When it comes to speed, if we don’t have it, people won’t wait for a download, especially if they are using their phones (which many do)
So I would say that all this that you have done is very important. On my main blog it is a managed host, so if my speed slows down for one reason or another, I get a text message from my provider. Then I need to go on a quest, but not as elaborate as yours.
I am impressed!
-Donna
Thanks Donna… but you know I didn’t stop there. I wanted all my sites to be in the “good” category for speed and I’ve gotten all but one there… though the one I got this evening meant I had to totally recode that website. This means there will be one more blog post about what I’ve been doing, but after that… well… whew! lol
Mitch – I think running a speed test is really important as it is something that Google looks at when determining where to place your site in the SERPs. It’s something that we looked at BEFORE making our site – so how big are the images, should we just link to YT videos instead of embedding them – does that make a difference etc…
Your job in testing was super thorough – not seen anything like it before and I spent a fair bit of time trying to make my site and figure out what’s best for ranking it etc. Great job and very useful, many thanks! Jess
Thanks Jess. The thing is that all my sites are old and built way before mobile was a thing. I’d know a lot better now but it’s what’s made me put in all this time and work to try to increase their speed. It’s hard enough trying to drive traffic via social media marketing without having Google fighting me on the other front… the weasels! lol
Great post Mitch! I appreciate all the work and research you did for this post and definitely found some good resources to help me in my blog research. Look forward to reading the rest of your series!
Then go take a look because it went live about 2 hours ago 🙂
Google Sucks…it tells me to set up compression when I already know that I have it set up and tested to see that it works.
It also tells me to optimise my images which I know are optimised. The only ones that aren’t are the affiliate ones and I don’t have any control over those. Why they don’t use optimised images is beyond me.
As for leverage browser caching, I’ve tried several plugins that claim to do it and none seem to please google so once again, GOOGLE SUCKS!!!
LOL! You’re killing me! However, only part of this can be blamed on Google because other speedtests talk about the same stuff. Then again, only Google seems to be penalizing us for it lol. I’m going to get it all figured out though; I must!
I’m slowly changing all my affiliate ads so That I’m hosting all the ‘optimised’ images and substituting all ads that us java script. Once all that is done I’ll see if it makes a difference.
I expect it will. Gotta watch some of that javascript stuff though; don’t forget to try that “async” entry into the code.