Document write

Silktide checks whether any scripts on your page use an outdated command called document.write, which forces the browser to stop and wait while the page is loading. Modern pages should not use it.

// Problem: injecting a script this way blocks the whole page
document.write('<script src="ads.js"><\/script>');

Why this matters

When a browser meets document.write() while reading a page, it cannot safely continue: the command can rewrite anything that follows, so the browser stops, waits for any injected script to download and run, and only then resumes. On a slow connection that single pause can add many seconds to the page load.

The technique survives mostly inside old advertising, tracking, and widget snippets, so pages usually carry this cost without anyone having chosen it. Browsers consider it harmful enough that they sometimes ignore these calls entirely on slow connections, which means content injected this way can simply fail to appear.

How to fix it

Remove document.write() from your own . To add content or scripts to the page, create elements through standard methods instead, which do not block loading:

// Fixed: inject the script without blocking the page
const script = document.createElement('script');
script.src = 'ads.js';
script.async = true;
document.head.appendChild(script);

If the call comes from a third-party snippet, check the provider's documentation for their current embed code - most replaced document.write() versions years ago.
If a provider offers nothing better, weigh what the script adds against the delay it causes, and consider replacing the provider.

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.
Watch for calls to document.write() while the page loads, including calls made by third-party scripts.
Report each script file that made a call, with the line where it happened.

Troubleshooting

The call is inside a script we don't control

That is the most common case. You cannot edit the provider's code, but you usually control the snippet that loads it - replacing an old embed snippet with the provider's current version is often the whole fix.

The page seems to load fine

On a fast connection the pause can be short enough to miss. The same page on a slow mobile connection stalls visibly - and some browsers ignore the call entirely there, so whatever it injects never appears for those visitors.