What this check inspects
Shipwork fetches the page as a crawler would, then renders it in a real browser, and compares the two. It reports the visible text length seen each way, any JavaScript errors in the console, a status code that differs between the two, a title that changes after scripts run, a transfer size over about three megabytes, and a request count that looks heavy.
What a failure means
When the rendered page carries much more visible text than the raw fetch, the finding is a warning: content that only exists after JavaScript is at risk of being missed. Console errors are warnings because they can stop the rest of a script from running. A heavy transfer or a very high request count is informational but relevant to performance.
How to fix it
- Render the important content, especially price and availability, on the server so it is in the raw HTML.
- If an app injects the product block client-side, check whether it offers a server-rendered variant.
- Fix JavaScript errors rather than tolerating them. One uncaught error can prevent later scripts from running and remove content.
- Use server rendering or pre-rendering for the largest content block so it is visible on first paint.
A typical failure, worked through
The setupA theme uses a JavaScript framework and fetches the price and variant options after load. The raw HTML contains the product title and an empty price container.
What the check reportsThe check reports that a browser sees far more text than a plain fetch, and notes the gap. A crawler that does not render sees the title with no price.
The pointIf the price is not in the HTML, any consumer that skips JavaScript sees a product with no price, which is exactly the state that gets listings disapproved.