מניעת בקשות רשת מיותרות באמצעות מטמון ה-HTTP

איליה גריגוריק
איליה גריגוריק

שליפה של משאבים מהרשת היא תהליך איטי ויקר:

  • תגובות גדולות דורשות פעולות דו-כיווניות רבות בין הדפדפן לשרת.
  • הדף לא נטען עד שכל המשאבים הקריטיים יושלמו במלואו.
  • אם מישהו נכנס לאתר שלכם עם חבילת גלישה מוגבלת, כל בקשה מיותרת לרשת היא בזבוז של הכסף שלו.

איך אפשר להימנע מבקשות רשת מיותרות? מטמון ה-HTTP של הדפדפן הוא קו ההגנה הראשון. זו לא בהכרח הגישה הכי חזקה או גמישה, ויש לכם שליטה מוגבלת על משך החיים של תגובות שנשמרו במטמון, אבל היא יעילה, היא נתמכת בכל הדפדפנים ולא מצריכה עבודה רבה.

מדריך זה מציג את היסודות של יישום יעיל של שמירת HTTP במטמון.

תאימות דפדפן

למעשה לא קיים ממשק API יחיד שנקרא 'מטמון ה-HTTP'. זה השם הכללי של אוסף ממשקי API של פלטפורמת אינטרנט. ממשקי ה-API האלה נתמכים בכל הדפדפנים:

כיצד פועל מטמון HTTP

כל בקשות ה-HTTP שהדפדפן מבצע מנותבות תחילה למטמון של הדפדפן, כדי לבדוק אם יש תגובה חוקית במטמון שאפשר להשתמש בה כדי למלא את הבקשה. אם יש התאמה, התגובה נקראת מהמטמון, וכך מתבטלת גם זמן האחזור של הרשת וגם עלויות הנתונים שיצטברו בהעברה.

ההתנהגות של מטמון ה-HTTP נשלטת על ידי שילוב של כותרות בקשות וכותרות תגובות. בתרחיש אידיאלי, יש לכם שליטה גם על הקוד של אפליקציית האינטרנט (שקובעות את כותרות הבקשות) וגם על ההגדרות של שרת האינטרנט (שקובעות את כותרות התגובות).

למידע מעמיק יותר על מושגים, כדאי לעיין במאמר שמירה במטמון HTTP של MDN.

כותרות הבקשות: נשארות עם ברירות המחדל (בדרך כלל)

יש כמה כותרות חשובות שצריך לכלול בבקשות היוצאות של אפליקציית האינטרנט שלכם, אבל הדפדפן כמעט תמיד יטפל להגדיר אותן בשמכם כשהוא שולח בקשות. כותרות בקשות שמשפיעות על בדיקת העדכניות, כמו If-None-Match ו-If-Modified-Since מופיעות רק על סמך היכולת של הדפדפן להבין את הערכים הנוכחיים במטמון ה-HTTP.

אלה חדשות טובות – המשמעות היא שאפשר להמשיך להוסיף תגים כמו <img src="my-image.png"> ל-HTML, והדפדפן יטפל עבורכם באופן אוטומטי בשמירת HTTP במטמון ללא מאמץ נוסף.

כותרות תגובה: הגדרת שרת האינטרנט

החלק החשוב ביותר בהגדרת שמירת ה-HTTP הוא הכותרות ששרת האינטרנט מוסיף לכל תגובה יוצאת. הכותרות הבאות מביאות בחשבון את ההתנהגות האפקטיבית של השמירה במטמון:

  • Cache-Control. השרת יכול להחזיר הוראת Cache-Control כדי לציין איך, ולמשך כמה זמן, הדפדפן ומטמון הביניים האחרים צריכים לשמור את התגובה המסוימת במטמון.
  • ETag. כשהדפדפן מוצא תגובה שנשמרה במטמון שפג תוקפה, הוא יכול לשלוח לשרת אסימון קטן (בדרך כלל גיבוב של תוכן הקובץ) כדי לבדוק אם הקובץ השתנה. אם השרת מחזיר את אותו אסימון, הקובץ זהה ואין צורך להוריד אותו מחדש.
  • Last-Modified. הכותרת הזו משרתת את אותה מטרה כמו ETag, אבל היא משתמשת באסטרטגיה מבוססת זמן כדי לקבוע אם המשאב השתנה, בניגוד לאסטרטגיה מבוססת-התוכן של ETag.

