Google reporting many errors on mobile crawling test

[sobrenome]

If I ran the google mobile crawling test on one of my Pages URL I get many errors:

Google test URL:

https://search.google.com/test/mobile-friendly

URL tested:

https://fisiculturismo.com.br/notas-rápidas/treinamento/posso-passar-o-joelho-da-ponta-do-pé-no-agachamento-r143/

Problems reported: javascript and css not loaded, google bots blocked and CKEDITOR error.

==============

[Adlago]

A control mobile test with GtMetrix also shows bad results. The main problem - defer parsing java script from Google ads.
View and modify the way loading ads.
Look at a test

https://gtmetrix.com/reports/fisiculturismo.com.br/cColCUuR

[Sonya*]

2 hours ago, sobrenome said:

Problems reported: javascript and css not loaded, google bots blocked and CKEDITOR error.

Be sure, that there is a limit for the tests you can perform per day. After the limit is exceeded you will get and error that your resources are blocked by robots.txt (even if they are not). In this case it is a kind of generic error. I have spent days to figure it out. You can also find confirmation for this behavior on Google webmaster forums. Unfortunately Google does not care about correct error in this case (quota exceeded) and you can spend a lot time trying to figure out what these errors mean.

[sobrenome]

7 hours ago, Sonya* said:

there is a limit for the tests you can perform per day

This limit is related to the users or to their systems? I have run less than 10 tests.... thanks

8 hours ago, Adlago said:

View and modify the way loading ads.

How can I do this with IPS?

[sobrenome]

I have also tried this tester:

https://ready.mobi/#1200846-0dii

[Adlago]

34 minutes ago, sobrenome said:

How can I do this with IPS?

Move this code
 

	{{if settings.ipbseo_ga_enabled}}
			{setting="ipseo_ga"}
		{{endif}}

from a head in a globalTemplate at the bottom before closing a body tag (</body>)

A little later I will write you a instruction on how to remove Render-blocking CSS. This will improve PSI test results.

http://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Ffisiculturismo.com.br%2Fnotas-r%C3%A1pidas%2Ftreinamento%2Fposso-passar-o-joelho-da-ponta-do-p%C3%A9-no-agachamento-r143%2F

 

[Sonya*]

50 minutes ago, sobrenome said:

This limit is related to the users or to their systems? I have run less than 10 tests.... thanks

This must be a limit per site. https://support.google.com/webmasters/thread/4786439?hl=en

[Adlago]

2 hours ago, Adlago said:

A little later I will write you a instruction on how to remove Render-blocking CSS. This will improve PSI test results.

Render-blocking CSS is easily removed using the preload CSS function.
How is this done in IPS? It's easy - follow these instructions.
You first need to create a blank template for your theme.
Open for edit HTML and CSS your theme.
Click New - HTML Template

and fill out a blank creation as shown.

Open Template:
core/global/analisys/preload_css

and put the code below in this template. Save.

{{foreach array_unique( \IPS\Output::i()->cssFiles, SORT_STRING ) as $file}}
<link rel='preload' href='{expression="\IPS\Http\Url::external( $file )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style">
{{endforeach}}
{{$customCss = \IPS\Theme::i()->css( 'custom.css', 'core', 'front' );}}
{{foreach $customCss as $css}}
<link rel='preload' href='{expression="\IPS\Http\Url::external( $css )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style">
{{endforeach}}

Open your globalTemplate
Find this in head

{template="includeCSS" app="core" group="global" location="global" params=""}

and put before, code below. Save.

{template="preload_css" app="core" location="global" group="analysis" params=""}

That's all - now a browser user will load your CSS without a render-blocking.
You can use the ACP support tool to remove the cache on your site.
Do the tests and share the result. I know that now your site loads faster. Good luck.

[sobrenome]

8 hours ago, Adlago said:

Move this code
 

	{{if settings.ipbseo_ga_enabled}}
			{setting="ipseo_ga"}
		{{endif}}

from a head in a globalTemplate at the bottom before closing a body tag (</body>)

A little later I will write you a instruction on how to remove Render-blocking CSS. This will improve PSI test results.

http://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Ffisiculturismo.com.br%2Fnotas-r%C3%A1pidas%2Ftreinamento%2Fposso-passar-o-joelho-da-ponta-do-p%C3%A9-no-agachamento-r143%2F

 

But is it ok to place google analytics outside the head? Google tell us to let it inside the head. Is there any consequence replacing it to the body?

[Sovereign Grace Singles]

10 hours ago, Adlago said:

Render-blocking CSS is easily removed using the preload CSS function.
How is this done in IPS? It's easy - follow these instructions.
You first need to create a blank template for your theme.
Open for edit HTML and CSS your theme.
Click New - HTML Template

and fill out a blank creation as shown.

Open Template:
core/global/analisys/preload_css

and put the code below in this template. Save.

{{foreach array_unique( \IPS\Output::i()->cssFiles, SORT_STRING ) as $file}}
<link rel='preload' href='{expression="\IPS\Http\Url::external( $file )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style">
{{endforeach}}
{{$customCss = \IPS\Theme::i()->css( 'custom.css', 'core', 'front' );}}
{{foreach $customCss as $css}}
<link rel='preload' href='{expression="\IPS\Http\Url::external( $css )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style">
{{endforeach}}

Open your globalTemplate
Find this in head

{template="includeCSS" app="core" group="global" location="global" params=""}

and put before, code below. Save.

{template="preload_css" app="core" location="global" group="analysis" params=""}

That's all - now a browser user will load your CSS without a render-blocking.
You can use the ACP support tool to remove the cache on your site.
Do the tests and share the result. I know that now your site loads faster. Good luck.

Thanks!

Just informing that copying and pasting the above code added a stray character between the analysis and " mark. After saving that resulted in a error when visiting the site. Check the global template after pasting in the above code to see whether anything is in red that may pose an error.

Much thanks Adlago!
William

[Adlago]

5 hours ago, sobrenome said:

But is it ok to place google analytics outside the head? Google tell us to let it inside the head. Is there any consequence replacing it to the body?

I've done one more thing - I downloaded an analytics js, and I uploaded it to my folder uploads. This solves a cache issue for this resource, and improves loading speed.
That's what I did 4 years ago - and until now I have not noticed a problem with this.
PS. Millions of sites download this script from Google's servers - this sometimes causes a delay in loading your own site.

[sobrenome]

5 hours ago, Adlago said:

I've done one more thing - I downloaded an analytics js, and I uploaded it to my folder uploads.

This is interesting. But have you noticed how often google update this script? Same thing could be done with adsense script, right?

[Dll]

18 hours ago, Adlago said:

Render-blocking CSS is easily removed using the preload CSS function.
How is this done in IPS? It's easy - follow these instructions.
You first need to create a blank template for your theme.
Open for edit HTML and CSS your theme.
Click New - HTML Template

and fill out a blank creation as shown.

Open Template:
core/global/analisys/preload_css

and put the code below in this template. Save.

{{foreach array_unique( \IPS\Output::i()->cssFiles, SORT_STRING ) as $file}}
<link rel='preload' href='{expression="\IPS\Http\Url::external( $file )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style">
{{endforeach}}
{{$customCss = \IPS\Theme::i()->css( 'custom.css', 'core', 'front' );}}
{{foreach $customCss as $css}}
<link rel='preload' href='{expression="\IPS\Http\Url::external( $css )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style">
{{endforeach}}

Open your globalTemplate
Find this in head

{template="includeCSS" app="core" group="global" location="global" params=""}

and put before, code below. Save.

{template="preload_css" app="core" location="global" group="analysis" params=""}

That's all - now a browser user will load your CSS without a render-blocking.
You can use the ACP support tool to remove the cache on your site.
Do the tests and share the result. I know that now your site loads faster. Good luck.

This 'fix' highlights the issues with reading too much into these speed testing scores. You're achieving a better score with it, but in reality you're not solving the problem of render blocking css slowing down page loads. 

Regardless of whether you preload it or not, all of the css still has to be downloaded before the page renders. So in the real world, on a slow connection, and especially on a mobile, it can seriously slow the rendering of the page. Preloading prioritises it, but, especially when bandwidth is limited, all you're doing is moving things around and not speeding anything up. 

The only way round this is to inline the css on the page which is vital to render the main elements of the page, especially in above the fold content (or at least to have a separate css file with those elements in it). Then, the rest of the css can be loaded in afterwards. That way, there is no wait for downloading lots of css before the page can start to draw. 

https://developers.google.com/web/tools/lighthouse/audits/unused-css?utm_source=lighthouse&utm_medium=unknown

