My Quest For Better Mobile Speed; Things I Can’t Figure Out

I know I said 4 weeks ago that I was done working on increasing the mobile speed of my websites. Actually, what I said was I was done for a long while… I’m thinking 3 weeks is a long enough “while” so I’m coming back to the fold to talk about it once more.

Speed ahead
SprinterJockey via Compfight

The thing is, there are some issues that I just can’t solve, and all my research isn’t answering any of it. I’ll own up to seeing a lot of solutions here and there, but I have to add that none of them either make any sense or don’t work.

One other thing that’s happened, at least for one of my regular websites, is having pages that are slower than other pages when the content is literally the same, and the page speed error messages are the same as well. Why does one page pass the test when the other doesn’t?

All this and more follow, but I want to mention the two reasons I’m putting this one together. The first is to show other people who might be fighting these issues that they’re not alone. The second is hoping that someone with some “real” knowledge will pop in and explain what some of these things are and how we might actually be able to fix them.

1. Eliminate render-blocking JavaScript and CSS in above-the-fold content

This one is at the top for my regular websites. For both sites, the issue is the CSS file, since I figured out how to correct javascript. There doesn’t seem to be a way to defer CSS files loading, and supposedly what this means is that we should put most of the code we have in a CSS file into the actual pages.

That’s fine, except… that’s the reason we’re using CSS in the first place, so that if there’s a change we want to make to affect all pages at once we only have to put it in one stupid file! All the research I did said to first try to minify the file (which means clean is up; there are lots of pages that offer links that will do it for you) but even after doing that it didn’t change my speed any. The second recommendation was to leave it alone and just thumb your nose at Google. Since I can’t find a better fix to this issue that’s exactly what I’m doing… but it’s unsatisfactory.

2. Leverage browser caching

This one recommends setting what’s called expiry dates to certain types of files, where the intention is to tell the browser of your visitor whether it needs to actually download those files to the browser again if you’ve already visited the site within a certain period of time. The site I linked to actually gives you the code to add to your .htaccess file, which I mentioned in the last page speed post, only… it doesn’t work!

I’ve tried changing some of the numbers. I’ve tried converting some of the numbers to the number of seconds those numbers represent (which was another recommendation). For whatever reason it’s just ignoring that code, and in all the research I’ve done I have yet to find even one person who might have an idea of why it doesn’t work… and lots of other people who have said it doesn’t work for them either.

3. Reduce server response time

IMG_20160712_094226
Need this to calm down lol

In essence, this one is blaming the host you’re using for your websites. The recommendation is to track it to see what’s going on and then… fix it. FIX IT?!?!? How do we do that? I actually called my hosting company and eventually hung up because they had no idea what I was talking about.

I could blame the hosting company but my research has shown that no one else has any real idea how to do it either except to change hosting companies. Let’s be real here; why the heck would most of us want to keep jumping around to hosting companies just to see if this possibly works?

4. Prioritize visible content

This is the strangest one. What it tells you is that you have issues with your HTML that it supposedly can’t render completely the first time around that’s above the fold. This one is problematic for two reasons.

The first is that, at least for me, the two things it’s telling me it’s having a problem with is my main image and some Google Adsense code. On the first, I’ve reduced the image and don’t have any actual HTML around the image, so I’m not sure what to do about that, especially since the entire code is actually way above the fold since it’s at the top of the page.

The second is that, even based on all the research I’ve done, they really don’t tell you what above the fold means in this particular context. For instance, on the page speed screen it shows you what you believe is the above the fold area. Yet, all the research says that’s not quite the above the fold Google’s talking about, and the only way to figure it out is to go step by step, testing each little change.

Not only do I NOT know who has the time to do all of that, but on one of my sites I totally eliminated the HTML for the content, going totally with CSS content. Unless CSS is now also HTML, Google’s gone bonkers! lol

