3

We noticed a lot of "Mobile Usability" errors in the Search Console. When I clicked on them and chose "Check live version" option - it always said the page was mobile friendly. However, the mobile usability errors didn't go away from the search console.

We continued testing and once or twice we got a "Page loading issues" error on top of the "Mobile Friendly Test" and the page was rendered with text content and images but CSS wasn't loaded.

It turns out Google Bot from time to time fails to download CSS from CloudFront distribution. This causes "Mobile Usability" errors in the Search Console and potentially search penalty.

We have a static website hosted on S3/CloudFront. CSS and HTML documents are on the same distribution. We have HTTP/2 enabled and I expect CSS to be served via the same connection as HTML. However, it doesn't happen from time to time and CSS fail to download. Errors happen rarely but yet they affect our website rankings.

CSS and JS are NOT in robots.txt

We have NO Geolocation restrictions.

There is NO errors originated from Googlebot in the CloudFront logs. I see only successful requests from Googlebot. There are errors from other users, so logs seems to work correctly.

Viewer protocol policy is set to Redirect HTTP to HTTPS.

Links to CSS are relative and look like that: https://www.visualwatermark.com/css/all-24c79a5ab7f0103302353199ecf9f1cf.css

The CloudFront distribution in question is https://www.visualwatermark.com/

Do you have any ideas what can be changed to ensure Google Bot always able to download CSS from CloudFront CDN?

Improve this question
7
  • 2
    "We have HTTP/2 enabled and I expect CSS to be served via the same connection as HTML. However, it doesn't happen from time to time and CSS fail to download." It shouldn't matter whether the CSS loads on the same HTTP connection, for any reason that I can think of. Can you elaborate on why this would matter? Also, are there CloudFront log entries that match the observed problems? Looking at the responses, I don't see an obvious explanation.
    – Michael - sqlbot
    Commented Jul 4, 2018 at 14:53
  • @Michael-sqlbot thank you for looking into this. I expected that once a connection was established, we should be pretty sure all files will be downloaded correctly.
    – Ivan Nikitin
    Commented Jul 5, 2018 at 7:43
  • It seems to be a reasonable expectation that the files should download correctly whether or not the same connection is reused. The CloudFront access logs would be the place go start. They provide quite a lot of information, including the status of the request, HTTP version actually used, timestamps, transfer sizes in bytes, etc.
    – Michael - sqlbot
    Commented Jul 5, 2018 at 9:11
  • 1
    @Michael-sqlbot there is no corresponding CloudFront log errors. Looks like Google bot's requests never reaches CloudFront.
    – Ivan Nikitin
    Commented Jul 6, 2018 at 11:08
  • The requests never hit my cloudfront either. I do have access logs and the ones that do make it are 200 (ok). I tested the same site on an EC2 instance and it doesn't have issue I wonder if something is setup wrong with cloudfront; but I never get css errors when browsing site
    – Chris Muench
    Commented Nov 10, 2018 at 19:27

2 Answers 2

Reset to default
1

Copy the css code that is used in the page, and place it in-line in a style tag on the page.

This forces the css, and there is no performance hit, and in some cases, it will run faster as there is no request routines for a css page.

Also, the fonts need to be the standard fonts, or locally installed, but I prefer to use the standard fonts the browser chooses instead of loading fonts.

Improve this answer
3
  • 2
    Thank you for looking into this. CSS file is too big to include it into the every page's code. Second page will load slower if we do this.
    – Ivan Nikitin
    Commented Jul 5, 2018 at 7:44
  • How many pages does a user typically use on your site? Many sites such as article sites typically get just one page view per user. Optimizing for the second page view may or may not make sense depending on your visitors typical usage patterns.
    – Stephen Ostermiller ♦
    Commented Jul 7, 2018 at 12:12
  • @StephenOstermiller I checked this. On average we have 2.1 pageviews/visitor. Considering this, I'm going to inline css.
    – Ivan Nikitin
    Commented Jul 8, 2018 at 15:27
1

This is probably caused by your css filenames changing. There may be a delay between when Google collects the initial html page and when it fetches the css. By the time they look for the css file, it may no longer exist.

To avoid this, you could leave old css files up for a while.

Improve this answer
2
  • Thank you for the reply. It's a static website, so there is no dynamic filename changes. It also works perfectly when opening it myself.
    – Ivan Nikitin
    Commented Jul 12, 2022 at 7:23
  • The css filename will update on generated static sites whenever your css changes (e.g., adjusting a style). If you never upload changes to css files, then I’m not sure
    – EmpireJones
    Commented Jul 12, 2022 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.