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

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

Demián Renzulli
Demián Renzulli
X GitHub תקלה
Jeremy Wagner

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

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

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

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

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

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

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

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

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

שליפה מראש של הדפים הבאים

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

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

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

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

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

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

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

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

שליפה מראש של מקטעי 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">

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

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

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

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

שליפה מראש (prefetch)

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

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

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

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

סיכום

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