Moving thumbnail generation from a PHP backend to Cloudflare Workers eliminated all CPU load on the origin server for a video-hosting site that serves millions of images a day. The switch also pushed image-processing latency from the data center to the edge, slashing response times and making bandwidth costs predictable.

Why the old model broke

The site, a platform that displays tens of thousands of videos, embeds up to 40 thumbnails on a single page. Each thumbnail is resized on demand by a PHP script that reads the original file and rescales it. When crawlers visited the site, the backend server would stall.

Edge processing solves the five core requirements

A production-grade thumbnail API must handle:

  • Fan-in – pulling source images from many third-party hosts.
  • Fan-out – producing several sizes (e.g., 320 px cards, 640 px hero images).
  • Format negotiation – serving WebP or AVIF when the browser supports them to cut bandwidth.
  • Cache – ensuring the first request can be expensive but every subsequent request is free.
  • Security – preventing anyone from abusing the service to process arbitrary images.

Cloudflare Workers address each point without touching the origin’s CPU:

  1. Proximity – Workers run in data centers close to the user, so the processed image travels a shorter path.
  2. Built-in Image Resizing – The platform’s Image Resizing feature does the pixel work, removing the need for a custom library.
  3. Cache API – Workers store the resized image at the edge; after the first request the edge serves it directly.
  4. Programmable security – A small script validates HMAC signatures, enforces an allow-list of hostnames and widths, and normalizes cache keys to avoid cache poisoning.

How the system works

  1. Origin creates signed URLs – The back-end holds a secret key and appends an HMAC signature to every thumbnail request. The URL also includes the desired width and format.
  2. Worker verifies the signature – On receipt, the Worker recomputes the HMAC with the shared secret. If the signature is missing or wrong, the request is rejected, stopping abuse.
  3. Allow-list enforcement – The script checks that the source hostname is on a predefined list and that the requested width is one of the supported sizes. This prevents malicious hosts from being cached.
  4. Cache key normalization – The signature itself is stripped from the cache key; the key contains only the source URL, width, and format. This raises the chance that different users requesting the same image hit the same cached entry.
  5. Edge fetch and resize – If the image is not already cached, the Worker fetches the original from the third-party host, runs the Image Resizing API, and stores the result in the edge cache.
  6. Cache warming – After every crawl, a lightweight Python script pre-requests the newest thumbnails. The first real user therefore receives a cached response instead of waiting for the resize operation.

Measurable impact after one month

  • Origin CPU for images – Dropped to zero; the back-end never processes image bytes again.
  • HTML serving speed – Improved noticeably because the server no longer blocks on image work.
  • Edge cache hit rate – Reached 96 %, meaning almost every request was satisfied from the edge without a backend fetch.
  • Latency – Fell as images are now served from a data center near the user rather than a central origin.
  • Bandwidth predictability – With edge caching, outbound traffic from the origin is stable and easy to forecast.

Bottom line

Offloading thumbnail generation to Cloudflare Workers turned a CPU-bound bottleneck into a near-zero-cost edge cache. The origin now only issues signed URLs, while the edge handles fetching, resizing, negotiating formats, and serving cached results. For any site that relies heavily on images—especially video platforms that display dozens of thumbnails per page—the edge-first approach delivers faster pages, predictable costs, and a cleaner separation between “what to show” (origin) and “how to deliver it” (edge).