Responsive layout and Google tools

Has your site started to lose positions in the search results due to a change in the ranking algorithm for mobile devices? Don't know what to do and where to turn? Google to the rescue!

Google site customization tools

To solve the issue with adaptive layout, Google offered 3 tools. Consider them:

Mobile Friendly Test. By testing the site with this tool, Google determines if the resource is optimized. The test checks for the following:

• Is there a viewport meta tag that indicates how the page will be scaled to fit the screen size of a mobile device.
• Font size. Should be readable.
• active elements. The size of the elements that the user clicks on is important here.
• Gaps between active elements.

The service is very simple in operation: enter the url-address of the page in the field, it scans it and issues its comments.

Another service, it is built into the Google Webmaster Tools. It is essentially similar to the previous one, Mobile-Friendly. The only thing is that he bypasses all the pages of the site himself about once every 3 days. Similar to Mobile-Friendly Test, after scanning it will issue its comments.

Page Speed Insights is the third tool offered by Google. It can be attributed to an auxiliary tool. It looks for mistakes you made while optimizing your site when you are trying to speed up page loading and rendering.

When checking a site, it first uses the mobile user agent and then the desktop user-agent. The result is issued by an assessment (on a scale from 2 to 100).

JavaScript - problem solved

Requests to move all JS elements have been around for a long time. And now, going into the settings of the main module, and checking the box, you can move all JS elements to the end of the page. Let's see how it works.

When the checkbox is activated, the system moves all the JS elements on the site down and places them before the </body> tag. The order of the code being moved is completely preserved. According to statistics, 95% of pages do not lose their working capacity.

If there are scripts that do not need to be moved, then specifying the data-skip-moving=true attribute (for both internal scripts and external ones) can prevent unwanted transfer.

What about the remaining 5% of pages that were broken after migrating JS elements?

Code is searched using <script></script> tags. The system does not scan complex constructs such as scripts found in HTML comments. This must be kept in mind. Also, browser developers do not recommend the document.write construct. Pay attention to this too.

Of course, if the JS is moved to the bottom, then this HTML will also be displayed at the bottom, not where we need it.

This tool makes it possible to use it both within a single page and a site template.

“But what will happen to the JS that is in the HTML attributes? Will a page that still has JS in its attributes, and everything else moved down, still work? " - you ask. It is important to remember here that when the scripts below start loading, the site page will already be shown to the user. If he clicks on some element before the required JS file is loaded, this will result in a JavaScript exception. The user will not see the error, the element simply will not respond to the click. If he clicks again, after the element has loaded, then everything will work.

There are also those who believe that JavaScript should not be present in the attributes, otherwise the layout is mixed with JS, that it is more correct to use the addEventListener method. Let's look at the same example, only with jQuery.

When using jQuery or the BX library function, handlers are hung on the DomContentLoaded events. After the last script has been processed, this event occurs. But usability problems can still arise: when a user clicks on an element that has not yet been loaded, nothing happens.

What to do in this case:

• Do not change anything, leave everything in its place, in the hope of a quick download of all elements.
• Find, after all, an alternative way out for such situations. For example, show a loading indicator if the element's scripts have not yet loaded.
• Turn to old methods, from the distant 2000s. Then the DOM was accessed before the DomContentLoaded event fired. Of course, with a feedback: we hang the handler if the element is present, if not, we call it in DomContentLoaded.

CSS also gets mercilessly optimized!

Move on. CSS also has the ability to block page rendering. We can't remove the CSS because the page will be left without design. In this case, Google suggests placing the styles directly in the page code using the <style> tags. But there is a small nuance: this recommendation is applicable in small CSS. To understand where you can apply all the CSS, and where you can’t, you will need to remember the “slow start”. It is specific to the TCP protocol. This means that when a resource is requested by the client, the server does not send the largest number of packets, but gives the minimum, waits for confirmation of receipt and sends the next set. At the same time, doubling the volume of packages.

The first batch of packets is called the Initial Congestion Window. If the page has a large volume, then Google will point it out to you. Page Speed, for example, accepts no more than two roundtrip (the total time that a packet takes round-trip until it is fully loaded).

There are three output options for CSS:

• Do not touch the styles, leaving them in external files. In this case, they will slow down the rendering of the page on the first hit. But already on the second hits, the browser will take the resource from the cache.
• Insert styles in the body of the page. Then you need to make the code as concise as possible. If the size still remains large, you can do this: those styles that are used to load the first screen are inserted into the body. Transfer the rest to an external file and load using JavaScript. Google finds this option one of the most logical.
• Make more value packages.

Optimization and minification

The Page Speed Insights service has a feature: it can underestimate the score for voluminous images that are forced to scale to a smaller size. Use tools that compress graphic files. Alternatively, you can use the tool built into Google's Page Speed utility. The test will offer you links to download compressed versions of resources.

Another useful novelty is the checkbox in the CDN next to “Optimize resources”. If you enable CDN, then all CSS and JavaScript files will be loaded from a third-party resource. If you check the box next to "Optimize resources", then images and resources will be immediately optimized and compressed.

And a couple of optimization tips:

• Use gzip compression. Otherwise, a "slow start" will not be avoided due to bloated pages.
• Use HTTP caching.
• Watch the server response time. Performance module to help you! Google believes that it should take no more than 200 milliseconds before receiving the first response.

In conclusion

Whatever one may say, but in order to pass the adaptability test, first you need to make a mobile version of the resource:

• Using responsive layout
• It is possible through the domain m.mysite.ru
• Or show different HTML, depending on the UserAgent.

Google prefers responsive layout. Moreover, it is easier to make than another version of the site and another domain. Also be sure to check the permissions in the robots.txt file.

In working with Page Speed Insights, everything is more complicated. Pay attention to the possible blocking of resources that are in the <head> tag, the server response time, the size of external resources and the size of the page.