לרענן את הקאש – איך מוחקים קאש ולמה צריך לעשות את זה

לקוחות שמנהלים אתר שומעים הרבה פעמים את המתכנת שלהם אומר ״תרעננו קאש״ או ״תנקו את הקאש לפני הבדיקה״

מה זה בעצם אומר?

למה אנחנו צריכים לעשות את זה?

האם המתכנת הכל יכול שלנו לא יכול לעשות איזה קסם שלא נצטרך לרענן קאש כל הזמן?

מה עם המשתמשים של האתר? גם להם אני צריך להגיד לנקות קאש?

במאמר הזה נסביר מה הוא ה cache, למה זה טוב, למה זה רע, ומה אפשר לעשות איתו?

מה זה קאש (cache)?

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

ישנם כמה סוגים שונים של cache אבל ה 3 העיקריים שבהם:

צד לקוח – client side cache

צד שרת (נקרא גם אפליקציה) – server side cache או application cache

צד ענן – CDN cache או propagated cache

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

למרות שה cache הנפוץ ביותר הוא הצד לקוח, נתחיל דווקא בצד האפליקציה server side cache:

אתרי אינטרנט כבר מזמן לא נבנים ב HTML.

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

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

אבל איך זה עובד בפועל?

בפועל אנחנו המתכנתים כותבים היום תבניות עמוד, ובתוך תבניות העמוד יש איזורי תוכן שניגשים למסד הנתונים – database של האתר, ושולפים משם את התוכן עבור כל איזור בעמוד.

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

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

לא לקאש הזה התכוונתי

מה הבעיה עם השיטה הזאת?

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

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

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

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

אז מה זה server side cache?

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

קאש מהסוג הזה בדרך כלל ניתן לרענן מתוך מערכת הניהול של האתר.

אחד הפלאגינים הנפוצים ביותר הוא wp-rocket והתפריט ניקוי קאש שלו מופיע בסרגל הניהול

הבעיות העיקריות של cache מהסוג הזה הן חוסר עדכון.

יכולים להיווצר מצבים שבהם עדכנו את התוכן באתר, אבל המשתמשים עדיין רואים תוכן ישן ולא מעדכן מפני שהאפליקציה (מערכת האתר) עדיין זוכרת ב cache את גרסת התוכן הקודמת.

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

בעיה נפוצה נוספת של הקאש בצד שרת היא באתרי חנות ecommerce.

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

כאן נכנסים שני מושגים חדשים וקצת יותר טכניים:

Over cache

Under cache

שניהם קשורים להגדרות הזכרון קאש, ויכולים להפתר ע״י מתכנת.

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

מצד שני, רצוי מאוש שלא להגיע למצב של over cache כי לדוגמה עגלת הקניות, עמוד הצ׳קאאוט, ועמוד התודה שרכשתם – הם לא עמודים סטטיים.

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

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

למתכנת קשה לאתר תקלות כאלה מפני שהוא בד״כ עסבוק באתר כשהוא מחובר למערכת הניהול שלו.

תקלות של overcache ייראו רק במהלך ה QA – בדיקות קצה שנערכות לאחר סבב התחזוקה או הפתוח.

מה זה צד ענן – CDN cache או propagated cache?

בהמשך ישיר ל server side cache – בהרבה אתרים בינלאומיים תשתית האיחסון היא תשתית ענן שמטרתה לפרוש את האתר לאיזורים גיאוגרפיים רבים ככל שניתן.

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

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

גם כאן יש ממש את אותן הבעיות שקיימות ב server side cache, מפני ששוב אנחנו מדברים על גרסאות סטטיות של האתר, ואף יותר מכך – ייתכן מצב שבו גולשים מאיזורים גיאוגרפיים שונים יקבלו אתר שונה ברמת העדכון שלו מכיוון שהענן האירופאי התעדכן בשעה האחרונה, והענן האמריקאי עדיין לא.

במקרה הזה רענון ה CDN cache ידרוש כניסה למערכת הניהול של ה CDN וצורך ניקוי הקאש (purge cache).

הרבה מערכות ענן ופלאגינים של cache מאפשרים חיבור של שתי המערכות כדי לסנכרן את המידע בצורה נוחה וטובה יותר. למשל wp-rocket תומכת במספר רשתות CDN גדולות ומוכרות ביניהן cloudflare ו – rocketCDN.

רשתות CDN ענן אחרות השקיעו בפלאגינים שמטרתם לתת את הוראת הניקוי קאש ממערכת הניהול של האתר ולחסוך למנהל האתר את הצורך להכנס למערכת הניהול של הרשת לצורך פעולת ה purge cache.

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

קאש צד לקוח – client side cache

הוא בד״כ הקאש שאליו המתכנתים מתכוונים כשהם מבקשים מהלקוח או ממנהל האתר ״לרענן קאש״.

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

במקרה הזה הדפדפן לא שומר את התוכן עצמו, אבל עדיין יש דברים באתר שלא משתנים כאשר גולשים מעמוד לעמוד – למשל העיצוב של האתר – קובץ style.css נשאר זהה בעמודים שונים של האתר.

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

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

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

האם צריך להנחות את המשתמשים באתר לעשות ניקוי קאש?

לא.

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

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

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

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

בין הגולשים הללו נמצאים גם מנהלי האתר עצמם שגולשים באתר לעיתים קרובות מאוד. על מנת לשקף את עדכוני העיצוב יש צורך למחוק את זכרון המטמון בצד הגולש – client side. ואז המתכנת יגיד לכם ״תנקו קאש ותבדקו שוב״

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

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

עוד קצת על קאש והוראות איך לנקות אותו בקישור כאן