[Adlago]

5 minutes ago, Dll said:

The only way round this is to inline the css on the page which is vital to render the main elements of the page, especially in above the fold content (or at least to have a separate css file with those elements in it). Then, the rest of the css can be loaded in afterwards. That way, there is no wait for downloading lots of css before the page can start to draw.  

Using Critical CSS inline solves some issues with the acceleration site, but it happens at the expense of the first byte. Html becomes big, more than 80kB, making the first byte slow. Another drawback of a critical CSS is that it is very complicated to create such an inline css file that includes critical css rules from all pages.

In most sites I've worked with, using a preload CSS is a good alternative.

34 minutes ago, sobrenome said:

This is interesting. But have you noticed how often google update this script? Same thing could be done with adsense script, right? 

I update this file twice a year when I think about it. I have not noticed issues.
I do not use ads and have no idea about script ads.

[Dll]

2 hours ago, Adlago said:

Using Critical CSS inline solves some issues with the acceleration site, but it happens at the expense of the first byte. Html becomes big, more than 80kB, making the first byte slow. Another drawback of a critical CSS is that it is very complicated to create such an inline css file that includes critical css rules from all pages.

In most sites I've worked with, using a preload CSS is a good alternative.

I update this file twice a year when I think about it. I have not noticed issues.
I do not use ads and have no idea about script ads.

Preloading the css makes absolutely no difference to anything but the score on whatever tests you're running. The css is generally loaded right at the top of the head section anyway, so asking the browser to preload it makes no real world difference whatsoever - which is the important thing. The scores you're forever chasing are irrelevant if your efforts to improve them don't make a difference to the time it takes users to load, view and start using your site.

Putting the critical css inline also makes no difference to the first byte as that has nothing to do with the size of the html in the page, it's the time it takes the browser to start loading the html after requesting - eg the time it takes for it to load the first byte of it.

And none of this has anything to do with the amount downloaded in any case, whether the css is in a file, in the html or wherever else, it's got to be downloaded. The issue here is the order. If you only need 10% of the css to start loading the page, but all the css needs to be downloaded before the page can start to render, then clearly that's the least efficient way of doing it. If you can take that 10% (or in many cases less) of that css out, and place it inline so the page can draw before the rest is downloaded, that is the most efficient way.

[sobrenome]

2 hours ago, Adlago said:

Using Critical CSS inline solves some issues with the acceleration site, but it happens at the expense of the first byte. Html becomes big, more than 80kB, making the first byte slow. Another drawback of a critical CSS is that it is very complicated to create such an inline css file that includes critical css rules from all pages.

In most sites I've worked with, using a preload CSS is a good alternative.

I update this file twice a year when I think about it. I have not noticed issues.
I do not use ads and have no idea about script ads.

Thanks! We will try this suggestions!

😀😀

[Adlago]

33 minutes ago, Dll said:

Putting the critical css inline also makes no difference to the first byte as that has nothing to do with the size of the html in the page, it's the time it takes the browser to start loading the html after requesting - eg the time it takes for it to load the first byte of it.

You're probably convinced of that. But the file html is not a ready file - it is a file that the server produces after the request and the time of the first byte depends on the time for which the server will create a html and will be ready to send a first byte from that html.

And yes, the size of html matters, but I do not think to argue with you. Thank you for your opinion.

[Dll]

33 minutes ago, Adlago said:

You're probably convinced of that. But the file html is not a ready file - it is a file that the server produces after the request and the time of the first byte depends on the time for which the server will create a html and will be ready to send a first byte from that html.

And yes, the size of html matters, but I do not think to argue with you. Thank you for your opinion.

If you think that adding less than 100kb inline to a file is going to dramatically change the ttfb, I'm afraid you're wrong - unless of course your server is really badly configured. I'm not suggesting you dump 20mb of css in there am I..

And the fact still remains that preloading css does absolutely nothing except game scores on mostly pointless online speed tests. Your aim should be to better serve users, not get marks out of 100 on those. 

[Adlago]

1 hour ago, Dll said:

And the fact still remains that preloading css does absolutely nothing except game scores on mostly pointless online speed tests.

Do you make a difference between downloading CSS and processing CSS from the browser?
Preload CSS creates a priority in CSS processing from a browser without render blocking.
It does 'preload', and it's not nothing, but just for wanting to use it - and test servers do not have blame you do not like it.
But if you are interested - there is a lot of information on the internet.

