מבוא לטכנולוגיות שזמינות לכל אחד.
למה מהירות הטעינה של דפים חשובה?
רוב המשתמשים מדווחים באופן קבוע על טעינת דפים איטית כמקור עיקרי לתסכול (54% במחקר משתמשים שנערך על ידי Google). לכן, לא מפתיע שטעינה מהירה יותר של דפים מניבה תוצאות טובות יותר לעסק. אכן, אם המבקרים מתוסכלים עוד לפני שהם יוצרים אינטראקציה עם אתר, סביר להניח שהם לא יישארו מספיק זמן כדי להבין את הערך שלו. למעשה, מחקר נוסף של Google ב-254 אתרים של מסחר אלקטרוני, פיננסים ונסיעות הראה ששיעורי ההמרות באתרים שנטענים תוך שתי שניות או פחות גבוהים ב-15%.
האצת הזמן של Largest Contentful Paint (LCP)
כמו שאומר הפתגם, אי אפשר לשפר את מה שלא מודדים. אנחנו מאמינים שהמדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) הם קבוצה מוצקה של מדדים שמתמקדים במשתמשים, שנועדו לתעד היבטים בסיסיים של חוויית המשתמש באינטרנט. באופן ספציפי, המדד Largest Contentful Paint (LCP) מודד את ביצועי הטעינה של הדפים על ידי דיווח על הזמן שנדרש להצגת בלוק הטקסט או התמונה הגדול ביותר שהמשתמש רואה. כדי לספק חוויית משתמש טובה, זמן ה-LCP צריך להתרחש תוך 2.5 שניות מרגע ההתחלה של טעינת הדף (כלומר, סף ה-LCP של 'טוב').
נבחן מה תורם ל-LCP של דף אופייני.
כשמשתמש נכנס לדף, הדפדפן מבקש את ה-HTML מהשרת. השרת משיב עם ה-HTML, שמספק לדפדפן עוד רמזים לגבי מה לאחזר בשלב הבא, כולל CSS, JavaScript, גופנים ותמונות. כשהתשובות האלה חוזרות, הדפדפן צריך גם לבצע קצת עבודה כדי להעריך אותן, ובסופו של דבר להציב את הרכיבים בדף ולצייר אותם. אבל רוב הזמן מוקדש להמתנה עד שהחבילות האלה יגיעו מהמכשיר לשרת ואז חזרה למכשיר. למעשה, הנתונים שלנו (Chrome ל-Android, חציון) מראים שבדרך כלל, כ-40% מהזמן של זמן האחזור שגלוי למשתמשים מוקדש להמתנה של הדפדפן לקבלת הבייטים הראשון מהשרת.
הכוח של אחסון נתונים לפני האצווה
אם אפשר יהיה לאחזר מראש את כל הקבצים האלה – כלומר לאחזר אותם לפני שהמשתמש יבקר בדף – זה יעזור מאוד לשפר את המהירות, ויישארו רק כמה משימות לפני הצגת הדף: הערכה, חישוב הפריסה וצביעת הדף.
בהתאם לנתונים ששיתפנו קודם, אפשר גם פשוט לבצע אחסון מראש של המשאב הראשי ועדיין להשיג טעינה מהירה יותר של הדף. במקרה של אותו אתר, טכניקה מסוג זה זמינה בקלות באמצעות פרימיטיבים כמו rel=prefetch. עם זאת, בתרחישים חוצי-אתרים, העניין לא פשוט כל כך.
ניווטים בין אתרים
אמנם טעינת נתונים מראש קיימת כבר זמן מה, אבל כדאי להביא בחשבון שיקול נוסף כשמטענים מראש דפים מאתר אחד בזמן שהמשתמש נמצא באתר אחר.
נניח שאתר מפנה ינחה את הדפדפן לבצע אחסון מקדים של דף מאתר אחר. ברור שכאשר המשתמש ילחץ על הקישור לדף הזה שנשלף מראש, הוא ייהנה מחוויית משתמש טובה יותר עם טעינת דף מהירה הרבה יותר. עם זאת, מה יקרה אם המשתמש אף פעם לא ילחץ על הקישור הזה? הם לא מצפים שאתר מקושר ידע שהם התעניינו בנושא מסוים בזמן שהם חיפשו אותו באתר המפנה. עם זאת, מדובר בסכנה משמעותית כי בקשות האחסון המקדים יכילו את כתובת ה-IP של המשתמש ואת קובצי ה-cookie, אם יש כאלה, כמו כל בקשה רגילה אחרת.
פתרונות
כדי לאפשר אחסון מראש (prefetch) באתרים שונים בלי לפגוע בפרטיות, פיתחנו שני פתרונות ב-3 השנים האחרונות: שרת proxy לאחסון מראש פרטי ו-Signed Exchanges (SXG). בנוסף, הרצנו ניסוי בקנה מידה רחב כדי לאשר שטעינה מראש בכמה מקורות מספקת יתרונות מהותיים במהירות. באופן ספציפי, כשבדקנו מקרים שבהם Google הצליחה לבצע אחסון מראש בטוח של ה-HTML הראשי לצורך הניווט הבא של המשתמש, ראינו שהחלק של טעינת הדפים עם LCP 'טוב' עלה ב-14 נקודות אחוז!
שיקולים חשובים
Proxy של אחזור מוקדם פרטי ו-Signed Exchange פותרים את אותו תרחיש לדוגמה, אבל לכל טכנולוגיה יש יתרונות וחסרונות שונים. לכן, הבחירה הטובה ביותר תלויה בצרכים הספציפיים של האתר. כדי לעזור לכם להבין את הפשרות הכרוכות בכך, בקטעים הבאים מפורטים שני שיקולים מרכזיים להפעלת אחסון מקדים בכמה אתרים ולבחירה בין שתי הטכנולוגיות הזמינות. פרטים נוספים זמינים גם במאמרים המפורטים על כל טכנולוגיה.
מבקרים חוזרים
קל להפעיל אחסון מראש בכמה אתרים למשתמשים שנכנסים לאתר בפעם הראשונה. לגבי מבקרים חוזרים, זה תלוי ברמת ההתאמה האישית באתר. הסיבה לכך היא שבקשות של טעינה מראש בכמה אתרים לא יכולות לכלול קובצי cookie מטעמי פרטיות.
- למבקרים בפעם הראשונה, ההגבלה הזו לא יוצרת בעיה כי אין להם קובצי cookie מלכתחילה. לכן, אפשר להפעיל טעינה מראש בכמה אתרים למשתמשים האלה בלי לבצע שינויים באתר.
- אם אתם רוצים להפעיל אחסון מקדים בכמה אתרים למבקרים חוזרים, והאתר שלכם מותאם אישית על סמך קובצי cookie, תצטרכו לטעון באיטרציה (lazy load) את הרכיבים המותאמים אישית האלה אחרי שהמשתמש מנווט. הסיבה לכך היא שבמהלך הניווט, אין יותר צורך להגביל את השימוש בקובצי cookie כי המשתמש בחר מפורשות להיכנס לאתר שלכם. לכן, בזמן הניווט, לאתר יש גישה לקובצי ה-cookie שלו כרגיל. שיטות מומלצות לטעינה איטית
- אם אתם מקודדים כרגע את ההתאמה האישית ישירות ב-HTML, תוכלו להמשיך לעשות זאת כשקובצי cookie נמצאים, ולהשתמש בטעינה איטית (lazy-loading) כאסטרטגיית חלופית לדפים שאוחסנו מראש.
- אם האתר שלכם לא מותאם אישית על סמך קובצי cookie, או אם ההתאמה האישית לא קריטית, אתם יכולים להציג למבקרים חוזרים את אותו תוכן שאתם מציגים למבקרים בפעם הראשונה.
בשלב זה, שרת proxy לטעינה מראש פרטית מופעל רק למבקרים בפעם הראשונה (קישורים ללא קובצי cookie). אנחנו עובדים כל הזמן כדי להרחיב את הכיסוי למבקרים חוזרים (קישורים עם קובצי cookie). לעומת זאת, Signed Exchange כבר תומך בטעינה מראש בכמה אתרים גם למבקרים בפעם הראשונה וגם למבקרים חוזרים (באמצעות הגישות שמפורטות למעלה).
הצגת נתונים נוספים מ-prefetch
הפעלת האחסון המקדים באתרים שונים עשויה לגרום להצגת נתונים נוספים. אכן, אם גורם מפנה מבצע אחסון מראש של הדף שלכם אבל המשתמש לא לוחץ על הקישור, המערכת תתייחס לכך כתנועה נוספת.
- כדי לצמצם את הבעיה הזו, אפשר לבקש מהגורם מפנה להיות פחות אגרסיבי עם בקשות ה-prefetch שלו. באופן דומה, הגורם המפנה או הדפדפן יכולים לצמצם את הבעיה הזו על ידי התמקדות במשאבים יחסית קלים, אבל קריטיים (לדוגמה, משאב ראשי, CSS קריטי או משאבי משנה של JavaScript). בעיקרון, מדובר בהתפשרות בין יתרונות המהירות לבין תנועה נוספת.
- לחלופין, אפשר לצמצם את נפח התנועה הזה על ידי בחירה באפשרות של אחסון נוסף במטמון (פרטים נוספים זמינים בקטע הזה בנושא Signed Exchange). החיסרון הוא ששמירת תוכן במטמון למשך זמן רב מדי עלולה לגרום להצגת מידע ישן יותר למשתמשים. בעצם, מדובר במאזן בין הצגת נתונים נוספים לבין עדכניות התוכן.
כדי לקבל את ההחלטה הטובה ביותר, כדאי לשאול את עצמכם איפה האתר שלכם נמצא בסולם המשופע בין עדכניות מקסימלית לבקשות נוספות מינימליות. התשובה לשאלה הזו תלויה בסופו של דבר בצרכים הספציפיים של העסק והמשתמשים שלכם.
תחילת העבודה
הטכנולוגיות האלה שולבו בחיפוש Google כדי שאתרים יוכלו להתחיל לשפר את ה-LCP שלהם באופן מיידי. אנחנו מקווים שהשינוי הזה יעודד גם גורמים פופולריים אחרים להפניה לבצע את הפעולה הזו, וכך לעזור להאיץ את האינטרנט באופן משמעותי בכל התחומים.
שתי הטכנולוגיות האלה פותרות את אותו תרחיש לדוגמה, אבל הן מציעות פשרות שונות לגבי השיקולים העיקריים שמפורטים למעלה. יכול להיות שתרצו להתחיל בטכנולוגיה אחת ולעבור לטכנולוגיה השנייה ככל שהצרכים שלכם או ההערכה שלכם להטבות יתפתחו. כדאי לעיין בסקירות המפורטות הבאות כדי להבין איזו טכנולוגיה הכי מתאימה למצב הספציפי שלכם: