העברת יצירת תמונות ממוזערות (thumbnails) משרת PHP backend ל-Cloudflare Workers ביטלה לחלוטין את עומס ה-CPU בשרת המקור (origin server) עבור אתר אירוח וידאו המגיש מיליוני תמונות ביום. המעבר גם העביר את השיהוי (latency) של עיבוד התמונות ממרכז הנתונים אל ה-edge, מה שקיצץ את זמני התגובה והפך את עלויות רוחב הפס לצפויות.
למה המודל הישן קרס
האתר, פלטפורמה המציגה עשרות אלפי סרטונים, מטמיע עד 40 תמונות ממוזערות בדף בודד. כל תמונה ממוזערת משנה את גודלה לפי דרישה על ידי סקריפט PHP שקורא את הקובץ המקורי ומבצע לו rescaling. כאשר סורקים (crawlers) ביקרו באתר, שרת ה-backend היה נתקע.
עיבוד ב-edge פותר את חמש הדרישות המרכזיות
API לתמונות ממוזערות ברמת ייצור חייב לטפל ב:
- Fan-in – משיכת תמונות מקור ממארחים רבים של צד שלישי.
- Fan-out – יצירת מספר גדלים (למשל, כרטיסים של 320px, תמונות hero של 640px).
- Format negotiation – הגשת פורמטים של WebP או AVIF כאשר הדפדפן תומך בהם כדי לחסוך ברוחב פס.
- Cache – הבטחה שהבקשה הראשונה עשויה להיות יקרה, אך כל בקשה עוקבת תהיה בחינם.
- Security – מניעת ניצול לרעה של השירות לצורך עיבוד תמונות שרירותיות על ידי כל משתמש.
Cloudflare Workers נותנים מענה לכל אחת מהנקודות הללו מבלי לגעת ב-CPU של ה-origin:
- Proximity – ה-Workers רצים במרכזי נתונים קרובים למשתמש, כך שהתמונה המעובדת עוברת מסלול קצר יותר.
- Built-in Image Resizing – תכונת ה-Image Resizing של הפלטפורמה מבצעת את עבודת הפיקסלים, מה שמסיר את הצורך בספרייה מותאמת אישית.
- Cache API – ה-Workers שומרים את התמונה המוקטנת ב-edge; לאחר הבקשה הראשונה, ה-edge מגיש אותה ישירות.
- Programmable security – סקריפט קטן מאמת חתימות HMAC, אוכף רשימת הרשאות (allow-list) של שמות מארחים ורוחב תמונות, ומנרמל מפתחות cache כדי למנוע cache poisoning.
איך המערכת עובדת
- Origin creates signed URLs – ה-back-end מחזיק מפתח סודי ומצרף חתימת HMAC לכל בקשה לתמונה ממוזערת. ה-URL כולל גם את הרוחב והפורמט הרצויים.
- Worker verifies the signature – עם קבלת הבקשה, ה-Worker מחשב מחדש את ה-HMAC באמצעות המפתח המשותף. אם החתימה חסרה או שגויה, הבקשה נדחית, מה שמונע ניצול לרעה.
- Allow-list enforcement – הסקריפט בודק ששם המארח (hostname) של המקור נמצא ברשימה מוגדרת מראש ושהרוחב המבוקש הוא אחד מהגדלים הנתמכים. זה מונע שמירה ב-cache של מארחים זדוניים.
- Cache key normalization – החתימה עצמה מוסרת ממפתח ה-cache; המפתח מכיל רק את ה-URL של המקור, הרוחב והפורמט. זה מגדיל את הסיכוי שמשתמשים שונים המבקשים את אותה תמונה יפגעו באותה רשומה ב-cache.
- Edge fetch and resize – אם התמונה עדיין לא נמצאת ב-cache, ה-Worker שולף את המקור מהמארח של צד שלישי, מריץ את ה-Image Resizing API ושומר את התוצאה ב-edge cache.
- Cache warming – לאחר כל סריקה (crawl), סקריפט Python קל מבצע בקשות מראש (pre-requests) לתמונות הממוזערות החדשות ביותר. כך, המשתמש האמיתי הראשון מקבל תגובה מה-cache במקום לחכות לפעולת ה-resize.
השפעה מדידה לאחר חודש אחד
- Origin CPU for images – ירד לאפס; ה-back-end כבר לא מעבד בייטים של תמונות לעולם.
- HTML serving speed – השתפרה באופן ניכר מכיוון שהשרת כבר לא נחסם על ידי עיבוד תמונות.
- Edge cache hit rate – הגיע ל-96%, מה שאומר שכמעט כל בקשה נענתה מה-edge ללא שליפה מה-backend.
- Latency – ירד מכיוון שהתמונות מוגשות כעת ממרכז נתונים קרוב למשתמש במקום משרת מקור מרכזי.
- Bandwidth predictability – עם edge caching, תעבורת ה-outbound מה-origin יציבה וקל לחזות אותה.
שורה תחתונה
העברת יצירת התמונות הממוזערות ל-Cloudflare Workers הפכה צוואר בקבוק של עומס CPU ל-edge cache בעל עלות אפסית כמעט. ה-origin כעת רק מנפיק signed URLs, בעוד ה-edge מטפל בשליפה, בשינוי גודל, בניהול פורמטים ובהגשת תוצאות מה-cache. עבור כל אתר המסתמך רבות על תמונות — במיוחד פלטפורמות וידאו המציגות עשרות תמונות ממוזערות בכל דף — גישת ה-edge-first מספקת דפים מהירים יותר, עלויות צפויות והפרדה נקייה יותר בין "מה להציג" (origin) לבין "איך לספק את זה" (edge).