בשרתי אינטרנט מסוימים יש תמיכה מובנית בהגדרת הכותרות האלה כברירת מחדל, ובאחרים יש להשאיר את הכותרות לחלוטין, אלא אם הגדרתם אותן במפורש. הפרטים הספציפיים לאופן ההגדרה של כותרות משתנים בהתאם לשרת האינטרנט שבו אתם משתמשים, וכדאי לעיין במסמכי התיעוד של השרת כדי לקבל את הפרטים המדויקים ביותר.

כדי לחסוך בחיפוש, ריכזנו כאן הוראות להגדרה של כמה שרתי אינטרנט פופולריים:

אי הכללת כותרת התגובה Cache-Control לא תשבית את שמירת ה-HTTP במטמון! במקום זאת, דפדפנים מנחשים באופן יעיל איזה סוג של התנהגות שמירה במטמון הוא המתאים ביותר לסוג נתון של תוכן. רוב הסיכויים שאתם רוצים יותר שליטה ממה שיש לכם להציע, לכן הקדישו זמן להגדרת כותרות התגובות.

באילו ערכים של כותרת תגובה כדאי להשתמש?

יש שני תרחישים חשובים שצריך להתייחס אליהם כשמגדירים את כותרות התגובות של שרת האינטרנט.

שמירה במטמון לטווח ארוך של כתובות URL עם גרסאות

איך כתובות URL עם גרסאות יכולות לעזור לאסטרטגיית השמירה במטמון
מומלץ להשתמש בכתובות URL עם גרסאות, כי הן מקלות על ביטול התוקף של תגובות שנשמרו במטמון.

נניח שהשרת מורה לדפדפנים לשמור קובץ CSS במטמון למשך שנה (Cache-Control: max-age=31536000), אבל המעצב שלך ביצע עכשיו עדכון למקרה חירום שצריך להשיק אותו באופן מיידי. איך מודיעים לדפדפנים לעדכן את העותק ה "לא פעיל" של הקובץ השמור? אי אפשר, לפחות לא בלי לשנות את כתובת ה-URL של המשאב. אחרי שהדפדפן שומר את התגובה במטמון, נעשה שימוש בגרסה שנשמרה במטמון עד שהיא לא עדכנית כפי שנקבע על ידי max-age או expires, או עד להסרה מהמטמון מסיבה אחרת – למשל, המשתמש מנקה את המטמון של הדפדפן. כתוצאה מכך, משתמשים שונים עשויים להשתמש בגרסאות שונות של הקובץ בזמן יצירת הדף: משתמשים שאחזרו את המשאב משתמשים בגרסה החדשה, בעוד שמשתמשים ששמרו במטמון עותק קודם (אבל עדיין תקף) משתמשים בגרסה ישנה יותר של התגובה. איך אפשר להפיק את המקסימום משני העולמות: שמירה במטמון בצד הלקוח ועדכונים מהירים? עליך לשנות את כתובת ה-URL של המשאב ולאלץ את המשתמש להוריד את התגובה החדשה בכל פעם שהתוכן שלו משתנה. בדרך כלל ניתן לעשות זאת על ידי הטמעה של טביעת אצבע של הקובץ או של מספר גרסה בשם הקובץ שלו – לדוגמה, style.x234dff.css.

כשאתם מגיבים לבקשות לכתובות URL שמכילות טביעת אצבע או מידע על גרסאות, והתוכן שלהן אף פעם לא אמור להשתנות, צריך להוסיף את הערך Cache-Control: max-age=31536000 לתשובות.

הגדרת הערך הזה מורה לדפדפן שכאשר הוא צריך לטעון את אותה כתובת URL במהלך השנה הבאה (31,536,000 שניות; הערך הנתמך המקסימלי), הוא יוכל להשתמש באופן מיידי בערך במטמון HTTP, ללא צורך בשליחת בקשת רשת לשרת האינטרנט. זה נהדר – בזכות ההימנעות מחיבור לרשת, קיבלתם מיד את האמינות והמהירות שצברתם.

כלים לפיתוח כמו Webpack יכולים לבצע אוטומציה של התהליך של הקצאת טביעות אצבע דיגיטליות (hash) לכתובות ה-URL של הנכסים.

