WhiteSites Blog
WhiteSites Blog
Today Google Rollled out their Mobile Penalty to any website that did not meet their new guidelines. These guidelines meant your website must resize and mold itself to fit the screen on mobile devices, without having to use the pinch to zoom as a way to navigate around. Many of us webmasters thought we were ahead of the curve and had our websites ready weeks before this penalty went into effect. We anticipated April 21st as the day when our websites would jump to the top of google simply because every other website did not update to be mobile friendly. So Today when all my sites didn't rock the top spot on google I had to do a little more digging into the cause.
As long as your website is built using a external referenced StyleSheet ( CSS ) the update is usually pretty simple. It took me anywhere from 6 hours to 14 hours to get each of my client's websites updated to be mobile friendly. By using media Queries in your CSS which are special class rules that only are loaded when the screen size is over or under a specific dimension you are able to make your website look great no matter what size screen the device has.
What I found this morning was things go further than just some CSS rules. Page load times, also make a huge impact in if google determine's your website is mobile friendly. The following are a few things to keep an eye out for, and fix if possible.
If you use PNG graphics on your site, be sure they are exported correctly. I use fireworks to do most of my website graphics and layouts. In Fireworks you can save a PNG as a fireworks PNG which will have all your layers and objects still there to edit later. But these files are very large. What you want to do is export your PNG files from fireworks. This will flatten them and take out the overhead of storing the object data. Then once you have exported your PNG files you can upload them to your server. DO NOT upload your Fireworks PNG source files to your website. This is one mistake I made, and corrected this morning. The result was a 90% savings in the amount of data from these graphics.
Cache headers tell browsers how long to hold onto data before checking for new versions. This helps to reduce redundant requests for the same data over and over again, and will make pages load much faster. This should in setup for all static files. I setup My Cache headers to expire after 7 days for Static files.
Text based files like JS, HTML, CSS compress very well. If you enable Gzip compression on your server this will compress this data before sending it to the clients. This ads a little bit of CPU overhead, but if your server is like mine, your CPU usually sits under 15% usage most of the time. Its a balance between what is faster. Sending 200 KB of uncompressed data, or compressing it to 30KB and sending that instead.
If you are like me you like your JPGs to look clean and set your quality to 85% or 90%. Turns out Google would rather you set them to be around 75%. I noticed when using Google's Page Speed Insights tool, they told me I could shave a few 2 KB off a specific JPG image. When I checked that image it was already at 76% qualtiy. Taking it to 75% got it under the threshold Google was looking for.
One thing I noticed was that google was marking pages on my sites as not mobile friendly, though everything looked good. Upon doing a test with Google's Mobile Friendly Test Page, I noticed that somtimes the page would load in a text only format, with no CSS styling. If Google has trouble loading external CSS files then it won't be able to style your pages correctly and determine its mobile friendly. The problem turned out to be the way the Document HEAD works. Everything in the Document HEAD will be loaded before page rendering starts. If you have tons of external files in your document head this could be a problem. Google kept telling me that my CSS file might be a little large, and I should load specific rules inline for above the fold rendering. To me this was not the correct answer. The idea that I should not contain all my CSS into a single stylesheet was not logical. Turns out the problem was not anything on my server, it was Third party hosted elements. The problem was not my CSS, the problem was I had my Google Analytics code in the HEAD of my document. This meant that before the page would load, a ping to Google Analytics would have to happen first. This caused a delay in page load times and google was not able to load my CSS in time for rendering. I moved my Google Analytics out of my Document HEAD and now google is happy with my pages.
After going through the PageSpeed Insights tool several times, one thing was apparent. Google did not have much love for any of my Like Buttons. Very few people actually click them, so my solution was to just remove them all together. They were causing slow page load times. Getting ride of them made a considerable difference. I may try to add like buttons later, but this time they will be static, and not dynamically loaded with counts.
Thus far I see this as a positive thing. One of my clients went from 12 on google places to 2. Others have jumped to the top 3 spots. I don't think google is finished yet though. I still see some sites ranking high that I know for a fact are not mobile friendly.