One last thing. For my medical billing site, I actually removed both the image and the two places where I have the Google Adsense code just to see how much my speed would improve… and it didn’t improve! What the hey? I also took a different page, saved it as something else on my computer, and copied just the content of the page that’s dragging into it; eureka, it worked! That is, until I changed the Title of the page to what it should be and the title on the page for what it was supposed to represent… all broke once more; sigh…

5. Size tap targets appropriately

This is another one that’s kind of goofy. What this supposedly means is that things you want people to click on, whether it’s a menu item or links to other pages within your content, are too close for mobile users to get to easily enough.

On my main business page it’s telling me that the menu items are too close to each other. Unfortunately there’s little I can do about that because the menu was created for me 13 years ago by my friend Kelvin, and I rarely dig into javascript code to make changes because I don’t know the ins and outs of it (although I did go into it to make a menu correction; I was proud of myself when it worked).

On my medical billing site, the content it’s telling me is too close to each other is, once again, within the Google Adsense code. I mean… really?!?!? What the heck am I supposed to do with that? By Google’s own terms of service you’re not allowed to mess with their code, and one would assume that if they’re going to report on themselves that they’d fix themselves while they were at it. Then again, why expect common sense from Google when Warner Brothers has reported their own site for stealing their content? Sheesh! lol

Those are the top 5 things I haven’t been able to figure out. I’ve actually figured out almost everything else, which is how I achieved the speeds I did. One last thing though; I want to reiterate that, though those error messages above keep popping up, they don’t seem to affect all my pages the same… even though the structure of all the pages is the same. I think I need a computer Sherlock Holmes to figure it out… or maybe someone out there much smarter than me who’ll see this post and stop by to help. We can only hope… 😉
 

Digiprove sealCopyright secured by Digiprove © 2016 Mitch Mitchell

The Stuff You Haven’t Been Told About How To Make Your Website Mobile Friendly

Back in May I wrote a post talking about trying to make my sites mobile friendly. I shared some links in that post where you can check to see if your sites are ready for mobile or if they need some work. I also had a few gripes in that post; that’s because no matter what I was reading, I just couldn’t figure things out.

code101

At least my blogs were all fine, thanks to WP Touch. I use the free version because I don’t need all the bells and whistles that come with it, but it’s a fabulous program that helps WordPress blogs become mobile friendly. If you’re not using this and aren’t mobile friendly, it’s a plugin you need to check out.

For the rest of us… well, it’s basically taken me over 5 months to finally figure out what was going wrong with all that I’d been trying to do to get my sites mobile compliant, and when I finally figured it out, it turns out that the information wasn’t on any of the websites I’d been reading. So, I’m going to address some of what I discovered on my quest; some is on other sites, some isn’t, and some wasn’t explained fully. These won’t be in any particular order, but I’ll number them in case there’s some you already know and some you don’t.

1. Table coding structure

Do you see that code above in the image? All coders know that, except for a couple of enhancements, that’s the basic table coding structure for websites. This particular snippet is the code I use when I put images on my blog posts, whether they’re mine or whether I’m using the Compfight plugin, which finds free images that are allowed to be used via Flickr and Creative Commons.

Anyway, most websites use this structure to put their websites together, whether or not they also use CSS (cascading stylesheets). At least they use it as an initial basis because it’s stable and helps lock many elements into place.

The problem as it concerns mobile comes when you’re designating specific sizes that might be higher than what mobile will allow in general. I’m one of those anal types who usually set my initial tables at 90%, which means that my content would spread out over 90% of the space on someone’s monitor. I’ve always thought that helped things look pretty cool… but it turns out that it ends up fighting anything you try to do with mobile. It’s the reason this code I had found, meta name=viewport content=”width=device-width initial-scale=1″, wouldn’t work on any of my sites; ugh. What I decided to do was take out the width connected with my main tables. That helped a great deal… but there’s more (as always lol).

On some of my sites I was using the Google box ads. To make them format within my content I used the same table code.

