משתמשים שטוענים את האתר שלך פעם נוספת ישתמשו במטמון ה-HTTP שלהם, לכן חשוב לוודא זה עובד טוב.
הפוסט הזה הוא נלווה לסרטון אהבתי את המטמון, חלק מהסרטון המורחב תוכן בוועידת המפתחים של Chrome לשנת 2020. חשוב לצפות בסרטון:
כשמשתמשים טוענים את האתר פעם נוספת, הדפדפן שלהם ישתמש במשאבים שנמצאים בתוך האתר את מטמון ה-HTTP שלו, כדי לזרז את הטעינה. אבל הסטנדרטים לשמירה במטמון האינטרנט, מאז שנת 1999, ומוגדרות להן באופן כללי למדי - יכול להיות שקובץ, כמו CSS או תמונה, יאוחזר שוב מהרשת לעומת הטעינה מהמטמון, מושג מדעי לא מדויק.
בפוסט הזה אדבר על ברירת מחדל הגיונית ומודרנית לשמירה במטמון – לא כולל שמירה במטמון. אבל זו רק ברירת המחדל, להיות ניואנסים יותר מאשר "כיבוי המצב". המשך לקרוא!
יעדים
כשאתר נטען בפעם השנייה, יש לכם שני יעדים:
- עליכם לוודא שהמשתמשים שלכם מקבלים את הגרסה העדכנית ביותר – אם שיניתם משהו, השינוי אמור לבוא לידי ביטוי במהירות
- מבצעים את הפעולה הראשונה כדי לאחזר כמה שפחות מהרשת
במובן הרחב ביותר, המטרה היא רק לשלוח את השינוי הקטן ביותר ללקוחות שלכם כשהם טוענים את האתר שוב. ובניית האתר שלכם כדי להבטיח מאתגר לבצע הפצה יעילה של כל שינוי (בהמשך מפורט מידע נוסף בנושא בסרטון).
למרות שאמרנו זאת, יש לכם גם לחצנים אחרים כשאתם שוקלים לשמור במטמון - אולי החלטתם לאפשר למטמון ה-HTTP של דפדפן המשתמש לשמור את האתר שלכם למשך זמן רב כך שלא יידרשו בקשות רשת כדי למלא בקשות. לחלופין, ויצרנו קובץ שירות (service worker) שימלא אתר לגמרי במצב אופליין לפני ולבדוק אם הוא עדכני. זוהי אפשרות קיצונית, תקפה — וניתן להשתמש בה בחוויות אינטרנט רבות ששמים דגש על אפליקציות אופליין, אבל לא צריך באופן קיצוני, ברמת מטמון בלבד, או אפילו ברמת רשת בלבד.
רקע
כמפתחי אתרים, כולנו רגילים לרעיון של "מטמון לא פעיל". אבל אנחנו יודעים, באופן כמעט אינסטימנטלי, שהכלים שזמינים לפתרון הבעיה: "לרענן", או לפתוח חלון פרטי, או להשתמש בשילוב כלשהו של הדפדפן שלך למפתחים לניקוי נתוני אתר.
למשתמשים רגילים באינטרנט אין את אותו יוקרה. אז בעוד שאנחנו יש לנו כמה יעדים עיקריים להבטיח שהמשתמשים שלנו יהנו מאוד חשוב גם לוודא שאין להם זמן גרוע או שתיתקלו. (צפו בסרטון אם תרצו לשמוע אותי איך האתר web.dev/live כמעט נתקע!)
בתור רקע, זו סיבה נפוצה מאוד ל"מטמון לא פעיל" הוא למעשה
ברירת המחדל של שמירה במטמון, שהוקמה ב-1999. היא מסתמכת על הכותרת Last-Modified:
כל קובץ שטוענים נשמר למשך 10% נוספים ממשך החיים הנוכחי שלו, כמו
שהדפדפן רואה אותו. לדוגמה, אם הקובץ index.html נוצר לפני חודש,
הוא יישמר במטמון של הדפדפן למשך כשלושה ימים נוספים.
זה היה רעיון ידוע מראש, אבל והאופי של האתרים של היום, התנהגות ברירת מחדל זו, להגיע למצב שבו למשתמש יש קבצים שמיועדים לגרסאות שונות של האתר שלך (למשל, ה-JS מהמהדורה של יום שלישי, וה-CSS של יום שישי ), והכל מפני שהקבצים האלה לא עודכנו בדיוק באותו הזמן.
נתיב מואר היטב
ברירת מחדל מודרנית לשמירה במטמון היא לא לאפשר כלל שמירה במטמון, רשתות CDN לכיווץ התוכן שלכם למשתמשים שלך. בכל פעם שמשתמש טוען את האתר, הוא מועבר לרשת כדי לראות אם הוא עדכני. לבקשה הזו יהיה זמן אחזור קצר, שמסופקים על ידי CDN קרוב גיאוגרפי לכל משתמש קצה.
אפשר להגדיר שמארח אתרי האינטרנט יגיב לבקשות אינטרנט באמצעות הכותרת הבאה:
Cache-Control: max-age=0,must-revalidate,public
זה בעצם אומר; הקובץ תקף ללא הגבלת זמן, ועליך לאמת מהרשת, לפני שאפשר יהיה להשתמש בו שוב (אחרת אפשר יהיה להשתמש רק 'הצעה').
תהליך האימות הזה זול יחסית מבחינת הבייטים שהועברו - אם לא השתנה קובץ תמונה גדול, הדפדפן שלכם יקבל שגיאת 304 קטנה תגובה, אבל זה עולה זמן אחזור כי המשתמש עדיין צריך לעבור לרשת כדי למצוא החוצה. וזה החיסרון העיקרי של הגישה הזו. זה יכול לעבוד ממש טוב לאנשים שמחוברים לחיבורים מהירים בעולם הראשון, ושבו יש רשת CDN שבחרת כיסוי מעולה, אבל לא לאנשים שמשתמשים בנייד לאט יותר או שימוש בתשתית ירודה.
לא משנה, זו גישה מודרנית הוא ברירת המחדל ברשת CDN פופולרית, Netlify, אבל ניתן להגדיר אותן כמעט בכל CDN. בשביל אירוח ב-Firebase אפשר לכלול הכותרת הזו בקטע האירוח של קובץ firebase.json:
"headers": [
// Be sure to put this last, to not override other headers
{
"source": "**",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=0,must-revalidate,public"
}
}
]
אז למרות שאני עדיין מציע את האפשרות הזו כברירת מחדל הגיונית, זה רק זה – ברירת המחדל! המשך לקרוא כדי ללמוד כיצד להיכנס ולשדרג את ברירות המחדל.
כתובות URL בטביעת אצבע
על ידי הכללת גיבוב (hash) של תוכן הקובץ בשם הנכסים, התמונות וכן הלאה
מוצג באתר שלכם, תוכלו לוודא שהקבצים האלה תמיד יהיו ייחודיים
content - התוצאה תהיה קבצים בשם sitecode.af12de.js, לדוגמה. מתי
השרת שלכם מגיב לבקשות לקבצים האלה, אתם יכולים להנחות את
לדפדפנים של משתמשי קצה לשמור אותם במטמון למשך זמן רב על ידי הגדרתם באמצעות
כותרת:
Cache-Control: max-age=31536000,immutable
הערך הזה הוא שנה, בשניות. לפי המפרט, זו פעולה שווה ל-'לתמיד'.
חשוב לא ליצור את הגיבובים האלה ידנית – זו יותר מדי עבודה ידנית! שלך יכולים להשתמש בכלים כמו Webpack, rollup וכן הלאה כדי לעזור לכם בכך. חשוב לקרוא מידע נוסף עליהם בדוח הכלי.
חשוב לזכור שלא רק JavaScript יכול להפיק תועלת מכתובות URL שנעשה בהן שימוש בטביעת אצבע. אפשר גם לתת לנכסים כמו סמלים, CSS וקובצי נתונים אחרים שאינם ניתנים לשינוי בדרך הזו. (אל תשכחו לצפות בסרטון שלמעלה כדי לקבל מידע נוסף על כתיבת קוד) פיצול, כך שתוכלו לשלוח פחות קוד בכל פעם שהאתר שלכם משתנה).
בלי קשר לאופן שבו האתר שלכם ניגש לשמירה במטמון, סוגי טביעות האצבע האלה חשובים מאוד לכל אתר שאתם יוצרים. רוב האתרים פשוט לא משתנים בכל גרסה.
כמובן שלא ניתן לשנות את השם של דפים 'הידידותיים' שמיועדים למשתמשים באופן כזה:
את קובץ index.html אל index.abcd12.html – זה לא אפשרי,
משתמשים לעבור לכתובת אתר חדשה בכל פעם שהם טוענים את האתר שלך! ההצעות האלה 'ידידותיות' כתובות URL
כך שאי אפשר לשנות את השם שלו ולשמור אותו במטמון, וזה מוביל אותי
בקרקע.
המקום האמצעי
ברור שיש מקום לאמצע כדי לשמור במטמון. אחרי הציגו שתי אפשרויות קיצוניות; מטמון אף פעם, או שמירה במטמון לתמיד. ויהיו להיות כמה קבצים שאולי תרצו לשמור במטמון לזמן מה, למשל "ידידותי" כתובות ה-URL שציינתי למעלה.
אם רוצים לשמור במטמון את מילות המפתח האלה ואת כתובות ה-URL וה-HTML שלהן, בהתחשב ביחסי התלות שהם כוללים, איך הם עשויים להישמר במטמון ואיך שמירה של כתובות ה-URL שלהן במטמון לזמן מה יכולה להשפיע עליך. בואו נסתכל על דף HTML כוללת תמונה כזו:
<img src="/images/foo.jpeg" loading="lazy" />
אם מעדכנים או משנים את האתר על ידי מחיקה או שינוי של הטעינה הדרגתית
תמונה, משתמשים שצופים בגרסה שנשמרה במטמון של ה-HTML עלולים לקבל שגיאת
חסרה תמונה - כי היא עדיין נשמרה במטמון של /images/foo.jpeg המקורי
הם מבקרים שוב באתר.
אם זהירות, יכול להיות שזה לא ישפיע עליך. אבל באופן כללי חשוב זכרו שהאתר שלכם - כשהוא נשמר במטמון על ידי משתמשי הקצה - כבר לא קיים השרתים שלך. במקום זאת, הוא עשוי להימצא בחלקים בתוך המטמון של בדפדפנים אחרים.
באופן כללי, רוב המדריכים בעולם שמירה במטמון ידברו על הסוג הזה הגדרה - האם ברצונך לשמור במטמון למשך שעה, מספר שעות וכן הלאה. כדי להגדיר את האפשרות הזו סוג של מטמון, להשתמש בכותרת כמו זו (שנשמרת במטמון למשך 3600 שניות, שעה):
Cache-Control: max-age=3600,immutable,public
עוד נקודה אחת. אם אתם יוצרים תוכן עדכני, שבדרך כלל יכול להיות משתמשים ניגשו אליהם פעם אחת - כמו מאמרי חדשות! - לדעתי הם אף פעם לא אמורים שנשמר במטמון, ועליך להשתמש בברירת המחדל ההגיונית שלנו שלמעלה. אני חושב שלעיתים קרובות להעריך בסכום גבוה יותר את ערך השמירה במטמון לעומת הרצון של המשתמש לראות תמיד את הנתונים העדכניים ביותר והתוכן החשוב ביותר, כמו עדכון ביקורתי על סיפור חדשותי או עכשווי אירוע.
אפשרויות שאינן HTML
מלבד HTML, כמה אפשרויות אחרות לקבצים שנמצאים באמצע התהליך כוללים:
באופן כללי, כדאי לחפש נכסים שלא משפיעים על אחרים
- לדוגמה: לא כדאי להשתמש ב-CSS, כי הוא גורם לשינויים באופן שבו ה-HTML. מעובד
תמונות גדולות שנעשה בהן שימוש כחלק ממאמרים עדכניים
- המשתמשים כנראה לא מתכוונים לקרוא עוד מאמר אחד מאשר כמה פעמים, אז אל תשמרו תמונות או תמונות גיבורות לנצח אחסון פסולת
נכס שמייצג משהו בעצמו שיש לו משך חיים
- יכול להיות שנתוני JSON לגבי מזג האוויר יתפרסמו רק כל שעה, לכן אפשר לשמור את התוצאה הקודמת במטמון למשך שעה — היא לא תשתנה בחלון
- גרסאות build של פרויקט בקוד פתוח עשויות להיות מוגבלות לקצב שליחת בקשות, לכן כדאי לשמור במטמון קובץ האימג' של הסטטוס של הגרסה עד שהוא עשוי להשתנות
סיכום
כשמשתמשים טוענים את האתר שלך פעם נוספת, כבר הצבעת הביטחון שלהם — הם רוצים לחזור ולקבל יותר ממה שאתם מציעים. בשעה הזו הנקודה היא לא תמיד רק קיצור זמן הטעינה, ויש לך כמה אפשרויות שזמינות לך כדי לוודא שהדפדפן שלך עושה רק את העבודה הוא צריך לספק חוויה מהירה ועדכנית.
שמירה במטמון היא לא קונספט חדש באינטרנט, אבל אולי צריך ברירת מחדל – כדאי להשתמש באחת מהן ולהביע הסכמה לאסטרטגיות טובות יותר לשמירה במטמון כשתזדקקו להם. תודה על שקראת מידע זה!
ראה גם
למדריך כללי על מטמון HTTP, אפשר לעיין מניעה של בקשות רשת לא נחוצות באמצעות מטמון ה-HTTP.