A render-blocking resource is one the browser refuses to paint past. Stylesheets in the head block render by default because the browser doesn't want to paint un-styled content. Scripts in the head block parsing unless they carry `async` or `defer`. The page sits at a blank or skeleton state until every blocking resource has downloaded, parsed, and (for CSS) applied to the document.
In a WordPress audit, the usual offenders are predictable. Block-library `style.css` enqueues into the head on every page that touches a block, whether or not the page uses any block components. jQuery still loads in the head on themes that haven't migrated to footer-loaded scripts. Page-builder plugins enqueue their full stylesheet on every page, sized for every possible widget, on a post that uses three of them. A fresh install of a popular theme and four plugins routinely ships 12-20 render-blocking resources before any of the theme's own code runs.
Finding them is mechanical: open the page in Chrome DevTools, look at the Network panel filtered by "CSS" and "JS," and check the "Initiator" column for anything loading from the document rather than from `async` / `defer` / preload. Anything in the head without one of those attributes is blocking.
The fix usually isn't to remove the resource — it's to change how it loads. Inline the [critical-css](/glossary/critical-css/) the page actually needs above the fold, then load the rest via [async-swap](/glossary/async-swap/) (`media="print" onload="this.media='all'"`). Move scripts to the footer or add `defer`. Dequeue what the surface doesn't use. The render-blocking line in a [byte-ledger](/glossary/byte-ledger/) audit is where I look first when a WordPress site's [lcp-largest-contentful-paint](/glossary/lcp-largest-contentful-paint/) sits above 2.5 seconds.