Error 1204 concerns memory used by a Cloudflare Snippet, separate from PHP at the WordPress host. Compare the failing input with a smaller one and inspect what the edge code retains.
Full response buffering, extra copies and broad matching rules can increase the workload. The correction should keep the intended output while reducing unnecessary retained data.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Identify what the Snippet keeps in memory
| Comparison | Inspect | Possible correction to evaluate |
|---|---|---|
| Large response fails, short page works | Body reading and derived data | Avoid unnecessary complete copies |
| Media/export unexpectedly matches | Rule scope and content type | Limit processing to intended inputs |
| Response cloned for inspection | Each consumer and retained data | Remove an unnecessary debug branch |
| Only one transformation fails | Required context and allocations | Suitable supported processing design |
| PHP limit raised, same 1204 | Which runtime enforces the limit | Review Snippet code |
Identify the request that uses the most memory
Keep the exact URL and note whether smaller pages still work. If the error appears on a large response but not a short page, the amount of data being processed is a useful clue. It does not prove which operation is responsible, but it gives the developer a focused comparison.
For example, a Snippet written for ordinary article pages might also match a large export or media response. If it reads every matching body before modifying it, the broader rule can expose it to data the initial test never covered.
Compare the matching rule with the feature’s actual purpose. A modification needed only for HTML pages should not be assumed appropriate for every file and endpoint on the hostname.
Look for complete copies of a response body
Draw the data path for the failing request: incoming response, decoded text, parsed object, transformed result and returned body. Mark which copies exist at the same time. This is a review of the actual implementation, not an assumption that every response transformation has identical memory needs.
Reading a body as text or parsed data can require holding it in memory. Additional copies or derived structures may increase the amount retained during processing. The original download size is therefore not always the whole memory story.
A developer can review whether the feature actually needs the complete body. If it only changes headers, reading the body may be unnecessary. If it modifies content, a suitable streaming approach may reduce the need to keep all of it at once, provided the platform and operation support that approach.
This is a design review rather than a recommendation to rewrite every Snippet the same way. Some transformations genuinely need more context, and the chosen method must preserve the feature’s output.
Review cloned and split streams carefully
Cloning a response allows more than one consumer to read its body, but it is not automatically memory-free. MDN explains that unread data can accumulate for the slower branch, and a body can be buffered when only one branch is consumed.
That matters when code clones a response for inspection while returning or processing another copy. The developer should check what each branch does and whether both are needed. A clone added for debugging can become part of the production memory problem.
Large responses deserve particular care. A design that behaves well on a short test page may retain much more data when one consumer advances faster than the other.
Reduce the work to the feature’s real scope
The matching rule can be narrowed to requests that need the modification, where that fits the intended behavior. The code can also avoid retaining temporary data longer than necessary. Each change should have a clear reason connected to the observed memory use.
Avoid treating a smaller PHP limit or a WordPress cache purge as a remedy for the edge allowance. Those settings belong to different parts of the request. They may matter for other symptoms, but they do not directly expand Snippet memory.
Cloudflare suggests considering Workers when a task needs more memory than Snippets provide. That is an architectural choice: the developer should compare the feature, limits and costs before moving it. A move is not a substitute for understanding unnecessary data copies.
Test representative large inputs
- Retest the original large response.
- Compare a small normal page.
- Include the largest input the feature is intended to support.
- Inspect the required modification and complete content.
- Check resources outside the rule’s intended scope.
After the correction, repeat the request that failed and compare it with a smaller page. Include any large resource that the rule intentionally covers. This checks whether the design fits actual site content rather than only the developer’s simplest example.
Verify the modification itself as well as the absence of an error. A response that opens but loses required content is not a complete repair. Related pages outside the rule’s intended scope should continue behaving normally.
If help is needed, provide the Snippet name, matching rule, approximate response size and a concise description of how the code processes the body. Keep private content and credentials out of public examples.
Cloudflare defines 1204 in its Snippet troubleshooting guide. MDN’s Response.clone reference explains buffering behavior that can be relevant when reviewing memory use.
Keep the supported workload explicit
Record the response type, approximate size, selected rule and verified output. If the task requires a different edge design, compare current capabilities and cost with the actual workload. A page that loads with missing required content is an incomplete repair.