CDN גורם לנכסים הסטטיים שלכם לטוס. תמונות, CSS, JavaScript, פונטים, הכל מוגש מנקודה קרובה לגולש במקום מהשרת המקורי שנמצא במרחק חצי כדור הארץ. אבל ברגע שמישהו מוסיף עגלת קניות, טופס התחברות, או דשבורד אישי, פתאום הצוות מפחד לגעת בהגדרות ה-CDN בכלל. אם שומרים הכל במטמון, המשתמשים רואים מחירים לא מעודכנים. אם לא שומרים כלום, מפסידים את רוב היתרון של CDN לשיפור מהירות האתר.
החדשות הטובות: לא חייבים לבחור בין מהירות לעדכניות. פשוט צריך כללי caching שמבינים את ההבדל בין תוכן שלעולם לא משתנה לבין תוכן שמשתנה עבור כל גולש בנפרד.
למה תוכן דינמי שובר הגדרות CDN נאיביות
רוב שירותי ה-CDN שומרים במטמון כברירת מחדל לפי כתובת ה-URL ולפעמים לפי סוג הבקשה. זה עובד מצוין עבור /images/logo.png. אבל זה עובד גרוע מאוד עבור /api/cart או /account/orders, שבהם התגובה תלויה במי שואל, מה נמצא בסשן שלו, או מה קרה חמש שניות קודם.
אם ה-CDN שומר במטמון עמוד מותאם אישית ומגיש אותו לגולש הבא, זו לא רק תקלה. זו בעיית פרטיות ואמון. זו הסיבה שכל כך הרבה צוותים או שמבטלים לגמרי caching בנתיבים דינמיים, או בונים רשימות החרגה מסובכות מבוססות URL שנשברות ברגע שמישהו מוסיף עמוד חדש.
המטרה האמיתית: caching סלקטיבי, לא גורף
הפתרון הוא לא מתג של הכל או כלום. מדובר בללמד את ה-CDN אילו חלקים בתגובה בטוחים לשמירה במטמון ולכמה זמן, תוך שימוש באותות שהאפליקציה שלכם כבר יודעת.
השתמשו בכותרות Cache-Control ככלי העיקרי שלכם
כל תגובה שהשרת שלכם שולח יכולה לשאת כותרת Cache-Control, וזו צריכה להיות מקור האמת שה-CDN מכבד, לא הגדרה שנלחמים נגדה.
- נכסים סטטיים: Cache-Control: public, max-age=31536000, immutable עבור קבצים עם שמות מוצפנים כמו app.a1b2c3.js. מכיוון ששם הקובץ משתנה כשהתוכן משתנה, אפשר לשמור אותם במטמון לשנה שלמה בלי סיכון.
- עמודים חצי-דינמיים: Cache-Control: public, max-age=60, stale-while-revalidate=300 עבור עמוד הבית של בלוג או רשימת קטגוריות שמשתנה מדי פעם אבל לא חייבת להיות מיידית.
- תוכן מותאם אישית לגמרי: Cache-Control: private, no-store עבור עמודי חשבון, עגלות קניות, וכל דבר שקשור לעוגיית סשן.
ההנחיה stale-while-revalidate ראויה לתשומת לב מיוחדת. היא אומרת ל-CDN להגיש את הגרסה השמורה במטמון מיד, תוך הבאת עותק מעודכן ברקע. הגולש שלכם לעולם לא מחכה לעדכון, והגולש הבא מקבל את הגרסה החדשה. כותרת אחת זו מבטלת את רוב הפשרה בין מהירות לעדכניות עבור תוכן שמתעדכן כל כמה דקות ולא כל כמה שניות.
שנו את המטמון לפי המפתחות הנכונים
לפעמים עמוד הוא ברובו סטטי אבל שונה מעט לפי עוגייה, שפה, או מכשיר. במקום לסמן את כל העמוד כלא ניתן לשמירה במטמון, השתמשו בכותרת Vary כדי לומר ל-CDN לשמור עותקים נפרדים במטמון עבור כל וריאציה.
Vary: Accept-Language, Cookieשימו לב כאן. שינוי לפי Cookie בלי לצמצם אותה יכול לפוצץ את המטמון שלכם לאלפי רשומות כמעט זהות, אחת לכל סשן ייחודי, מה שמבטל את המטרה כולה. רוב שירותי ה-CDN מאפשרים לציין אילו שמות עוגיות באמת חשובים, כך שתשנו רק לפי אלה שמשפיעות על התגובה, כמו מטבע או העדפת שפה, ולא עוגיות מעקב אנליטיות.
פצלו עמודים לחלקים ניתנים לשמירה במטמון ולחלקים שלא
עמוד מוצר יכול להיות זהה ב-95% מהמקרים עבור כל גולש, כאשר רק באנר "ברוכה השבה, שרה" ומספר פריטים בעגלה משתנים. במקום להפוך את כל העמוד ללא ניתן לשמירה במטמון, הרבה צוותים שומרים את מסגרת העמוד בקצה הרשת וטוענים את החלקים המותאמים אישית באמצעות קריאת JavaScript קטנה בצד הלקוח לנקודת קצה API שלא שמורה במטמון. הדפוס הזה, שנקרא לפעמים edge-side includes או hydration בצד הלקוח, מאפשר ל-CDN לשיפור מהירות אתרים לעשות את העבודה על 95% ממשקל העמוד, כאשר רק הקטע הקטן המותאם אישית מגיע לשרת המקורי.
קבעו זמני TTL הגיוניים לפי הקצב שבו התוכן באמת משתנה
טעות נפוצה היא לבחור TTL אחד לכל האתר. במקום זאת, התאימו את משך השמירה במטמון לתדירות שבה כל סוג תוכן משתנה במציאות:
- תמונות מוצרים ו-CSS: שמרו לשנה, השתמשו בשמות קבצים עם גרסאות
- פוסטים בבלוג ועמודי שיווק: שמרו ל-5-15 דקות עם stale-while-revalidate
- עמודי קטגוריה ותוצאות חיפוש: שמרו ל-60-120 שניות
- נתוני מחיר ומלאי: שמרו ל-10-30 שניות, או הגישו ללא שמירה במטמון עם שרת מקור מהיר
- עגלה, קופה, עמודי חשבון: לעולם אל תשמרו במטמון
המספרים האלה אינם חוקים אוניברסליים, הם נקודת התחלה. עקבו אחר נתוני האנליטיקה של ה-CDN שלכם לגבי אחוז פגיעות במטמון לכל נתיב. אחוז פגיעות מעל 80% בתוכן שניתן לשמור במטמון בדרך כלל אומר שה-TTL שלכם עובד היטב. אם נתיב נמצא מתחת ל-50%, או שה-TTL קצר מדי, או שהנתיב בכלל לא צריך להישמר במטמון בקצה הרשת.
נקו את המטמון במקום לחכות
TTL קצר הוא רשת ביטחון, לא אסטרטגיה. אם פרסמתם פוסט בבלוג או עדכנתם מחיר, לא אמורים לחכות חמש דקות עד שהמטמון יתעדכן. רוב שירותי ה-CDN תומכים בניקוי מטמון פרוגרמטי, לפי URL, לפי תגית, או לפי דפוס wildcard. שילוב זה בתהליך הפרסום שלכם, כך שלחיצה על "פרסם" גם שולחת בקשת ניקוי, מאפשר לכם לקבוע TTL ארוך יותר בכל מקום בלי לוותר על עדכניות כשזה באמת חשוב.
ניקוי מבוסס תגיות עדיף על ניקוי מבוסס URL
אם ה-CDN שלכם תומך בתגיות מטמון, השתמשו בהן. במקום לעקוב אחר כל URL שכולל פיסת תוכן מסוימת (מוצר שמופיע בעמוד שלו, בעמוד קטגוריה, ובקרוסלה בעמוד הבית), תייגו את שלוש התגובות עם product-1234 ונקו את התגית הבודדת הזו כשהמוצר מתעדכן. זו עלות הקמה קטנה שחוסכת הרבה כאבי ראש בהמשך.
אל תשכחו את הצד של השרת המקורי במשוואה
שום דבר מכל זה לא משנה אם השרת המקורי שלכם איטי כשה-CDN באמת צריך לבדוק. שמירה במטמון של אובייקטים בשרת שלכם, באמצעות משהו כמו Redis לשמירת תוצאות שאילתות מסד נתונים בזיכרון, שומרת על מהירות הבדיקה החוזרת ברקע גם בנתיבים מותאמים אישית או חצי-דינמיים. אנחנו מפעילים סוג זה של caching באופן אוטומטי עבור אתרי WordPress בפלטפורמה שלנו, עם דשבורד שמציג אחוזי פגיעה אמיתיים, כך שהשרת המקורי נשאר מהיר גם כשה-CDN לא יכול לעזור. להבנה מעמיקה יותר של מה שקורה בין ה-CDN לשרת שלכם, ראו איך CDN משנה את הגיאוגרפיה של ביצועי האתר שלכם.
כדאי גם להבין למה זמן התגובה הראשוני (time to first byte) משפיע על ההמרות, מכיוון שכל פספוס במטמון תלוי בסופו של דבר במהירות תגובת השרת המקורי. אם אתם בוחרים CDN מלכתחילה, המדריך שלנו על בחירת רשת edge של CDN שמכסה את הקהל שלכם הוא תחנה טובה להמשך.
לסיכום
עדכניות ומהירות אינן הפכים, שתיהן נפתרות באמצעות דיוק. שמרו במטמון בצורה אגרסיבית היכן שהתוכן באמת סטטי, השתמשו ב-TTL קצר עם stale-while-revalidate היכן שהתוכן משתנה בהדרגה, ולעולם אל תשמרו במטמון שום דבר שקשור לסשן או לעגלת קניות. הגדירו תהליך ניקוי כדי שלא תסתמכו רק על TTL ברגעים שבאמת חשובים. אם תסדרו את כללי ה-caching האלה נכון, CDN לשיפור מהירות אתרים יפסיק להיות קופסה שחורה מסוכנת ויהפוך לאחד השיפורי הביצועים האמינים ביותר שאתם יכולים לעשות.
לשמירה במטמון בצד השרת שמשתלבת היטב עם ההגדרה הזו, ראו את הסקירה שלנו על caching ברמת השרת או בדקו איך עובד caching עם Redis באירוח מנוהל.
