Is SDCH an AI model or training method?

No. It concerns compressed web delivery. AI applications can generate or serve content over HTTP, but the transport technique is separate from model behavior.

Does a dictionary need to be sent with every response?

The shared-dictionary idea relies on retaining it for reuse. The server still needs evidence that the client possesses an applicable dictionary.

Is modern Compression Dictionary Transport identical to SDCH?

No. They share the broad objective of cross-resource compression, but differ in protocol details and design. Use documentation for the actual mechanism being evaluated.

AI Glossary / MLOps and deployment / Intermediate

SDCH

Definition

SDCH stands for Shared Dictionary Compression over HTTP. It was an approach to reducing web-response sizes by using a dictionary of repeated byte sequences already shared between a server and a browser. It is a historical protocol, distinct from newer Compression Dictionary Transport mechanisms.

What it means

Many pages from one service contain similar markup, scripts or other repeated material. Compressing each response independently can rediscover that repetition every time. A shared dictionary lets later responses refer to material the browser already possesses instead of transmitting it again.

The dictionary is compression data, not a glossary or a language-model vocabulary. The goal is to reconstruct the exact response bytes. For an AI website, SDCH is relevant as background in web delivery and compression history; it does not perform inference, summarize content or change the meaning of a generated answer.

How it works

In the historical proposal, a supporting client advertised SDCH capability. A server could identify a downloadable dictionary, and a client with an applicable dictionary advertised its identifier in subsequent requests. The server could then encode a response against that dictionary and identify the encoding in the response.

The encoding used VCDIFF to express reconstruction using the shared data. Dictionary scope and lifetime determined where and when it could apply. An ordinary response remained necessary when support or an appropriate dictionary was absent.

These negotiation rules are specific to SDCH. Modern shared-dictionary systems have their own headers, encodings and security model; copying an old SDCH configuration does not implement a newer protocol.

Three practical examples

1. Historical search-page delivery: repeated page scaffolding can be separated from query-specific content in the compression representation. A shared dictionary may reduce repeated transmission even when the complete pages cannot be reused from cache.

2. Legacy traffic analysis: an engineer investigating an archived network trace may encounter SDCH-related encoding or dictionary headers. Recognizing them explains why the compressed body cannot be decoded from that response alone.

3. Web-performance education: a team can use SDCH to study the difference between within-response compression and compression that depends on state established by earlier responses. This distinction remains useful when evaluating newer mechanisms.

Think of it this way

Think of two colleagues agreeing on a reference booklet. Later messages can say “insert paragraph seven” instead of copying its full text. Both must have the same booklet edition, and the initial delivery of the booklet has a cost.

The analogy stops at the wire format. Compression references address byte sequences through a defined algorithm; they are not human instructions. A dictionary identifier also does not remove the need for appropriate transport and security controls.

Worked example

Consider a hypothetical shared-dictionary experiment inspired by SDCH. A dictionary costs 30 kilobytes to transfer. Without it, each relevant response transfers 12 kilobytes after ordinary compression. With it, each response transfers 7 kilobytes. Assume these are measured payload sizes, and temporarily ignore extra headers and request latency.

Each dictionary-assisted response saves 5 kilobytes. After four such responses, savings total 20 kilobytes, which does not repay the 30-kilobyte dictionary download. Total transfer is 30+4×7=58 kilobytes, compared with 4×12=48 kilobytes without the dictionary.

At six responses, the payload totals tie at 72 kilobytes. At ten, the dictionary approach transfers 100 kilobytes versus 120 kilobytes, saving 20 kilobytes overall.

This simplified break-even calculation assumes the same dictionary remains applicable and cached throughout. Eviction, frequent dictionary changes, extra headers and users leaving after one response can alter the result. These invented numbers illustrate the accounting; they are not measured SDCH or Google performance results.

Illustrative case study

Fictional case: PageWeave discovers an old SDCH experiment while reviewing its web-delivery architecture. The archived report measures response sizes only after the test browser has downloaded a dictionary.

The team reconstructs the experiment's accounting and notices that first visits, dictionary downloads and cache misses were excluded. It also separates the historical SDCH design from the modern protocol it is considering.

For a new evaluation, it measures complete sessions under cold and warm cache conditions, checks fallback behavior and includes dictionary lifecycle costs. This fictional case shows how an impressive compression ratio can answer a narrower question than the business actually needs: total transfer and user experience across real sessions.

Common misconceptions and mistakes

“SDCH is another name for all dictionary compression.” It names a particular historical HTTP proposal and encoding arrangement. Shared dictionaries are a broader concept.

“The browser can decode with any similar dictionary.” Reconstruction requires the correct dictionary bytes. Similar-looking content is insufficient.

“A smaller response guarantees a faster first visit.” Dictionary acquisition, additional work and request timing can offset payload savings. Measure the complete experience.

“Compression and caching are the same.” Caching can reuse a whole resource. Dictionary compression can help reconstruct a different response using previously stored material, but it still needs encoded response data.

Business use

For a new website project, treat SDCH as historical context and check the current protocol and implementation documentation for any proposed shared-dictionary deployment. The reusable business question is whether repeated content across responses is substantial enough to justify dictionary distribution and management.

Evaluate repeat-visit patterns, dictionary refresh frequency, compatibility, fallback traffic and total delivery cost. Security review is also part of the protocol decision: Chrome's retrospective identifies side-channel concerns among SDCH's drawbacks. An old compression benchmark is therefore not evidence that reviving the old mechanism is an appropriate deployment choice.

Check your understanding

A dictionary saves five kilobytes per response but costs thirty kilobytes to download. Has a two-response session saved payload bytes?

Answer: No. Ten kilobytes of response savings do not repay the thirty-kilobyte dictionary cost, under those assumptions.

Related terms

Delta encoding
Brotli
HTTP compression
shared dictionary
VCDIFF
caching
Compression Dictionary Transport

Learn next

Learn HTTP content negotiation and ordinary response compression first. Then compare cold-cache and warm-cache session measurements, and read current shared-dictionary specifications before applying the historical idea to a new service.

Sources

Primary historical proposal: “A Proposal for Shared Dictionary Compression over HTTP,” an Internet-Draft rather than a final standard: https://datatracker.ietf.org/doc/html/draft-lee-sdch-spec-00 . Primary retrospective and successor context: Chrome Developers, “Improving Google Search with Compression Dictionaries”: https://developer.chrome.com/blog/search-compression-dictionaries . All numerical and fictional examples here are illustrative.

Previous: Scoring Next: Sealed-bid auction