Het verplaatsen van de generatie van thumbnails van een PHP-backend naar Cloudflare Workers heeft de volledige CPU-belasting op de origin-server geëlimineerd voor een video-hostingwebsite die miljoenen afbeeldingen per dag serveert. De overstap heeft de latentie van de beeldverwerking ook verplaatst van het datacenter naar de edge, waardoor de responstijden drastisch zijn verlaagd en de bandbreedtekosten voorspelbaar zijn geworden.

Waarom het oude model niet meer werkte

De site, een platform dat tienduizenden video's weergeeft, bevat tot wel 40 thumbnails op een enkele pagina. Elke thumbnail wordt op aanvraag aangepast door een PHP-script dat het originele bestand inleest en herschaalt. Wanneer crawlers de site bezochten, liep de backend-server vast.

Edge-verwerking lost de vijf kernvereisten op

Een thumbnail-API van productiekwaliteit moet het volgende kunnen afhandelen:

  • Fan-in – het ophalen van bronafbeeldingen van vele externe hosts.
  • Fan-out – het produceren van verschillende formaten (bijv. 320px kaarten, 640px hero-afbeeldingen).
  • Format negotiation – het serveren van WebP of AVIF wanneer de browser dit ondersteunt om bandbreedte te besparen.
  • Cache – ervoor zorgen dat de eerste aanvraag weliswaar kostbaar kan zijn, maar elke daaropvolgende aanvraag gratis is.
  • Security – voorkomen dat iemand misbruik maakt van de service om willekeurige afbeeldingen te verwerken.

Cloudflare Workers pakken elk punt aan zonder de CPU van de origin te belasten:

  1. Proximity – Workers draaien in datacenters die dicht bij de gebruiker staan, waardoor de verwerkte afbeelding een kortere weg aflegt.
  2. Built-in Image Resizing – De Image Resizing-functie van het platform doet het pixelwerk, waardoor een aangepaste bibliotheek niet meer nodig is.
  3. Cache API – Workers slaan de verkleinde afbeelding op aan de edge; na de eerste aanvraag serveert de edge deze direct.
  4. Programmable security – Een klein script valideert HMAC-handtekeningen, handhaaft een allow-list van hostnames en breedtes, en normaliseert cache-keys om cache poisoning te voorkomen.

Hoe het systeem werkt

  1. Origin maakt ondertekende URL's aan – De backend bevat een geheime sleutel en voegt een HMAC-handtekening toe aan elke thumbnail-aanvraag. De URL bevat ook de gewenste breedte en het formaat.
  2. Worker verifieert de handtekening – Bij ontvangst berekent de Worker de HMAC opnieuw met de gedeelde geheime sleutel. Als de handtekening ontbreekt of onjuist is, wordt de aanvraag geweigerd, wat misbruik voorkomt.
  3. Handhaving van de allow-list – Het script controleert of de bron-hostname op een vooraf bepaalde lijst staat en of de gevraagde breedte een van de ondersteunde formaten is. Dit voorkomt dat kwaadaardige hosts in de cache terechtkomen.
  4. Normalisatie van de cache-key – De handtekening zelf wordt uit de cache-key verwijderd; de key bevat alleen de bron-URL, breedte en het formaat. Dit vergroot de kans dat verschillende gebruikers die dezelfde afbeelding opvragen, dezelfde gecachte vermelding raken.
  5. Edge fetch en resizing – Als de afbeelding nog niet in de cache staat, haalt de Worker het origineel op bij de externe host, voert de Image Resizing API uit en slaat het resultaat op in de edge-cache.
  6. Cache warming – Na elke crawl vraagt een lichtgewicht Python-script vooraf de nieuwste thumbnails aan. De eerste echte gebruiker ontvangt daarom een gecachte reactie in plaats van te moeten wachten op de resize-operatie.

Meetbare impact na één maand

  • Origin CPU voor afbeeldingen – Gedaald naar nul; de backend verwerkt nooit meer afbeelding-bytes.
  • Snelheid van HTML-servering – Merkbaar verbeterd omdat de server niet langer geblokkeerd wordt door beeldverwerking.
  • Edge cache hit rate – Bereikte 96%, wat betekent dat bijna elke aanvraag vanuit de edge werd afgehandeld zonder een backend-opvraag.
  • Latentie – Is gedaald omdat afbeeldingen nu worden geserveerd vanuit een datacenter dicht bij de gebruiker in plaats van vanuit een centrale origin.
  • Voorspelbaarheid van bandbreedte – Dankzij edge-caching is het uitgaande verkeer vanaf de origin stabiel en gemakkelijk te voorspellen.

Conclusie

Het verplaatsen van de generatie van thumbnails naar Cloudflare Workers heeft een CPU-gebonden bottleneck veranderd in een edge-cache met vrijwel nul kosten. De origin geeft nu alleen nog ondertekende URL's uit, terwijl de edge het ophalen, verkleinen, onderhandelen over formaten en het serveren van gecachte resultaten afhandelt. Voor elke site die zwaar leunt op afbeeldingen — vooral videoplatforms die tientallen thumbnails per pagina tonen — levert de edge-first aanpak snellere pagina's, voorspelbare kosten en een duidelijkere scheiding tussen "wat er getoond moet worden" (origin) en "hoe het geleverd moet worden" (edge).