Is your site delivering pages efficiently?
Two sites can look identical and load seconds apart. Compression, caching headers and server response time decide which one feels instant, and each is set once, at the server or CDN.
Reads the response headers and timing from a set of your pages. Saved to your account if you are signed in to a paid plan.
How this check works
Shipwork requests a set of your pages and reads the delivery headers: whether the HTML is compressed (gzip, brotli or zstd), whether Cache-Control tells browsers and CDNs how long to keep it, whether Vary includes Accept-Encoding, and how long the server took to respond.
What the site delivery check reads
The site delivery check reads the response headers of the pages it samples, up to 20 in a free run, taking the home page as its main subject. It checks whether the HTML is compressed, what the caching header says, whether the response varies by encoding, and how long each sampled page took to respond.
Compression is measured with a request that asks specifically for compressed content, because a normal fetch often decompresses the body and hides the header. Pages that took over 800 milliseconds to respond are listed with their times. If a probe cannot be made, the check leaves that item out rather than guess.
How to read a delivery result
A warning that the HTML is not compressed means the server is sending full-size pages when it could send much smaller ones. A missing caching header means browsers and caches have to guess how long to keep the page. Pages over 800 milliseconds point at the server or cache rather than the front-end. A clean result means the sampled responses looked compressed, cacheable and quick.
These are server-level observations, not a page-speed score. The check cannot measure how the page renders or how it feels to use. A single fast response also says nothing about the slowest moment under load. Use it to catch unset headers and slow responses, then confirm the visitor experience with real-user data.
Common causes and why they matter
Compression and caching are often simply never enabled, because many platforms work without them and nothing visibly breaks. A host may compress some file types but not HTML, or a default caching policy may send no-store on pages that rarely change. Slow responses usually come from an uncached origin doing work on every request.
Delivery sits before everything else: the faster the first byte arrives, the sooner the browser can start fetching images, styles and scripts. Compressed HTML and sensible caching reduce the work and the bytes on every visit. Slow server responses delay the whole page, no matter how well the front-end is built.
How to fix compression, caching and slow responses
Enable compression for the HTML at the server or edge cache, using a modern algorithm where it is offered. Set a sensible caching header: a long lifetime for static assets whose names change with each release, and a short lifetime or revalidation for HTML that changes often. If compressed output is served, include the encoding in the vary header so a shared cache does not send the wrong version.
For slow responses, look at what the origin does on each request and what caching sits in front of it. On a store, check whether an add-on is bypassing the cache for common pages. After changing settings, re-run the check and confirm the unset-header warnings are gone, then watch real-user data for the effect.
When to use related checks
Use image weight for the images inside the page, which are often the largest part of its bytes. Use Core Web Vitals when you want field data on what visitors actually experienced rather than response headers.
The website audit checklist places delivery among the first checks to run. Headers, images and real-user speed are three layers of the same question, so read the one that matches what you are trying to improve.
Questions
Why does compression matter?
What should Cache-Control say?
What is a good time to first byte?
How do I check if my site is compressed?
Why does the Vary header matter for compression?
Does the delivery check measure page speed in a browser?
Keep reading
What this reads
- Reads public pages from outside your network, the way a crawler does.
- No signup, and nothing is stored on the free checks.
- One of 83 checks across discovery, content, markup, trust and catalogue data.
Cool, just ran an audit and got some insights! Let’s see if I can fix them :)
Whoah! this site is crazy, nothing to roast at all
cool as heck, tried it on my blog and the insights it gave are helpful and not bluff.