On my medical billing site, the size of the menu on the left side and the size of the table in the content made the mobile version too big. I couldn’t shrink the size of the menu, so I had to remove the box code. That brought the pages on that site that I altered into compliance, and instead of fighting to keep the side box I switched to a different code… which I’ll come back to later.

On my main business site, I totally removed all secondary tables and went back to original coding instead, using the main table only and breaking the two columns up by using the

tag. I also altered the size of the two columns by making the width of the first td tag to 15% and the second one to 50%. I needed to go with the 65% because on that site I have two images up against each other, and they wouldn’t show properly if I reduced the size of the columns more.

2. Logo images

If you go to the page that talks about speed, it’ll recommend that you reduce the size of your images so they’ll load faster. What they don’t tell you is that you might need to reduce the width of your images as well for true mobile compliance.

On my medical billing site, the logo was 793 pixels; on my business site the combined size of the two images was around 850 pixels. That’s way bigger than the allowed size for the initial mobile size, thus you’ll never be mobile compliant that way. Although I loved the way the larger images looked, I knew I had to make a change.

Screenshot_2015-11-02-00-41-02

For the medical billing site, I reduced the width of the image to 400 pixels. On my main browser it’s definitely smaller, but still looks pretty cool. On my business site, I went a totally different direction and changed the height to 100 pixels for both images. It reduced the size of them both enough so that they would be compliant. The only problem I have is that if you look at it on the phone lengthwise the first image sits on top of the other one but I can deal with that because one, I doubt many people will be looking it up on their phone (maybe the blog), but two, if they’re like me they’ll probably turn their phone sideways, where they line up properly.

3. Google code

If you read that previous post, you will have seen my little rant that one of the issues turns out to be Google’s own stupid code. The code size that always worked the best was the 728×90 ad, which one normally put at the top of a page. Well, that 728 is way too big for mobile phones, so it looked like Google wasn’t giving us a choice of what to do.

Turns out they had made a relatively recent change that I didn’t know about, that I learned of from Lisa Irby’s YouTube channel, where she was talking about responsive ads and how one of her friends had doubled his income since switching. I don’t know about all that, but what I discovered is that if you use the responsive ad, it alters its size based on where people are viewing it. So, if it’s on their home browser they’ll get a big ad, even bigger than the 728, and if it’s on the phone and people aren’t blocking those ads they’ll show up perfectly for them and as big as they’re allowed.

I tried this out on my medical billing site and it works wonders! However, remember earlier when I was talking about using the tables for the ads within my content? For some reason the responsive ads won’t work if confined, and the table made the overall size for the phones being viewed lengthwise that it took them out of compliance. What I’ve done instead is killed that side box and put a second responsive ad at the end of the content. Since I was only running two ads on each page, and hopefully people are reading all the way to the end of those articles… all should be good long term, and I’m still mobile compliant.

4. Viewport code

Remember that viewport code I shared above? I had a couple of pages where I was having trouble with it in that form. The Google insights page kept saying to use the code as given; forget that mess. Most of today’s smartphones will handle a width size of up to 525 pixels, so what I did was alter the code and make the width 500. I had seen this figure altered on a couple of pages I visited while trying to figure things out. However, what none of them did that I did was to leave the second part of that script in there, the initial-scale part. For some reason it helped bring everything together; I can’t explain it but it worked. 🙂

By making all these changes, my pages were suddenly mobile compliant; yay! That doesn’t mean they’re perfect by any means. If I put the code into the insights page, it keeps finding recommendations to make to try to get to 100%. However, the main thing we all want to achieve is compliance, since that’s the thing Google is penalizing some of us for, and these changes overcame that.

To think, it only took me 5 months! lol Hopefully, if you’ve run into any problems this will help you solve some of them. I still have a ways to go to get to all the pages on those two sites, and I have one more site where the coding was so intensive that I’m going to have to do something drastic with it… but at least I now know what needs to be done… and you do also. 😉
 

Digiprove sealCopyright secured by Digiprove © 2015 Mitch Mitchell