API reads behind this page
2 over the wire, 7 from cache ·
33 ms total · template: Default Parts List
| Method |
Path |
Source |
Status |
Time |
| GET |
/slugs('dia') |
cache
1h
|
—
|
—
|
| GET |
/products/13342?$expand=items,media,attributes,related,applications,fitment,tabs,documents,modifiers |
cache
1m
|
—
|
—
|
| GET |
/v2/products/13342?$expand=pricing |
network
|
200
|
25 ms
|
| GET |
/slugs('dia') |
asked twice
|
—
|
—
|
| GET |
/me |
cache
30m
|
—
|
—
|
| GET |
/items(…)/attributes ×3 |
cache
30m
|
—
|
—
|
| GET |
/v2/products/13342/diagram |
network
|
200
|
8 ms
|
| GET |
/categories |
cache
15m
|
—
|
—
|
204 and 404 both mean “no rows” on this API — which of the two
an endpoint uses is per-endpoint, and the client maps both to an empty
result rather than an error. Collections come wrapped in an OData
envelope and are capped at 100 rows per page.
Rows marked cache were answered from memory,
and the time beside each is how long that kind of read is held; one marked
asked twice is something this page had already
read while rendering, so it cost nothing either way. Catalog reads are
cached by rate of change rather than on one site-wide
timer:
- Slugs 1h
- Vehicles 1h
- Identity (/me) 30m
- Brands 30m
- Item attributes 30m
- Navigation 15m
- Categories 5m
- Product structure 1m
- Anything absent 1m
- Price and stock never cached
Pricing and stock are read live on every view — there is
no setting that caches them. That is why a warm product page still makes
exactly one request: everything else on it came from memory.
The catalog can also drop all of it at once rather than waiting for a
tier to lapse, by calling POST /hooks/cache when it
publishes.
