This issue can be fixed by using responsive images, which relies on creating multiple versions of each image, that are served via CSS media queries depending on the user's viewport dimensions.

Another solution can be to use vector-based image formats like SVG. SVG images scale appropriately to any size, without wasting unnecessary bandwidth. Also consider image CDNs that can help serve responsive images.

In order to pass this test, you have to fix all the warnings and errors reported in Chrome DevTools console. You can also visit Google's documentation for further troubleshooting support: https://developer.chrome.com/docs/devtools/issues/

In order to pass this test, convert all the images listed in this report into a modern image format such as JPEG 2000, JPEG XR or WebP.

It's important to understand that the modern image formats, like WebP, are not yet widely supported across all devices and browsers. You can find here a full list of supported browsers and devices for the WebP format.

If your target audience falls within one of the unsupported browser/device categories, you should serve optimized fall-back images in the original JPEG/PNG format so that your users don't see a broken or badly designed page:

<!--Before:-->
<img src="image.jpg" alt="">

<!--After:-->
<picture>
	<source type="image/webp" srcset="image.webp">
	<img src="image.jpg" alt="">
</picture>

The browser uses the first listed source that's in a format it supports. If the browser does not support any of the formats listed in the "source" tags, it falls back to loading the image specified by the "img" tag.

In order to pass this test, you have to reduce the impact of render-blocking resources.

First, you have to identify what's critical and what's not. You can use the Chrome DevTools (Coverage tab) to identify non-critical CSS and JS.

Once you've identified critical code, you can try the below methods to eliminate render-blocking resources:

• inline critical JS within a script tag in your HTML document
• inline critical CSS required for the first paint inside a style block in the head of the HTML document
• move the script and link tags at the end of the HTML document
• add async or defer attributes to non-critical script or link tags
• split CSS styles into different files, organized by media query
• compress and minify your text-based resources

HTML5 Microdata is an easy way to add semantic markup to your web pages. Search engines rely on this markup to improve the display of search results, making it easier for people to find the right web pages.

Here is a simple example of how to use HTML5 microdata in your contact web page:

<div itemscope itemtype="http://schema.org/Person">
   <span itemprop="name">Joe Doe</span>
   <span itemprop="company">The Example Company</span>
   <span itemprop="tel">604-555-1234</span>
   <a itemprop="email" href="mailto:joe.doe@example.com">
      joe.doe@example.com
   </a>
</div>

In order to pass this test, the ads.txt file should be publicly available in the website's root domain and its content should be properly formatted.

The advertising systems will read the content of the ads.txt file only if the request will return a 200 OK HTTP status code. The content of this file should be encoded as a formatted plain text and the HTTP Content-Type header should be text/plain (all other Content-Types are treated as an error and the content will be ignored).

As outlined in the IAB Tech Lab specifications for ads.txt file, the format logically consists of three types of records: comments, data records and variables:

1. Comments
   Lines starting with # symbol are considered comments and are ignored.
2. Data records
   For each Exchange or Supply-Side Platform (SSP) that is authorized to sell your inventory you must add a data record. Each of these lines should contain 3 or 4 comma separated fields:

   <FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>

   • #1 - The canonical domain name of the system where bidders connect (e.g. google.com, appnexus.com, etc)
   • #2 - The publisher account ID
   • #3 - The type of account or relationship (e.g. DIRECT or RESELLER)
   • #4 - (Optional) An ID that uniquely identifies the advertising system within a certification authority
3. Variables

   Any line containing a pattern of <VARIABLE>=<VALUE> should be interpreted as a variable declaration. The <VARIABLE> is a string identifier without internal whitespace. The only supported separator is the equals sign ‘=’. The <VALUE> is an open string that may contain arbitrary data.

   For human readability it is recommended that variables be declared at the end of the file, but this is not a strict requirement.

   Only the following variables are supported: CONTACT, SUBDOMAIN and INVENTORYPARTNERDOMAIN.