Render-blocking resources

When a browser reads a page’s HTML and meets a stylesheet link or a regular script tag in the <head>, it stops. It has to fetch and process that file before it can paint the page, because the file might change how everything looks. Each of those files is a render-blocking resource. A page with six stylesheets and eight scripts in the head makes the visitor wait for all of them.

Why it matters

This delay lands directly on Largest Contentful Paint and on how quickly a visitor sees anything at all. Brightside Dental’s WordPress theme loads CSS for a slider, a gallery, a contact form, an icon font and a page builder on every page, including the simple “Insurance we accept” page that uses none of them. On a slow phone connection, that’s a second or more of blank screen.

Which files block

• <link rel="stylesheet"> in the head (unless it has a media attribute that doesn’t match the current device)
• <script src="..."> in the head without async or defer

Images, fonts and scripts with defer or async don’t block the first paint.

How to fix them

Defer non-critical JavaScript. Most scripts don’t need to run before the page appears:

<!-- Blocks rendering -->
<script src="/js/reviews-widget.js"></script>

<!-- Downloads in parallel, runs after the HTML is parsed -->
<script src="/js/reviews-widget.js" defer></script>

Trim and split CSS. Remove styles for features the page doesn’t use. Some optimization plugins can inline the small amount of “critical CSS” needed for the first screen and load the rest afterwards.

Load third-party widgets later. Chat, review carousels and social embeds can load after the main content, or only when the visitor scrolls to them, similar to lazy loading for images.

Self-host fonts and preload the one or two files used above the fold, rather than loading several weights from an external service.

Common mistakes

Adding defer to every script at once can break things: a script that depends on jQuery will fail if jQuery runs later than expected. Test after each change. Another trap is optimization plugins that combine all CSS into one huge file, which can be slower than leaving it split.

How to check

PageSpeed Insights lists render-blocking requests with the estimated time each one costs. In Chrome DevTools, the Coverage tab shows how much of each CSS and JS file actually runs on a page, which is often under a quarter. RankThat’s Site Audit reports render-blocking files as part of its speed and Core Web Vitals checks.