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