מטמון HTML בקצה (Edge HTML Caching) הוא שמירה של עמודי האתר המוגמרים — ה-HTML עצמו, לא רק תמונות וקבצי CSS — בשרתים של ה-CDN, כך שגולש מקבל את העמוד משרת קרוב אליו בלי שהבקשה תגיע בכלל לשרת של האתר. זה אחד השיפורים הגדולים ביותר האפשריים בזמן תגובה, כי הוא מוריד כמעט לאפס את הזמן עד הבייט הראשון. אבל יש סיבה שזה לא מופעל כברירת מחדל: לפי התיעוד של Cloudflare, "ה-CDN של Cloudflare לא שומר HTML או JSON במטמון כברירת מחדל". עמוד HTML יכול להיות אישי, ומטמון לא נכון יכול להגיש לגולש אחד את העגלה, את שם המשתמש או את התוכן של גולש אחר. במאמר הזה אני מסביר איך עושים את זה בבטחה.
מה Cloudflare שומר כברירת מחדל
לפי אותו תיעוד, השמירה מבוססת על סיומת הקובץ: תמונות (JPG, PNG, WebP, AVIF, SVG ועוד), קבצי CSS ו-JS, פונטים, וידאו ומסמכים — כן; HTML — לא. לכן ברוב האתרים שמאחורי Cloudflare, הקבצים הסטטיים מוגשים מהקצה, אבל כל בקשה לעמוד עצמו עדיין מגיעה לשרת. כשבודקים את כותרות התגובה של עמוד, רואים את זה בכותרת cf-cache-status: הערך DYNAMIC אומר שהעמוד לא נשמר. כך זה גם באתר הזה, נכון לאוקטובר 2026 — עמודי ה-HTML מסומנים DYNAMIC ומוגשים מהשרת. על שכבות המטמון השונות כתבתי במאמר מטמון באתר.
איך מפעילים מטמון HTML
ב-Cloudflare עושים את זה עם Cache Rule: כלל שאומר שבקשות מסוימות "זכאיות למטמון" (Eligible for cache). לפי התיעוד של הגדרות Cache Rules, בכלל קובעים:
- Edge TTL — כמה זמן העמוד נשמר בשרתי Cloudflare: לפי כותרת
Cache-Controlשהשרת שולח, או זמן קבוע שמתעלם ממנה. - Browser TTL — כמה זמן הדפדפן של הגולש שומר. ל-HTML, בדרך כלל עדיף זמן קצר מאוד בדפדפן, כדי שאפשר יהיה לעדכן תוכן.
- מפתח המטמון — מה הופך שתי בקשות ל"אותו עמוד": האם מחרוזות שאילתה נספרות, האם מפרידים לפי מכשיר.
- הגשת גרסה ישנה בזמן רענון — האם להגיש לגולש את העותק הקיים בזמן ש-Cloudflare מביא גרסה חדשה מהשרת.
התיעוד מציין גם מתי Cloudflare לא ישמור תגובה, גם אם יש כלל: כשיש כותרת Set-Cookie, כשכותרת Cache-Control היא private, no-store, no-cache או max-age=0, ובכל בקשה שאינה GET. ההתנהגות הזו היא רשת ביטחון חשובה, אבל לא מספיק לסמוך עליה לבד.
הכלל החשוב ביותר: מה לא לשמור
הסכנה במטמון HTML היא להגיש עמוד אישי לגולש אחר. לכן הכלל צריך לעקוף את המטמון (Bypass) במקרים האלה:
- משתמשים מחוברים — בוורדפרס, עוגייה שמתחילה ב-
wordpress_logged_in. - עגלה וקופה — בווקומרס, עוגיות העגלה והסשן, וכתובות כמו העגלה, הקופה והחשבון.
- ממשק הניהול והתחברות — wp-admin ו-wp-login.
- תצוגה מקדימה, חיפוש ותגובות שעדיין ממתינות לאישור.
- בקשות שאינן GET — שליחת טפסים, למשל.
דוגמה לביטוי של כלל כזה (כלל שמחריג, לפני כלל שמאפשר):
(http.cookie contains "wordpress_logged_in") or (http.cookie contains "woocommerce_items_in_cart") or (starts_with(http.request.uri.path, "/wp-admin"))
ההגדרות המדויקות תלויות באתר: לכל תוסף שמשתמש בעוגיות משלו — שפות, מטבעות, חברות — צריך לבדוק אם הוא משנה את תוכן העמוד.
הבעיה השנייה: עדכון תוכן
כשהעמוד נשמר בקצה לשעות, עריכה בוורדפרס לא תופיע עד שהעותק יפוג — אלא אם מנקים אותו. לפי התיעוד של ניקוי המטמון, אפשר לנקות לפי כתובת בודדת (השיטה המומלצת), לפי שם מארח, לפי קידומת, לפי תגיות, או את הכול — ויש מגבלות קצב לפי תוכנית; בתוכנית החינמית, למשל, ניקוי לפי כתובת מוגבל ל-800 כתובות בשנייה. גישה מעשית:
- ניקוי אוטומטי לפי כתובת כשפוסט מתעדכן: העמוד עצמו, דף הבית, עמודי הקטגוריה והתגיות שלו, ומפת האתר. כאן תוסף מטמון או קוד ייעודי מתחבר ל-API של Cloudflare.
- זמן שמירה סביר — גם אם הניקוי נכשל, העמוד יתעדכן בסוף.
- לא "לנקות הכול" בכל שינוי — זה מבטל את התועלת, כי כל האתר נטען שוב מהשרת.
איך בודקים שזה עובד
טוענים עמוד פעמיים ובודקים את הכותרת cf-cache-status: בבקשה הראשונה MISS, בשנייה HIT. אחר כך בודקים את ההפך — מתחברים לאתר, או מוסיפים מוצר לעגלה, ומוודאים שהעמודים מסומנים BYPASS או DYNAMIC ושאתם רואים את התוכן האישי שלכם. ואז עורכים פוסט ובודקים שהשינוי מופיע. ההשפעה על זמן התגובה נראית מיד ב-מדידת TTFB.
שאלות נפוצות
זה מחליף את מטמון העמודים בשרת?
לא — הם משלימים. מטמון השרת מגן כשהעמוד לא נמצא בקצה (בקשה ראשונה, אחרי ניקוי, או בשרת קצה אחר), ומטמון הקצה חוסך את הנסיעה לשרת ברוב הבקשות.
זה מתאים לחנות?
לעמודי מוצר וקטגוריה לגולשים אורחים — כן, עם החרגה זהירה של העגלה, הקופה והחשבון. מחירים ומלאי שמשתנים צריכים ניקוי אוטומטי כשהם מתעדכנים. ראו ווקומרס איטי.
ומה עם פרמטרים כמו utm בכתובת?
כל וריאציה של כתובת עלולה להיחשב עמוד נפרד במטמון. כדאי להגדיר את מפתח המטמון כך שפרמטרי מעקב לא יפצלו אותו; על פרמטרים כאלה כתבתי במאמר פרמטרי UTM.
מטמון HTML בקצה הוא שיפור גדול, אבל הוא דורש תכנון: מה נשמר, מה עוקף ומתי מנקים. אני מגדיר את זה כחלק מעבודת ביצועים, יחד עם השרת והתבנית — פירוט בעמוד שיפור מהירות אתר, או כתבו לי.
אהבתם את המאמר?
