Preload, preconnect ו-prefetch: רמזי טעינה ומתי הם עוזרים

Preload, preconnect, prefetch ו-dns-prefetch הם "רמזי טעינה" (resource hints): שורות קצרות ב-HTML שאומרות לדפדפן מה הוא יצטרך בקרוב, כדי שיתחיל להכין את זה מוקדם. preload מוריד מראש משאב שהעמוד הנוכחי צריך, preconnect פותח מראש חיבור לדומיין חיצוני, prefetch מוריד בעדיפות נמוכה משהו שיידרש בעמוד הבא, ו-dns-prefetch מבצע רק את שאילתת ה-DNS. כשמשתמשים בהם נכון, הם חוסכים עשרות עד מאות אלפיות שנייה. כשמשתמשים בהם בלי הבחנה, הם מתחרים על רוחב הפס ומאטים בדיוק את מה שהיה צריך להאיץ.

ההבדלים, בטבלה אחת

לפי המדריך של MDN לטעינה ספקולטיבית:

preload: למשאבים שהדפדפן מגלה מאוחר

הדפדפן קורא את ה-HTML ומוריד את מה שהוא מוצא. הבעיה היא משאבים שמוסתרים עמוק יותר: פונט שמוגדר בתוך קובץ CSS, תמונת רקע ב-CSS, או סקריפט שנטען על ידי סקריפט אחר. הדפדפן מגלה אותם רק אחרי שהוריד ופענח את הקובץ שמפנה אליהם. preload מקצר את השרשרת:

<link rel="preload" href="/fonts/heebo.woff2" as="font" type="font/woff2" crossorigin>

שני פרטים שחשוב לדייק בהם, לפי MDN: התכונה as חובה, והיא אומרת לדפדפן מה סוג המשאב; ולפונטים חובה crossorigin — גם כשהפונט באותו דומיין — כי פונטים נטענים במצב CORS אנונימי. בלי זה, הדפדפן יוריד את הפונט פעמיים.

באתר הזה, למשל, שני קבצי הפונט Heebo — עברית ולטינית — נטענים מראש בדיוק כך, כי הם מוגדרים ב-CSS והטקסט תלוי בהם. preload מתאים גם לתמונת LCP שמוגדרת כרקע ב-CSS; ראו שיפור LCP.

מתי preload מזיק

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

preconnect: לחיבורים לדומיינים חיצוניים

כל דומיין חדש דורש שאילתת DNS, חיבור והצפנה — עד שלושה סבבים ברשת לפני שהבייט הראשון יורד. לפי web.dev, preconnect יכול לחסוך 100 עד 500 אלפיות שנייה. אבל:

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

לדומיינים פחות קריטיים — כלי אנליטיקס, ווידג'טים — מספיק dns-prefetch, שלפי web.dev חוסך בדרך כלל 20–120 אלפיות שנייה. אגב, אם האתר טוען הרבה דומיינים חיצוניים, הצעד הראשון הוא לשאול אם כולם נחוצים — על כך במאמר סקריפטים חיצוניים.

fetchpriority: לא מתי, אלא כמה דחוף

preload עוזר לדפדפן לגלות משאב מוקדם, אבל לא משנה את העדיפות שלו. לפי web.dev, התכונה fetchpriority מאפשרת לסמן משאב כ-high או low, והיא עובדת על תמונות, סקריפטים ו-link. היא נתמכת בכרום ובאדג' מגרסה 102, בפיירפוקס 132 ובספארי 17.2. השימוש הנפוץ: עדיפות גבוהה לתמונה הראשית, ועדיפות נמוכה לתמונות שנטענות מוקדם אבל לא נראות.

prefetch ו-Speculation Rules: לעמוד הבא

prefetch מוריד משאב בעדיפות נמוכה לשימוש בניווט הבא, ושומר אותו במטמון. MDN מציין מגבלה חשובה: בגלל חלוקת המטמון בדפדפנים מודרניים, prefetch לא עובד בין אתרים שונים. לעמודים שלמים יש היום כלי חדש יותר — Speculation Rules — שמאפשר לטעון מראש או אפילו לרנדר מראש את העמוד הבא, כך שהמעבר אליו מיידי. ה-rel="prerender" הישן הוצא משימוש. רינדור מראש צורך משאבים, ולכן מתאים רק לעמודים שסביר מאוד שהגולש יפתח.

איך בודקים שזה עובד

במפל הטעינה של כלי המפתחים, או ב-GTmetrix ו-WebPageTest, משאב שנטען מראש מתחיל לרדת מוקדם — בדרך כלל מיד אחרי ה-HTML. אם preload לא שינה את מיקום המשאב במפל, או שהדפדפן מוריד אותו פעמיים, משהו בהגדרה שגוי (לרוב as או crossorigin). Lighthouse גם מתריע על חיבורים מוקדמים שלא נוצלו.

שאלות נפוצות

תוסף המטמון שלי מוסיף preload אוטומטית. זה טוב?

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

אפשר לשלוח רמזים בכותרות HTTP?

כן — preconnect ו-preload אפשר לשלוח גם בכותרת Link של תגובת השרת, כך שהדפדפן מקבל אותם עוד לפני שהתחיל לקרוא את ה-HTML.

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