Anyone who reads this blog knows that the biggest issue I have with many blogs these days are newsletter subscription popups. Although I hate them with a passion, I didn’t mind as much when they showed up at the bottom of the content. My gripe was always that the popups came without giving us the opportunity to even know whether or not we wanted to subscribe to any of the content, and my solution had been to try to never go back to those blogs ever again.
That turned out to be futile. I like sharing other people’s content but when you’re on Twitter, you’re rarely sure where a link is taking you. So I’d often end up on blogs I said I wasn’t going to visit again because of the popups, which was irksome because the topics seemed like they’d be really good. Continue reading How To Block Newsletter Popups From Blogs→
I was looking at my site on Saturday night and I noticed my Alexa rank. Even though most people think there’s no use for Alexa, it turns out there is. and it scared me. I noticed that my traffic had dropped drastically and I wanted to see what the issue might be.
Friendly vs Speed
I looked at my Google Analytics and noticed that for every single one of my websites my traffic had dropped drastically around the beginning of May. I thought that was strange and I wasn’t sure why that was happening so I did some research. Continue reading Mobile Friendly Versus Mobile Speed→
I have long been someone who’s believed that the more one writes on their blog, the more traffic they’ll get, the higher their blogs will rank, and the better opportunity they’ll have to be more popular across the board. That certainly used to be true; back in the days where I was writing more than 300 posts a year on this blog it was very highly ranked. Once I slowed down, my ranking dropped, which has happened to all my long time blogging friends who have reduced how much they put out.
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.
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.
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. 😉
Ever since Google and a couple other search engines decided they wanted to rank websites that they consider mobile friendly higher than other sites, people like me have been tearing our hair out trying to figure out how to get there. I can tell you it’s not easy at all.
For those of you who haven’t heard about this or don’t understand what it means, let’s talk about mobile friendly sites for a quick minute.
It seems that more than 55% of all web traffic is now being performed via some type of mobile device. This means smartphones, tablets, readers, etc. It doesn’t mean laptops or notebooks and definitely not desktop computers.
Mobile friendly for the specific items I mentioned means that if someone pulls your website up that it’ll load fast and look like it was designed for a mobile experience since the screens are smaller than what some of us are traditionally used to. Strangely enough, it’s their expectation that the website needs to look good if someone’s looking at it on their phone vertically, which means the long way, rather than horizontally, meaning you’re looking at more physical real estate.
Frankly, I’m a horizontal viewer whenever I need to use my phone to look something up. It’s easier to hold my smartphone in two hands and easier to type that way. I might search for something vertically, but once I pull up a site I always move horizontally because it’s a better viewing experience in my opinion.
Never mind that for now I suppose. Let’s look at trying to get one’s site mobile friendly.
You’ll get some kind of score. If you’re already using something on your blog to make your site mobile friendly (I use WP Touch) then you’ll probably come up as being friendly, although some people say it’s not 100% effective; I’ve done okay so far. If not, the most common issue is the font, in which case you just go into the plugin and select one of the supposedly favored Google fonts and get on with life.
If it’s your website… you’re probably in some kind of trouble. Google will give you a score, then they’ll give you links that you can click on to refine what your issues are and give you a chance to fix them.
I have three static websites, and none of them are compliant. However, by working on some of these things all of them are at least 80% compliant, one of them at 93%. However, there are issues, which I’m going to point out and, maybe, some day someone will be able to help me get around them because so far the advice has been the same but none of the fixes have worked.
Before I go too far, let me tell you that size seems to be the major issue overall, as in how it will look on a smartphone if you’re looking at vertically, as I mentioned above. This is how they begin scoring you; after that it’s speed.
The biggest recommendation I kept getting was to add this code into the header: meta name=viewport content=”width=device-width initial-scale=1″. For every one of my sites, when I put this sucker in and tested the site again my score went down. So, instead of using this I started experimenting with different widths. I tried going larger first but it seems bringing it down in degrees works better. On the site I got to 93% I changed the width to 400; system assumes it’s pixels so I didn’t define it further than that. Eventually I tried taking out the “initial-scale=1” part and there are no difference in score at all.
The next thing is your fonts. For all my sites it kept telling me that the fonts were too small. I kept changing the pixel size, by degrees of course because you don’t want your site looking goofy; they say they don’t want it looking strange either. They recommend making the size 16px; only on the site that I got to 93% did it make a difference; not sure why it didn’t work on the other sites. Still, it’s something to play with.
After that you might have to do something with your logo image if it’s a large one. On two of my sites the logo is larger than 320px. If you try shrinking your logo it looks stupid; trust me on this one. However, the fix that was recommended that raised my score was to not put a “restrictive” size on the image. Instead, make the width 100%; it allows the phones to resize it somewhat… I’ll get back to this point later.
The final thing… do you run Adsense on any of your sites? On the site I’m getting the 93% on, my lingering issue has to do with my Google Adsense code. At first they were griping because I wasn’t using what they call an asynchronous version of their code. Turns out they changed their codes somewhere along the line; totally missed that.
So, I went back and changed the codes on most of my sites. The top code size is 728×90, which is one of the highest converting codes Google’s ever put out, and works well on my site (this is my medical billing site by the way). Guess what… Google hates that size! That’s the last thing it wants me to fix, and it’s their code!
Come on now; that’s just not fair! It’s still a code choice in Adsense, which means their own code isn’t mobile friendly. Thus, they’re going to penalize me and lots of other folks for using their own code; tell me that’s not the stupidest thing you’ve ever heard! Sigh…
Not only that, but when I looked at each of my websites after making the changes… vertically they all look stupid. Horizontally they look a lot better, and one can resize as necessary to read easier, especially with the larger phones.
Thus, my contention that trying to go mobile friendly isn’t a friendly process whatsoever, and Google is a big part of the problem. Trust me, I’ve researched this a lot and most of what I’m seeing either keeps recommending things that don’t work, like what I’ve mentioned above, or talks in riddles with language I just don’t understand. Many recommendations are to totally change your design, with an understanding that a lot of small businesses (me!) might not be able to do it for a while.
My saving grace? On two of my sites I have blogs attached to them that are mobile friendly. So, I shouldn’t take a big hit if I take one at all. The other one… I’m not really worried about it yet, however it’s the one site that just might need a total redesign because I built it in a very complicated way. I like it, but it’s never done what I wanted it to do so if I have the time it just might need some major reworking.
That’s my tale and my sharing… as much as I could. What have you been dealing with, if you’ve bothered to deal with it? I know my buddy Pete changed his sites over to WordPress so he could run the mobile app. I don’t have that luxury unfortunately, as I’m running a couple of scripts that I couldn’t run with that software. Anyway, share your thoughts on all of this; I need a cookie!