Posted by Mitch Mitchell on Sep 21, 2016
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.
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.
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
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 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… 😉
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! 😉
Posted by Mitch Mitchell on Aug 22, 2016
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.
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
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
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.
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 thearea 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 thearea, 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 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.
Posted by Mitch Mitchell on Aug 15, 2016
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.
I finally have a solution, it works every time, and I’m going to share it with you. The thing I want to tell you up front is that you have to be willing to either do some work on the back end or just ignore a few things here and there, but it works, it works every time on every blog or website… at least if you use Firefox, and probably on Chrome also.
One, you can decide to either temporarily allow a site or permanently block it. You can always remove the permanent block in the extensions settings but I’d think hard before doing that. I’m only blocking a few sites, those being Forbes & Inc, which makes you turn off your Adblocker before they’ll let you see their content. I figure I’m not doing that, so why even keep me on their sites, right?
Two, you can decide you want to whitelist a site because you visit it often and trust it. In that case you highlight the address in the address bar, go to the extension in your browser and click on the options button, go to the whitelist menu, paste the address in and push Allow. When you go back to the site you’ll see the page as you expected to see it.
Of course there are some sites automatically whitelisted. Those include Google and Facebook. You can decide to remove those if you wish but why would you unless you’re never going to use either of them. 🙂
This extension is only for Firefox. Chrome has its version of the same extension called No-Script Suite Lite, and it does the same thing as No Script does for Firefox. The only reason I’m not adding it to Chrome is that I don’t use Chrome that often, and the only time I actually do is when I want to see some Flash content that Firefox won’t show (I removed Flash from my computer last year) and, for some reason, Chrome shows it. However, if you add this script you might have to either temporarily or permanently whitelist the site so you can view Flash content.
It took me a while to find this but I finally did. I’ve been talking about this irritation since 2008 when popups were in their infant stage and now I can breathe freely once more. Some people might say this is an inconvenience and yet many people are using Disqus or other inconveniences on their blogs which includes Captcha and moderation of comments; this proves we all have our bugaboos. If anything, this will allow me to share more content because now I won’t know which sites have popups on them, so it won’t be my problem anymore, and it won’t be anyone else’s problem if they decide to add either of these extensions.
Posted by Mitch Mitchell on Aug 8, 2016
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.
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.
It turns out that at the beginning of May is when Google decided to look at web sites and determine whether they were mobile friendly or not, which I thought I was totally prepared for. I had gone through a lot of work to make sure that all my websites were mobile friendly, and I had even checked them against this Google page that indicated that all my sites were mobile friendly. So what was the issue?
It seems mobile friendly isn’t the only thing to worry about. The other thing we have to worry about is mobile speed. I hadn’t paid that much attention to mobile speed because all everyone ever talked about was being mobile friendly. When I checked all my sites against mobile speed, even though they all still came up mobile-friendly, my mobile speed was around 60/100. It turns out that’s considered a poor mobile website; who knew?
I’m one of those people who is at least a little bit tech savvy. I’m also a pretty good researcher, so I did my thing and started doing all this research, then started finagling with code to try to get the mobile speed up to par. The problem was associated with compression, though initially I thought it might be a problem with image sizes. However, since my blogs won’t accept large files, I didn’t think it was that particular issue. It was associated with something called “gzip compression”; I don’t fully understand it but it didn’t mean I was scared to try to correct the problem.
At one point I actually succeeded in getting my mobile speed to 100/100, and thought that was pretty fantastic. However, two things happened. The first is that my mobile friendly went down from 100/100 to 72/100, which is only considered fair. The second is that all my websites suddenly had internal server errors; that wasn’t good.
I had to go back and remove all the new code that I had added to both php.ini and .htaccess to get my websites back; whew! Once that was accomplished, I dabbled around with the code for a longer period of time, finding more examples during my search including on the 1&1 site, which is where I host my sites.
After almost 3 hours I decided it was time to call 1&1 to see what they might offer. The recommendation that was on their site was from 2014, so I thought maybe it was out of date.
I spoke to the lady who told me she would send me a code I should add to .htaccess. When I got the code in the email it was the same code I had already tried. I wrote her back saying it didn’t work, gave her a screenshot of the Google test as well as other information that I had in both php.ini and .htaccess. After I hadn’t heard from them in a couple of hours I decided to go to bed (it was close to 2:30 in the morning after all lol).
Sunday morning I checked email and found that the reason none of what I was doing would work was because I was on a package that was 10 years old and they hadn’t just rolled it over, which seems like it would make sense until I realize that neither the phone companies or cable companies would do it automatically either. In essence, nothing I was doing was compatible with what everyone else might have because I’ve been with the same package for too long.
Sunday afternoon I finally made the call to 1&1 and, after having all my questions answered, I decided to upgrade my package. Here’s the funny thing though. Upgrading my package is costing me $0.13 more a month. Also, for the first year I’m getting it at $6 less than what it would normally cost, and they have to give me a prorated discount because they had just taken a payment against my credit card last week so they have to apply that to the new package. In essence, this means for the first year I will be paying them just under $50, and after that it will be $14.99 a month, which they’ll bill in one shot as opposed to the quarterly billing I’ve been paying. Not only that, but with the new package I won’t be paying $5.99 for extended PHP support, which I was paying because my sites weren’t compatible with the latest PHP under the old package; sigh…
Supposedly it’s going to take 3 to 5 days for everything to be working properly. After that time, it’s my expectation that I should at least be close to 100/100 for everything since compression will automatically be on via the hosting company. Hopefully this will result in a turnaround in my stats, although since it took 4 months for it to fall this far it just might take the same amount of time to get it all back… but I’m hopeful.
I tell this tale because I’m betting that some of you have been going through some of the same things I have. If you have exhausted all of your options and you’re still having issues with your website as it applies to being mobile friendly, you should check with your host to find out if your on a proper package that will help you take care of this issue. If only I had known back in May… sigh…