שליפה מראש (prefetch) של משאבים כדי להאיץ את הניווטים בעתיד

מידע נוסף על רמז למשאב rel=prefetch ואיך להשתמש בו.

דמיאן רנזולי
דמיאן רנזולי
X GitHub תקלה
ג'רמי וגנר

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

במדריך הזה מוסבר איך לעשות את זה באמצעות <link rel=prefetch>, רמז למשאבים, שמאפשר להטמיע שליפה מראש (prefetch) בדרך קלה ויעילה.

משפרים את הניווטים בעזרת rel=prefetch

הוספה של <link rel=prefetch> לדף אינטרנט מנחה את הדפדפן להוריד דפים שלמים, או חלק מהמשאבים (כמו סקריפטים או קובצי CSS), שהמשתמש עשוי להזדקק להם בעתיד:

<link rel="prefetch" href="/articles/" as="document">

תרשים שמראה איך פועלת שליפה מראש (prefetch) של קישורים.

הרמז prefetch צורך בייטים נוספים למשאבים שאינם נחוצים באופן מיידי, ולכן יש להפעיל את הטכניקה הזו בקפידה, ולאחזר משאבים רק כאשר אתם בטוחים שהמשתמשים יזדקקו להם. מומלץ לא לבצע שליפה מראש (prefetch) של נתונים כשהמשתמשים מחוברים לחיבורים איטיים. אפשר לזהות את זה בעזרת Network Information API.

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

תרחישים לדוגמה

אחזור מראש של הדפים הבאים

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

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

שליפה מראש (prefetch) של משאבים צורכת רוחב פס נוסף, אבל היא יכולה לשפר את רוב מדדי הביצועים. זמן עד בייט ראשון (TTFB) יהיה בדרך כלל נמוך יותר, מפני שבקשת המסמך גורמת להיט של מטמון. מאחר שהמדד 'שיעור טריוויה' יהיה נמוך יותר, גם המדדים הבאים שמבוססים על זמן יהיו בדרך כלל נמוכים יותר, כולל המדדים המהירות שבה נטען רכיב התוכן הכי גדול (LCP) והצגת התוכן הראשוני (FCP).

שליפה מראש של נכסים סטטיים

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

לדוגמה, Netflix מנצלת את הזמן שמשתמשים מבלים בדפים לא מחוברים כדי לבצע שליפה מראש (prefetch) של React. המערכת תשתמש במידע הזה כשהמשתמשים יתחברו. לכן הם הפחיתו ב-30% את זמן השימוש ב'אינטראקטיבי' לניווטים עתידיים.

ההשפעה של השליפה מראש (prefetch) של נכסים סטטיים על מדדי הביצועים תלויה במשאב שמבוצע בשליפה מראש (prefetch):

  • שליפה מראש (prefetch) של תמונות יכולה לקצר משמעותית את זמני ה-LCP של רכיבי תמונות מסוג LCP.
  • שליפה מראש של גיליונות סגנונות יכולה לשפר את ה-FCP וגם את ה-LCP, מפני שזמן הרשת להורדת גיליון הסגנונות יתבטל. מאחר שגיליונות סגנון חוסמים עיבוד, הם עשויים להפחית את ה-LCP בשליפה מראש (prefetch). במקרים שבהם אלמנט ה-LCP בדף הבא הוא תמונת רקע של CSS שנשלחה בקשה דרך המאפיין background-image, התמונה תבוצע שליפה מראש (prefetch) גם כמשאב תלוי של גיליון הסגנונות שנשלף מראש.
  • שליפה מראש של JavaScript תאפשר עיבוד של סקריפט שנשלף מראש מוקדם הרבה יותר מאשר אם הרשת נדרשת לאחזר אותו קודם במהלך הניווט. יכולה להיות לכך השפעה על מדדי תגובה כמו השהיה לאחר קלט ראשון (FID) ואינטראקציה אל הצגת התמונה הבאה (INP). במקרים שבהם תגי העיצוב מעובדים בלקוח באמצעות JavaScript, ניתן לשפר את ה-LCP באמצעות עיכובים בטעינת משאבים, ועיבוד תגי עיצוב בצד הלקוח של תגי עיצוב שמכילים רכיב LCP של דף עשוי להתרחש מוקדם יותר.
  • שליפה מראש של גופני אינטרנט שלא נמצאים כבר בשימוש בדף הנוכחי יכולה למנוע שינויים בפריסה. במקרים שבהם נעשה שימוש ב-font-display: swap;, פרק הזמן להחלפת הגופן מתבטל, וכתוצאה מכך מתבצע עיבוד מהיר יותר של הטקסט וללא שינויים בפריסה. אם בדף עתידי נעשה שימוש בגופן שנשלף מראש, ורכיב ה-LCP של הדף הוא בלוק של טקסט שמשתמש בגופן אינטרנט, גם ה-LCP של הרכיב הזה יפעל מהר יותר.

