Render-blocking resourcesWhat it checks and how to fix it

What it checks

Counts the resources in <head> that block the first render: stylesheets without a print or conditional media query, external scripts without async, defer or type="module", and inline scripts over 1,000 characters. None passes, one to three is a warning, and four or more fail the check.

Why it matters

The browser cannot paint anything until it has downloaded and processed every blocking resource in the head, so each one adds a round trip before the visitor sees content. That delay shows up directly in First Contentful Paint and Largest Contentful Paint, which are part of Core Web Vitals and affect both rankings and bounce rate, especially on mobile networks.

How to fix it

Load scripts with defer (or async for independent scripts such as analytics), and keep only the CSS needed for the first screen blocking.

<!-- scripts: defer keeps execution order and runs after parsing -->
<script src="/assets/application.js" defer></script>
<script src="https://analytics.example.com/script.js" async></script>

<!-- print styles never block rendering -->
<link rel="stylesheet" href="/assets/print.css" media="print">

<!-- non-critical CSS: load it without blocking, then apply it -->
<link rel="preload" href="/assets/below-the-fold.css" as="style" onload="this.rel='stylesheet'">

In Rails:

<%= javascript_include_tag "application", defer: true %>
<%= javascript_importmap_tags %> <%# importmap modules are already non-blocking %>

Move large inline scripts out of <head> into a deferred file, and inline only a small block of critical CSS for above-the-fold content.