אימות מחדש של השרת עבור כתובות URL ללא גרסה

לצערנו, לא כל כתובות ה-URL שאתם טוענים הן גרסאות. אולי אין לכם אפשרות לכלול שלב build לפני פריסת אפליקציית האינטרנט, ולכן אתם לא יכולים להוסיף גיבובים לכתובות ה-URL של הנכסים. וכל אפליקציית אינטרנט צריכה קובצי HTML – הקבצים האלה (כמעט!) אף פעם לא יכללו מידע על גרסאות, כי אף אחד אחר לא ישתמש באפליקציית האינטרנט שלכם אם צריך לזכור שכתובת ה-URL לביקור היא https://example.com/index.34def12.html. אז מה אפשר לעשות לגבי כתובות ה-URL האלה?

זהו תרחיש אחד שבו אתם צריכים להודות בתפילה. שמירת HTTP במטמון בלבד לא חזקה מספיק כדי להימנע לגמרי מהרשת. (אל דאגה – בקרוב תלמדו על service worker, שיספק את התמיכה שאנחנו צריכים כדי להניע את הקרב שוב לטובתכם). עם זאת, יש כמה פעולות שאפשר לבצע כדי להבטיח שבקשות ברשת יהיו מהירות ויעילות ככל האפשר.

הערכים הבאים של Cache-Control יכולים לעזור לכם לכוונן את המיקום במטמון ואת האופן שבו כתובות URL ללא גרסה יישמרו במטמון:

  • no-cache – זו הוראה לדפדפן שצריך לאמת מחדש מול השרת בכל פעם לפני שמשתמשים בגרסת המטמון של כתובת ה-URL.
  • no-store. המדיניות הזו מורה לדפדפן ולמטמוני ביניים אחרים (כמו CDNs) לא לאחסן אף פעם גרסה של הקובץ.
  • private. דפדפנים יכולים לשמור את הקובץ במטמון, אבל מטמוני ביניים לא יכולים.
  • public. ניתן לשמור את התגובה בכל מטמון.

כדאי לעיין בנספח: תרשים זרימה של Cache-Control כדי להמחיש את תהליך ההחלטה באילו ערכים של Cache-Control להשתמש. שימו לב גם ש-Cache-Control יכול לקבל רשימה של הנחיות שמופרדות בפסיקים. פרטים נוספים זמינים בנספח: Cache-Control דוגמאות.

בנוסף, הגדרה של אחת משתי כותרות תגובה נוספות יכולה גם לעזור: ETag או Last-Modified. כפי שצוין בכותרות התגובות, גם ל-ETag וגם ל-Last-Modified יש מטרה זהה: לקבוע אם הדפדפן צריך להוריד מחדש קובץ שמור במטמון שתוקפו פג. הגישה המומלצת היא ETag כי היא מדויקת יותר.

דוגמה ל-ETag

נניח שחלפו 120 שניות מאז האחזור הראשוני והדפדפן שלח בקשה חדשה לאותו משאב. ראשית, הדפדפן בודק את מטמון ה-HTTP ומוצא את התגובה הקודמת. לצערנו, הדפדפן לא יכול להשתמש בתשובה הקודמת כי תוקף התגובה פג. בשלב הזה, הדפדפן יכול לשלוח בקשה חדשה ולאחזר את התגובה המלאה החדשה. עם זאת, הפעולה הזו לא יעילה כי אם המשאב לא השתנה, אין סיבה להוריד את אותו המידע שכבר נמצא במטמון! זו הבעיה שאסימוני האימות, כפי שצוין בכותרת ETag, נועדו לפתור. השרת יוצר ומחזיר אסימון שרירותי, שהוא בדרך כלל גיבוב (hash) או טביעת אצבע אחרת של תוכן הקובץ. הדפדפן לא צריך לדעת איך טביעת האצבע נוצרת. הוא צריך לשלוח אותה לשרת רק בבקשה הבאה. אם טביעת האצבע עדיין זהה, המשאב לא השתנה והדפדפן יכול לדלג על ההורדה.

הגדרה של ETag או Last-Modified תשפר מאוד את היעילות של בקשת האימות מחדש. בסוף הן יקפיצו את כותרות הבקשות If-Modified-Since או If-None-Match שצוינו ב-כותרות של בקשות.