שליפה מראש (prefetch) של מקטעי JavaScript לפי דרישה

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

לדוגמה, אם יש לכם דף שמכיל לחצן שפותח תיבת דו-שיח עם בוחר אמוג'י, תוכלו לחלק אותו לשלוש קטעי JavaScript – דף הבית, תיבת דו-שיח ובורר. אפשר לטעון בהתחלה את דף הבית ותיבת הדו-שיח, ואילו הבורר יכול להיטען על פי דרישה. כלים כמו Webpack מאפשרים להורות לדפדפן לשלוף מראש את המקטעים האלה לפי דרישה.

איך מטמיעים את rel=prefetch

הדרך הפשוטה ביותר להטמיע את prefetch היא להוסיף את התג <link> ל-<head> של המסמך:

<head>
  ...
  <link rel="prefetch" href="/articles/" as="document">
  ...
</head>

המאפיין as עוזר לדפדפן להגדיר את הכותרות הנכונות ולקבוע אם המשאב כבר קיים במטמון. ערכים לדוגמה של המאפיין הזה כוללים: document, script, style, font, image ואחרים.

ניתן להתחיל שליפה מראש (prefetch) גם דרך כותרת ה-HTTP Link:

Link: </css/style.css>; rel=prefetch

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

שליפה מראש של מודולי JavaScript עם תגובות קסם בחבילה של Webpack

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

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

form.addEventListener("submit", e => {
  e.preventDefault()
  import('lodash.sortby')
    .then(module => module.default)
    .then(sortInput())
    .catch(err => { alert(err) });
});

במקום להמתין עד שהאירוע 'שליחה' יתבצע כדי לטעון את הפונקציונליות הזו, אפשר לשלוף מראש את המשאב הזה כדי להגדיל את הסיכויים שהוא יהיה זמין במטמון עד שהמשתמש ישלח את הטופס. שימוש ב-Webpack מאפשר להשתמש בתגובות הקסם בתוך import():

form.addEventListener("submit", e => {
   e.preventDefault()
   import(/* webpackPrefetch: true */ 'lodash.sortby')
         .then(module => module.default)
         .then(sortInput())
         .catch(err => { alert(err) });
});

הקוד הזה מורה ל-webpack להחדיר את התג <link rel="prefetch"> למסמך ה-HTML:

<link rel="prefetch" as="script" href="1.bundle.js">

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

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

אפשר גם להטמיע אחזור מראש חכם יותר בספריות שבהן נעשה שימוש ב-prefetch מאחורי הקלעים:

  • ב-quicklink נעשה שימוש ב-Intersection Writeer API כדי לזהות מתי קישורים מגיעים לאזור התצוגה ולאחזר מראש משאבים מקושרים במהלך זמן 'לא פעיל'. בונוס: הקישור המהיר שוקל פחות מ-1KB!
  • ב-Guess.js נעשה שימוש בדוחות של ניתוח נתונים כדי ליצור מודל חיזוי שמשמש לשליפה מראש חכמה רק של מה שהמשתמש עשוי להזדקק לו.

גם הקישור המהיר וגם Guess.js משתמשים ב-Network Information API כדי למנוע שליפה מראש (prefetch) אם המשתמש נמצא ברשת איטית או הפעיל את Save-Data.

שליפה מראש (prefetch) לעומק

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

אפשר להשתמש בשליפה מראש (prefetch) כמה פעמים באותו הדף. הדפדפן מכניס את כל הרמזים לתור ומבקש כל משאב כשהוא לא פעיל. ב-Chrome, אם הטעינה מראש לא הסתיימה והמשתמש מנווט למשאב הייעודי לשליפה מראש, העומס במהלך ההפעלה יזוהה במהלך הניווט על ידי הדפדפן (יכול להיות שספקי דפדפנים אחרים מיישמים זאת באופן שונה).

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

קבצים שנשלפו מראש מאוחסנים במטמון HTTP או במטמון הזיכרון (בהתאם למשאב ניתן לשמירה או לא), למשך פרק זמן שמשתנה בהתאם לדפדפנים. לדוגמה, משאבים ב-Chrome נשמרים למשך חמש דקות, ולאחר מכן חלים כללי Cache-Control הרגילים של המשאב.

סיכום

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