[Dll]

23 minutes ago, Adlago said:

Do you make a difference between downloading CSS and processing CSS from the browser?
Preload CSS creates a priority in CSS processing from a browser without render blocking.
It does 'preload', and it's not nothing, but just for wanting to use it - and test servers do not have blame you do not like it.
But if you are interested - there is a lot of information on the internet.

CSS is already prioritised in the browser - that's why it blocks rendering! Preloading every single css file is just doing what the browser will do already and is pointless.

Have a read of the guidance from the lighthouse report. Nowhere in there does it suggest that preloading is the way to solve the problem. If you're loading all the css before everything else, then the user still has to wait for it. 

The only way to truly prioritise it, is to do as the likes of Google suggest and place priority css directly into the document and load the rest of the css later on. It's really as simple as that.

Quote

Recommendations

The CSS that is needed in order to load a page is called the critical CSS. In general, a page load should only be blocked on critical CSS. See Detecting critical CSS.

Theoretically, the most optimal approach is to inline critical CSS into the <head> of the HTML. Once the HTML is downloaded, a browser has everything that it needs in order to display the page. It doesn't need to make any more network requests. See Inlining CSS.

https://developers.google.com/web/tools/lighthouse/audits/unused-css?utm_source=lighthouse&utm_medium=unknown

 

[Adlago]

1 minute ago, Dll said:

The only way to truly prioritise it, is to do as the likes of Google suggest and place priority css directly into the document and load the rest of the css later on. It's really as simple as that. 

That's what I know, and be sure that I'm succeeding and creating a very good critical CSS and in many sites running such a critical CSS that's fine.
But this is not the only way - and that's what I have said in this topic. I have written my opinions on this topic here after thousands of tests and analyzes, and that's why I'm sure of what I've been researching.
This of course does not make you believe me and use my advice.

[Dll]

1 hour ago, Adlago said:

That's what I know, and be sure that I'm succeeding and creating a very good critical CSS and in many sites running such a critical CSS that's fine.
But this is not the only way - and that's what I have said in this topic. I have written my opinions on this topic here after thousands of tests and analyzes, and that's why I'm sure of what I've been researching.
This of course does not make you believe me and use my advice.

Honestly, it's not about believing you. It's simply the fact you are wrong in this instance. There is no advice out there suggesting what you're doing with the css is correct. If CSS wasn't prioritised in the browser, it wouldn't render block. Browsers all treat it as highest priority, because it's required to render the page. 

You could in theory use preload to tell the browser about a critical css file, but if you do that without deferring the rest of the css, it's pointless. As it is if you preload every css file. 

Here's the read out from this forum - you can view the browser priorities in the network panel on the developer tools in your browser. (Click the rows and select priorities). 

Quote

forums/	200	document	Other	31.0 KB	1.35 s	Highest
341e4a57816af3ba440d891ca87450ff_framework.css.504f67f9c3b1b98f9708407bec8ebf67.css.gz?v=d815db9321	200	stylesheet	(index)	44.8 KB	44 ms	Highest
05e81b71abe4f22d6eb8d1a929494829_responsive.css.078991fd19c81aaa3e5113f16de9d5f0.css.gz?v=d815db9321	200	stylesheet	(index)	7.1 KB	46 ms	Highest
90eb5adf50a8c640f633d47fd7eb1778_core.css.2d66ef351eab4a8fa5477631c25cc6c0.css.gz?v=d815db9321	200	stylesheet	(index)	4.5 KB	46 ms	Highest
5a0da001ccc2200dc5625c3f3934497d_core_responsive.c…ea86463ff37aaa4ee313658c6f094.css.gz?v=d815db9321	200	stylesheet	(index)	1.2 KB	45 ms	Highest
62e269ced0fdab7e30e026f1d30ae516_forums.css.2ff9c95e63f9d1715f24f9ef5ff4ce8a.css.gz?v=d815db9321	200	stylesheet	(index)	2.6 KB	47 ms	Highest
76e62c573090645fb99a15a363d8620e_forums_responsive…6f8da7a1538f33521d9e7a014222e.css.gz?v=d815db9321	200	stylesheet	(index)	1.8 KB	46 ms	Highest
aa0d3895a07f810ea9ac4b0e03928774_promote.css.db66d699c7974ae4140eb76b0cbbd064.css.gz?v=d815db9321	200	stylesheet	(index)	2.4 KB	44 ms	Highest
311e677be1fd9bd34c1ccbaf8c789d99_promote_responsiv…828af9b72d04ed4fd688be8bc1def.css.gz?v=d815db9321	200	stylesheet	(index)	597 B	376 ms	Highest
258adbb6e4f3e83cd3b355f84e3fa002_custom.css.9df31aaf0a251fc77c7cfa3d196f2dc8.css.gz?v=d815db9321	200	stylesheet	(index)	10.5 KB	47 ms	Highest

