Table of contents of the article:
We've talked a lot about the importance of User Experience and Google's new evaluation criteria and metrics called Google Core Web Vitals .
We also talked about how important it is to provide good, valid values to the real end user and not fool Google's PageSpeed test.
Today we had the real confirmation of a highly deleterious and negative modus operandi, which causes damage to those who use it in order to deceive Google and obtain a better PageSpeed score, or at least better from the LABS tests.
We wanted to write a post to demonstrate once again how not knowing a topic can only harm you.
The specific case to be examined and the PageSpeed score.
It all started with a comment from someone on Facebook about their recipe site, which has been struggling to take off. We've mentioned in other articles that we manage major brands and recipe sites with over 60 million page views per month , and since we manage three of the top six sites in Italy, we can safely say we know something about it.
The interlocutor is informed that his site does not support Brotli compression , a feature that is very productive nowadays, just as it does not support TCP BBR which is very important for slow 3G connections or even 4G connections with high packet loss and high latency.
For its part, we receive a rather self-centered and questionable response, stating that its site is a surface-to-air rocket and that it is even superior to Giallo Zafferano.
Let's focus our attention on the PSI PageSpeed Insight test report, which initially leaves us rather astonished because it actually has all the optimal values and exceeds all the Google PageSpeed Insight metrics.
In short, according to the owner we are faced with a site that exceeds the values of Giallo Zafferano, but Giallo Zafferano makes several tens of millions of visitors a month, and this site perhaps a few thousand, so few visits that it is not even estimated by services like SimilarWeb Sites.
Let's start looking at those values in detail and we find ourselves faced with a use / abuse of the use of the CSS background-image property
In fact, this site does not load images in HTML using the img tag but using a div with background-images property that loads the image as background.
And here begins the pains and the severe criticism not so much of the owner of the site, moved by the best of intentions, but of the dangers faced when trying at all costs to obtain a high PageSpeed score in the green area and therefore above 90. , sacrificing important features and functionalities that irremediably impact in this case on SEO and positioning.
IMG vs Background-image let's see the difference between the two.
It is self-evident that the huge mistake that was made in this case is to sacrifice the use of the HTML img tag to replace it with the non-blocking background-image that was created for other purposes and with features and related pros and cons, certainly not suitable for use that has been made of it on an online recipe blog which aims to position itself and be searched on search engines.
Definition of the HTML IMG tag
The HTML img tag is used to include images within a web page. This tag requires two mandatory attributes: src and alt.
The tag <img> is used to embed an image in an HTML page.
The images are not technically inserted in a web page; the images are linked to web pages. The tag <img> creates a holding space for the reference image.
The tag <img> has two mandatory attributes:
- src - Specifies the path to the image
- alt - Specifies alt text for the image, if the image for some reason cannot be displayed
Note: Also, always specify the width and height of an image. If you don't specify the width and height, the page may flicker while the image loads.
Definition of the CSS background-image property
The property background-image set one or more background images for an element.
By default, a background image is placed in the upper left corner of an element and repeated both vertically and horizontally.
Google does not index images declared and uploaded via background.image
Google's John Mueller said in a webmaster hangout that Google's image search doesn't index and rank images from CSS background code. He said that if you want your images to rank in Google's image search, then it's best to use the normal image tag with the source attribute pointing to the image.
The reference has been public since 2018 and can be viewed at 20:55 of the video below.
If you prefer to access reliable alternative documentation you can understand the same thing by reading the same notions at this URL: https://www.seroundtable.com/google-image-search-css-25068.html
Use an img tag. It's best for a variety of reasons.
When to use
- When your image has to be indexed by the search engine
- If it has a relationship with the content, not with the design.
- If your image is not too small (non-iconic images).
- Pictures where you can add
altetitleattribute that have very positive SEO implications.
When to use background-image CSS
- Images used exclusively for design.
- No relationship with the content and that do not need to be indexed.
- Small images that we can load with CSS3.
- Repeated images (in the blog author icon, the date icon will be repeated for each post etc.).
- Images from which SEO-side indexing is not expected.
Based on the list above and some observations we have these reasons to use a imgDay:
- A logo image has a semantic meaning and is related to the content. So this is just the right thing to do from a semantic point of view.
- Google doesn't automatically index background imagesotherwise the image search results would be filled with image sprites. Google hasn't officially released a statement about it, but it will most likely add more value to the div with an air label, although an image will most likely have even more value. (Bing presumably doesn't do anything with this though)
So: most likely it is best to use a imgtag
If anyone thinks that accessing 2018 documentation and references is wrong and misleading, remember that John Muller recently returned to the subject in this Tweet on April 14, 2021 with a very clear answer that leaves little room for interpretation.
https://twitter.com/JohnMu/status/1381583542484893706
What can we learn from this experience?
This experience helps us to understand how the goal of having a fast and performing website has put us in a position to lose sight of what are the fundamentals of SEO for example.
We have always described our work (that of fast and performing systems engineers for Hosting) as that of an excellent cog among many gears that constitute the beating heart of a successful publishing project.
Each department and each branch of the project and the various departments must be able to express the best without invalidating the work of other departments and without giving up compromises by managing the due priorities.
In this specific case we have seen how it is counterproductive and not very logical in order to achieve business objectives, to sacrifice SEO and the functionality offered by the html tag, only in order to have a site that brilliantly passes a PageSpeed Insight test by cheating on the type of item chosen for image upload.
Pagespeed is very important but SEO is more.
Always be scrupulous in evaluating the pros and cons of any changes you make to your site, taking care above all to understand the real reasons and side effects that could arise even irreparably.


