Render-blocking resources
Silktide checks for stylesheets and scripts that the browser must fully download before it can show anything on your page. Every one of them keeps visitors staring at a blank screen a little longer.
By default, a stylesheet or a script referenced near the top of a page blocks rendering: the browser will not paint anything until the file has arrived, because the file could change how everything looks or behaves.
Why this matters
The blank moments before a page first appears are when visitors decide whether to wait. Every render-blocking file adds a network round trip to that blank time, and the delays add up quickly on mobile connections - a handful of blocking files can hold an otherwise fast page white for seconds.
Most of that blocking is unnecessary. Typically only a small part of a page's is needed to draw the first screen, and most does not need to run before the page appears.
How to fix it
- Load scripts without blocking by adding
defer(orasyncfor independent scripts such as analytics):
<!-- Problem: blocks rendering until downloaded and run -->
<script src="app.js"></script>
<!-- Fixed: downloads in parallel, runs after the page is parsed -->
<script src="app.js" defer></script>
- Inline the small amount of CSS needed for the first screen directly into the page, and load the full stylesheets without blocking.
- Give stylesheets that only apply in certain situations a
mediaattribute (such asmedia="print"), so they stop blocking rendering everywhere else. - Reduce what there is to block on: remove unused styles and scripts, and keep the rest small - see CSS minification and Minified JavaScript.
How Silktide tests this
- Load the page in a real browser, using the device type, connection speed, and test location configured for your speed tests.
- Identify each stylesheet and script that blocked the first paint of the page.
- Estimate the time each one held rendering back, and report each file with its estimated saving.
- Grade the page by the total time that could be saved: around 100 milliseconds is graded down, and 200 milliseconds or more is graded as poor.
Troubleshooting
Doesn't CSS have to block rendering?
The stylesheet driving the first screen does - that is by design, so visitors never see unstyled content. The fix is not to remove CSS but to shrink what blocks: inline the critical part, and load the rest in a non-blocking way.
The blocking file is a third-party script
Tag managers, fonts, and chat widgets are frequent offenders. Most work correctly with defer or async - check the provider's current embed instructions, which often already include it.