Notice, the document and css are already highest priority. Preloading the css will not change that. The CSS still has to load first, the browser still has to wait for it before it'll draw the page.

Here's your forum, where you've preloaded - and no surprise, it's the same. No change in loading order, no discernible speed difference, no difference to the end user. The only change is the score on whichever site(s) you're testing on. 

Quote

nophelet.com	200	document	Other	15.8 KB	401 ms	Highest
341e4a57816af3ba440d891ca87450ff_framework.css.35eb3a7c630784c441861998867a230c.css?v=8deda61424	200	stylesheet	(index)	44.6 KB	142 ms	Highest
05e81b71abe4f22d6eb8d1a929494829_responsive.css.793d793a23eb49b4a58edfc37c6f03d5.css?v=8deda61424	200	stylesheet	(index)	6.8 KB	76 ms	Highest
20446cf2d164adcc029377cb04d43d17_flags.css.af6969fe1d267a8144897187d0c1fb38.css?v=8deda61424	200	stylesheet	(index)	1.7 KB	73 ms	Highest
90eb5adf50a8c640f633d47fd7eb1778_core.css.e4faee1415909eb56ccce482c549742a.css?v=8deda61424	200	stylesheet	(index)	4.2 KB	77 ms	Highest
5a0da001ccc2200dc5625c3f3934497d_core_responsive.c…52fa09772c3c55b37ddfedede13ee4db.css?v=8deda61424	200	stylesheet	(index)	900 B	75 ms	Highest
51a672ecd6862df2c2f1969522683ee9_calendar.css.9554328723638bda7c80615d5c621c1c.css?v=8deda61424	200	stylesheet	(index)	1.7 KB	78 ms	Highest
aa0d3895a07f810ea9ac4b0e03928774_promote.css.2343c9631d351e03de620a79f76800d0.css?v=8deda61424	200	stylesheet	(index)	2.1 KB	79 ms	Highest
311e677be1fd9bd34c1ccbaf8c789d99_promote_responsiv…2728900a7c4185ba52187d8ec2f20365.css?v=8deda61424	200	stylesheet	(index)	437 B	80 ms	Highest
97c0a48072ce601c9764cb6b00a6588a_page.css.0c5f8d87d0e9000ebb978a38ac782e39.css?v=8deda61424	200	stylesheet	(index)	620 B	82 ms	Highest
258adbb6e4f3e83cd3b355f84e3fa002_custom.css.2eb61fc6b1b9032c21353bd60541b9bd.css?v=8deda61424	200	stylesheet	(index)	4.8 KB	80 ms	Highest

 

[Adlago]

Your example only indicates Rendering time.
See and compare Parsing Time ...

 

[Dll]

You miss the point.

The browser already prioritises CSS at the highest possible level. So you telling it to prioritise all the CSS files makes no difference. See the priority on your screenshots - both sets are highest.

If it were as simple as you claim to magically get the browser to somehow load the CSS any sooner, parse it any faster or treat it any higher than highest priority, why wouldn't everyone be doing it? Why wouldn't Google advise it?

I can find literally no one suggesting what you're doing. You've apparently taken a piece of advice about preloading a single CSS file while deferring others, have misunderstood how it works and are now chasing fools gold by thinking preloading everything will somehow work.

If you want to do that, of course it's up to you, but seriously you're wasting your time. I've tried to help you, have shown you evidence and linked you information but clearly you're intent on doing what you're doing, so I'll leave it here, as I'm not going to waste any more of my time going over it.

[Adlago]

17 minutes ago, Dll said:

now chasing fools gold by thinking preloading everything will somehow work.

This is a public topic, not a marketplace offer ...
I share experience and if someone can use it.
What gold is turning your head, I have no idea and I do not care.

Good luck with your knowledge.