שמירת מטמון ושיפור ביצועים – PWA

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

זיהוי משאבים המצריכים שמירה למטמון

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

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

Cache Types
תיאור סוגי מטמון מאתר MDN

מטמון צד לקוח

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

HTTP caching

The fastest HTTP request is the one not made

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

הדפדפן יחשיב את הקבצים כ’טריים’ ולא ינסה להביא חדשים מהשרת ע”פ header בשם cache-control שנשלח ומתקבל מהשרת.
יש אפשרויות שונות לקבוע אסטרטגיית שמירת מטמון, בד”כ הבחירה באפשרות זו או אחרת תושפע מהפרטיות הנצרכת למסמך.

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

AppCache

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

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

זה הקובץ AppCache שלי בשם menifest.appcache:

ע”מ לחבר אותו לאתר יש צורך בהוספת attribute לתגית html כך:
<html lang="en" manifest="menifest.appcache">

יצרתי דף web ע”מ להדגים איך הAppCache עובד.
זו חלק מרשימת הקבצים שנטענים בדף:

טעינה ללא מטמון של AppCache

אפשר לראות שבטעינה הראשונה של הדף עם הmanifest הדפדפן שומר את כל המשאבים שצויינו:

עכשיו אני אעבור למצב offline ואטען את העמוד שוב:

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

כל זה יפה ונחמד, אך עדיין יש לנו חסרונות בגישה הזו, אין לנו הרבה גמישות- אנחנו כבולים בדיוק לסינטקס של הקובץ ואם נרצה לדוגמה לממש design של offline first, להגיש קודם מהמטמון ואח”כ לרענן בbackground את המשאב – אין לנו אפשרות כזו.
ולמעשה, AppCache הוא deprecated, המקומות שבהם כן מומלץ להשתמש בAppCache זה בדפדפנים שלא תומכים עדיין בCache API וב Service Workers

Cache API

הcache API מתבטא באובייקט בשם caches שמוחצן לאובייקט הגלובלי window.
נכון לעכשיו יש כבר תמיכה של כל הדפדפנים הגדולים לService Workers ולאובייקט Caches.

הService Worker מתנהג כפרוקסי בין האפליקציה לבין השרת ובשביל אפשרות גלישת offline הוא נעזר באובייקט caches.

אמשיך את הדוגמה עם הדף שלי, זה הקובץ של הService Worker שמבצע את ההכנסה של המשאבים למטמון:

אפשר לראות שאני שומר את המטמון על תגית מסויימת.
באופן כללי מטמון נשמר per origin כשהכוונה של origin זה הwindow.origin, לorigin זה נשמר ללא בחירה שלנו אך התגיות שנחלק יישמרו לתוך החלק מטמון של הorigin שלנו.

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

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

אביא דוגמה מהמסמכים של Google ליישום אפשרי:

המקום אחסון המקסימלי למטמון יכול לנוע בין 50MB ל 20GB כשהמקום אחסון מתחלק בין כל הפתרונות אחסון כמו הIndexedDB והLocalStorage ואפילו הAppCache. ניתן לקרוא על זה בהרחבה פה.

למעוניינים, ניתן למצוא את הדף דוגמה פה.

כתיבת תגובה

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