Start with the file, not the count
A render-blocking resource is a file the browser waits for before drawing the initial page. You will often investigate CSS, which controls appearance, and JavaScript, which provides behavior. A report listing eleven scripts does not tell you which one to remove or how much time a change would save. Start by identifying the actual files involved.
Open the affected page in Chrome, then open DevTools and select Performance. Use Record and reload to capture the page loading. In Insights, expand Render-blocking requests. Copy the listed file URLs and find out which feature or plugin loads each one. If DevTools feels unfamiliar, ask your website developer to do this. Give them the page URL and the flagged check so they can investigate the same thing.
Read more: Chrome for Developers · Render-blocking requests · Chrome DevTools · Performance reference
Work out what needs to load first
CSS that lays out the first screen may be needed right away. A widget further down the page might be able to wait. The distinction depends on how the website is built. Delaying files used by menus, inquiry forms or checkout can break them. In WordPress, review the settings of the performance plugin you already use and try one change at a time on a test copy.
For a developer editing the code, defer may be suitable for an external classic script after its dependencies have been checked. The filename below is an illustrative example. It assumes the script is not needed for the first screen or by code that runs immediately afterward. This is not a blanket change for inline or module scripts, and defer is not a CSS attribute.
Before
<script src="/assets/program-inquiry.js"></script>After
<script src="/assets/program-inquiry.js" defer></script>Read more: Chrome for Developers · Render-blocking requests · MDN · The script element
Check the website, then measure again
Keep the original setting and recording. After the change, measure the same page under the same device and network conditions more than once. Watch the first screen appear, open the menu and work through the inquiry form without sending a real request. Check a phone-sized screen too. If something breaks, restore the previous setting and investigate that file separately.
When handing the task to a developer, ask which feature owns the file, whether its loading can change, and what the before-and-after recording and functional checks show. That gives you something concrete to review. A successful edit is one you can explain and verify. A local DevTools recording and Core Web Vitals collected from real visitors are different datasets; keep that distinction when reviewing the result.
Read more: Chrome DevTools · Performance reference