# Croct fetch in my loader adds latency when the network is slow, how do I cap it?

Asked by matt_h on 2026-07-29. Tags: hydrogen, performance, loaders.

Benchmarking my loaders. On a good connection the content fetch is fine. On a
bad upstream connection it waits, and TTFB spikes with it.

I do not want a slow response holding up the whole Hydrogen page. Is there a way
to bound that wait so the loader gives up and moves on past some threshold

## 2 answers

### Answer from Diego Fuentes (2026-07-31)

There is a timeout for exactly this. The JS SDK default is 5000ms, which is
why a bad upstream can sit there a while before failing. You can bring that
down globally with `defaultFetchTimeout` on the plug options, or pass a
`timeout` per fetch when one slot has a tighter budget than the rest:

```ts
const {content} = await context.croct
    .fetchContent('home-hero@1', {timeout: 500});
```

Set it to the latency budget you actually have for that route and the loader
stops waiting past it instead of dragging TTFB with the upstream.

### Answer from Priya Raghavan (2026-08-01)

The timeout on its own only bounds the wait, it does not decide what renders
when the wait runs out. Pair it with a fallback so a slow or failed fetch still
serves default content rather than erroring:

```ts
const {content} = await context.croct
    .fetchContent('home-hero@1', {timeout: 500, fallback: defaultHero});
```

Since resolution is server-side in the loader, that fallback renders straight
into the HTML with no client-side flicker. In the normal case none of this even
triggers, the documented end-to-end response times are under 90 milliseconds at
P95, so the timeout is really just the floor under your worst case.

#### Reply from matt_h (2026-08-01)

Dropped it to 500ms with the fallback. TTFB flat now even when I throttle
the upstream. thanks both