The Quest For Mobile Speed, Part Three
Posted by Mitch Mitchell on Aug 29, 2016
Whew, I’m tired! This will be the last installment of the quest for mobile speed, even if later on I may write about something new I’ve discovered. It’s finally time to end this journey, which has taken on a life of it’s own. The previous quest for speed post was pretty epic; I expect this one to be much shorter… then again, what do I know? lol
This time around I’m adding two of my business websites along with talking about the blogs. I still have one website I haven’t addressed, mainly because I still haven’t figured out what I want to do with it. This still means I have 7 web properties to talk about. First, take a look at the numbers from the previous post because I’ve improved on all of them:
Not bad right? I’ll take a moment for myself. 😀
That’s over. The way I’m going to do this is to first mention things I learned and had to change up from last time, which of course means I’m going to start by talking about the WordPress blogs.
The first thing I had to change was the coding I used for compression. I mentioned that I had been working towards something called GZIP compression (link in the last article) and I posted code that I said boosted my blogs up slightly. Well, it turns out there’s two types of compression, GZIP and Deflate, and it all depends on the host as to which one will work for you. My host, 1&1, doesn’t use Deflate, which explains why the code didn’t work properly.
With more research I came across this code, which I put into my .htaccess file:
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
< /ifModule >
With this code, I finally achieved speed ranks over 85 on most of my blogs. The others were close, but this was a major step. I was now into the area of tinkering, but I could handle it. By the way, remember to remove those spaces in the tags, which I had to put in so it wouldn’t start coding this post. lol
The next thing I did I owe to Brenda Pace… or to whomever it was that shared her link on Twitter talking about WP Smush for images. I had previously talked about Zara 4, but you had to pay to go over a 16MB limit. This plugin does have a pay component, but for most of our needs the free version works wonders.
Any images you’ve uploaded to your blog it will reduce for you, which speeds things up. My mobile speed jumped nicely for individual posts, which was pretty cool. However, it couldn’t affect everything because of my use of Compfight, which I mentioned last time. Since those images don’t reside on my site, I can’t reduce them, which explains why two of my blogs are still in the Fair category as it pertains to my desktop speed. This means some posts are faster than others; just something you should know.
Another issue that kept cropping up talked about some stupid Google fonts that I didn’t even know existed, because I don’t remember ever adding them. Turns out I didn’t; for some reason, there’s a link contained in at least one of the WordPress PHP files that we can’t get to. Almost all the research I was doing pointed to a plugin called Disable Google Fonts. That sucker didn’t work for me; instead, I found one called Remove Google Fonts References that got it done and that helped speed.
At this point anything else I did was just tinkering, and I decided instead to tackle the websites instead. These brought their own challenges, thus they’ll make up the bulk of the rest of this post, although some of these things will also work on your blogs if you’re in the mood to do them.
Let’s start with my main business site. Back in November I mentioned that I’d had to remove HTML table coding and that helped the site move faster. I’d only done it for a few pages, so now it was time to tackle all of the pages, which meant a lot of copying and pasting and testing. Overall it was pretty easy stuff to do, but I ran into things that I still can’t fix.
One thing I was able to do was what they call “compressing CSS”, which in essence, means you modify your code to strip out stuff that you really don’t need, which is known as “minifying”. I went to this site, pasted my CSS code into it, and it spit out tighter code, even if it looked ugly. It worked in speeding things up a little bit so I took it. Hey, I’m at 90 for mobile and 96 for desktop; I’m ecstatic!
Thus, it was time for my medical billing site, and this one took lots of time. Nothing I was doing to it would improve my speed or desktop score, and it was irksome. Then I finally realized what the issue was… too much HTML. This meant I had to recode the entire site, using CSS; ouch!
I hadn’t built a totally CSS site in 6 years, so I had to brush up on it. Not only that, but if you look at the site you’ll see that the menu is on the left side. The only coding I’d ever done before this put the menus at the top, which means I had to do research on how to get it vertical. Then I had to tinker and tinker and tinker some more until I finally got it looking close to where I had it previously.
It was ugly and time consuming, but I finally got the main page right. Then I did another page and things still looked good, so I went to bed. Next morning I started on all the other pages… and it turns out some of them worked well and some didn’t. Truthfully, almost all my sites want me to tweak these particular issues, but on some pages it’s enough to keep your speed from reaching good:
The file it says needs rendering is my CSS file, and so far nothing I do is eradicating the issue;
* Prioritize visible content
The problem here is that I use Adsense on these pages and to keep the code where I want it to be for some of it means I need to use some HTML, and that particular bit of HTML drags down the speed, and there’s nothing I can do about it. The funny thing is that one of my pages, which talks about Medicaid, doesn’t have any HTML on it, so I have no idea what it’s looking for me to change (well, that’s not quite true, but the HTML that’s on it is near the bottom of the page, and this talks about stuff that’s “above the fold”…;
* Leverage browser caching
This one is irksome because it depends on some code that, for some reason, worked on the blogs but doesn’t work on either of my webpages. This is that code, which goes in the .htaccess file:
# Enable expirations
# Default directive
ExpiresDefault “access plus 1 month”
# My favicon
ExpiresByType image/x-icon “access plus 1 year”
ExpiresByType image/gif “access plus 1 month”
ExpiresByType image/png “access plus 1 month”
ExpiresByType image/jpg “access plus 1 month”
ExpiresByType image/jpeg “access plus 1 month”
ExpiresByType text/css “access plus 1 month”
Just so you know, depending on your host, you might have to put in “defer” instead. Either way, it works; shocking right! 🙂
One final thing. It seems that if you’re linking to other content, whether it’s on your site or not, and you’re linking a bunch of things in one paragraph, it’ll reduce your speed for that also, saying things are too close together (I can’t remember the actual words but you’ll know it if you see it), in which case I just removed a few here and there to add some spacing.
I think that’s enough of that. I’m done talking about it for the longest while, and I’m telling myself that I’m done working on the problem for a while as well. Of course, if you have questions I might be able to answer go ahead and ask. Next week, back to fussing about stuff! 😉