Delivering content fast: caching and what callers can do

OmniCon works hard to return content quickly and safely, but a request still has to travel from your app to OmniCon and back. The biggest speed wins come from not making that round trip at all. This page explains what OmniCon does on its side — and the few things you can do on the caller side to cut traffic and latency.

What OmniCon does for you

• Server-side read cache. Single-entity reads — a channel, an article — are cached close to the API, so repeat requests don't re-query the database every time.
• Write-through invalidation. When content is created, updated, or deleted, the cached copy is dropped immediately. An edit is visible on the next read rather than after a delay.
• A short freshness window. Anything the cache can't explicitly invalidate expires on its own within roughly a minute or two, so stale content has a hard upper bound.
• Safe by default. The cache is never load-bearing. If it is unavailable the API simply reads from the source — you get correct data, just a little slower.
• Lean transport. HTTPS everywhere, JSON payloads kept small with lite list projections, pagination, and per-culture results.

The practical takeaway: content you read is fresh within a minute or two of any change, and you never need to defeat caching to "see your edit" — that is already handled for you.

What you can do on the caller side

Because OmniCon's own freshness window is short and predictable, you can safely cache on your side too. These are ordered from biggest payoff to smallest.

1. Cache responses in your application. Most OmniCon read endpoints are POST with a JSON body, because the filter shape is rich — and POST responses are not cached by browsers or CDNs automatically. Keep a small in-process or shared cache keyed on the request parameters (channel, permaName, culture, page) and reuse it for about a minute before re-fetching. This one change removes most of your repeat traffic.
2. Put a CDN or reverse proxy in front of your own site. If you render public pages from OmniCon content, cache your rendered HTML at the edge for a short TTL. Visitors are then served from the edge and never trigger an API call at all — the largest possible latency and traffic win.
3. Use conditional requests where the endpoint is a GET. A few reads are plain GET (for example, fetching a channel by permalink). For those, standard HTTP caching and If-None-Match / 304 Not Modified work normally — let your HTTP client honor them.
4. Don't over-poll. There is no value in fetching the same article every few seconds; OmniCon content doesn't change that fast and your own cache window already covers it. Refresh on the order of a minute, or on a user action, not on a tight timer.
5. Ask for only what you need. Use the lite list projection when you only need titles and permalinks, paginate instead of pulling everything, and request a single culture rather than fetching all and filtering client-side. Smaller responses transfer faster and cache cheaper.
6. Fail soft. If a request times out or errors, serve your last-known-good cached copy instead of an error page. Combined with a short refresh window, this keeps your site up through a transient hiccup.

A sensible default

For most sites, two settings cover it: cache OmniCon read responses in your app for about 60 seconds, and cache your own rendered public pages at a CDN for a similarly short TTL. That keeps content fresh within roughly a minute end to end — matching OmniCon's own window — while removing the vast majority of redundant requests.

If a page must reflect an edit instantly — a correction, a takedown — bypass your own cache for that one read, or purge the affected entry. OmniCon's side already invalidates on write, so the only staleness left is whatever you introduced on your side and chose to keep short.

See Endpoints for which reads are GET vs. POST, and Examples for the request shapes to key your cache on.