כששרת אינטרנט שמוגדר כראוי רואה את הכותרות של הבקשות הנכנסות, הוא יכול לאשר אם גרסת המשאב שכבר יש לדפדפן במטמון ה-HTTP תואמת לגרסה האחרונה בשרת האינטרנט. אם יש התאמה, השרת יכול להגיב בתגובת HTTP של 304 Not Modified, שזהה כמו "היי, תמשיכו להשתמש במה שכבר יש לכם!" שולחים מעט מאוד נתונים כששולחים תשובה מהסוג הזה, כך שבדרך כלל זה הרבה יותר מהיר מאשר שליחה חוזרת של עותק של המשאב המבוקש בפועל.

דיאגרמה של לקוח שמבקש משאב והשרת שמגיב עם כותרת 304.
הדפדפן מבקש את /file מהשרת וכולל את הכותרת If-None-Match. הכותרת הזו מנחה את השרת להחזיר את הקובץ המלא רק אם ה-ETag של הקובץ בשרת לא תואם לערך If-None-Match של הדפדפן. במקרה הזה, שני הערכים תואמים, ולכן השרת מחזיר תגובה 304 Not Modified עם הוראות לגבי משך הזמן לשמירת הקובץ במטמון (Cache-Control: max-age=120).

סיכום

מטמון ה-HTTP הוא דרך יעילה לשפר את ביצועי העומס, כי הוא מפחית בקשות רשת מיותרות. יש תמיכה בכל הדפדפנים ולא נדרשת יותר מדי עבודה כדי להגדיר אותה.

ההגדרות הבאות של Cache-Control הן התחלה טובה:

  • Cache-Control: no-cache למשאבים שצריך לאמת מחדש מול השרת לפני כל שימוש.
  • Cache-Control: no-store למשאבים שאף פעם לא אמורים להישמר במטמון.
  • Cache-Control: max-age=31536000 למשאבים עם גרסאות.

בנוסף, הכותרות ETag או Last-Modified יכולות לעזור באימות מחדש של משאבי מטמון שתוקפם פג, ביעילות רבה יותר.

מידע נוסף

אם אתם מחפשים מידע מעבר לעקרונות הבסיסיים של השימוש בכותרת Cache-Control, כדאי לעיין במדריך של ג'ייק ארצ'יבלד שיטות מומלצות לשמירה במטמון וגיל מקסימלי של ג'ייק ארצ'יבלד.

ראו את המאמר אוהבים את המטמון כדי לקבל הנחיות לאופטימיזציה של השימוש במטמון למבקרים חוזרים.

נספח: טיפים נוספים

אם יש לך עוד זמן, הנה דרכים נוספות שבהן תוכל לבצע אופטימיזציה של השימוש במטמון ה-HTTP:

  • חשוב להשתמש בכתובות URL עקביות. אם מציגים את אותו תוכן בכתובות URL שונות, התוכן יאוחזר ויישמר כמה פעמים.
  • צמצמו את הנטישה. אם חלק ממשאב (כמו קובץ CSS) מתעדכן לעיתים קרובות, בעוד ששאר הקובץ לא מתעדכן (כמו קוד ספרייה), כדאי לפצל את הקוד שמעדכן בתדירות גבוהה לקובץ נפרד ולהשתמש באסטרטגיית שמירה במטמון למשך זמן קצר לקוד שמתעדכן לעיתים קרובות, ואסטרטגיה למשך שמירה ארוך במטמון של הקוד שלא משתנה לעיתים קרובות.
  • כדאי לעיין בהנחיה החדשה stale-while-revalidate אם מידה מסוימת של חוסר פעילות מקובלת במדיניות Cache-Control.

נספח: תרשים זרימה Cache-Control

תרשים זרימה

נספח: Cache-Control דוגמאות

ערך של Cache-Control הסבר
max-age=86400 התגובה יכולה להישמר במטמון על ידי דפדפנים ומטמון ביניים למשך עד יום אחד (60 שניות x 60 דקות x 24 שעות).
private, max-age=600 התגובה יכולה להישמר במטמון על ידי הדפדפן (אבל לא במטמון הביניים) למשך עד 10 דקות (60 שניות x 10 דקות).
public, max-age=31536000 ניתן לשמור את התשובה בכל מטמון למשך שנה.
no-store אי אפשר לשמור את התגובה במטמון וצריך לאחזר אותה במלואה בכל בקשה.