הדפדפן שלכם חכם יותר ממה שרוב האנשים חושבים. הוא יכול להתחיל להביא משאבים עוד לפני שהוא בכלל זקוק להם, אם רק תגידו לו. זה בדיוק הרעיון מאחורי רמזי משאבים כמו preload, prefetch, preconnect ו-dns-prefetch. אלו תגיות HTML קטנות שנותנות לדפדפן התראה מוקדמת על מה שעומד לקרות, וכשמשתמשים בהן נכון, הן יכולות לחתוך מאות מילישניות מזמן הטעינה שלכם כחלק ממאמצי שיפור זמן טעינת דף, בלי לגעת כמעט בשרת או בקוד.
בואו נפרק מה כל רמז עושה בפועל, מתי להשתמש בו, ואיפה אנשים בדרך כלל טועים.
מה רמזי משאבים באמת עושים
דפדפנים בדרך כלל מגלים משאבים תוך כדי קריאת ה-HTML שלכם, שורה אחר שורה. גיליון סגנונות שמקושר קרוב לתחתית תגית ה-head מתבקש מאוחר יותר מאחד שנמצא קרוב לראש. גופן שמוזכר בתוך קובץ CSS לא מתבקש עד שהדפדפן כבר הוריד וקרא את אותו CSS. אפקט המפל הזה מצטבר.
רמזי משאבים מאפשרים לכם לדלג בתור. אתם למעשה אומרים לדפדפן: "היי, אתה הולך להזדקק לזה בקרוב, תתחיל עכשיו במקום לחכות לגלות את זה בדרך הטבעית."
Preload: למשאבים שאתם יודעים שאתם צריכים ממש עכשיו
<link rel="preload"> אומר לדפדפן להביא משאב מיד, בעדיפות גבוהה, כי הוא יידרש לדף הנוכחי. זה הכלי הנכון עבור:
- תמונת ה-LCP (Largest Contentful Paint) הגדולה שלכם, כמו באנר ראשי
- גופנים קריטיים שבלעדיהם יהיה הבזק של טקסט בלתי נראה
- קובץ CSS או JS מרכזי שבדרך כלל מתגלה מאוחר
הנה דוגמה טיפוסית לתמונת hero:
<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">ועבור גופן:
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter.woff2" crossorigin>בבדיקות, preload של תמונת LCP הוריד את ציוני ה-LCP ב-300-600 מילישניות באתרים שבהם התמונה נתגלתה בעבר דרך כלל CSS מסוג background-image. זה שינוי משמעותי כאשר הסף של גוגל ל-LCP "טוב" הוא 2.5 שניות.
הבעיה: preload הוא הבטחה. אם אתם עושים preload למשהו ולא באמת משתמשים בו בדף, Chrome יזרוק אזהרה בקונסול ותבזבזו רוחב פס לשווא. בצעו preload רק למה שאתם בטוחים שהדף צריך.
Prefetch: למשאבים שתזדקקו להם בקרוב, רק לא עכשיו
<link rel="prefetch"> עובד אחרת. הוא אומר לדפדפן להביא משאב בעדיפות נמוכה בזמן פנוי, כי סביר שהוא יידרש לניווט עתידי, לא לדף הנוכחי.
זה הרמז שמאחורי התחושה ה"מיידית" שמקבלים באתרים כמו תוצאות חיפוש של גוגל או חנויות אונליין בנויות היטב. כשמשתמש מרחף עם העכבר מעל קישור, או כשדף מסיים להיטען והדפדפן יש לו קיבולת פנויה, אפשר לעשות prefetch לדף הבא הסביר:
<link rel="prefetch" href="/checkout">כמה פריימוורקים, כמו Next.js, עושים את זה אוטומטית לכל קישור שנראה בתצוגה. אם אתם בונים את זה ידנית, דפוס נפוץ הוא לבצע prefetch בזמן ריחוף עם השהיה קצרה (סביב 65 מילישניות) כדי להימנע מבזבוז בקשות על ריחופים בטעות.
ביצוע prefetch לדף הבא בתהליך רכישה, למשל, יכול לגרום למעבר להרגיש מיידי כי ה-HTML, CSS וה-JS כבר יושבים במטמון הדפדפן עד שהמשתמש לוחץ.
Preconnect ו-DNS-Prefetch: למקורות צד שלישי
אם הדף שלכם טוען משאבים מדומיינים אחרים (Google Fonts, CDN, סקריפט אנליטיקס, שער תשלומים), הדפדפן צריך לבצע חיפוש DNS, handshake של TCP, ומשא ומתן TLS לפני שהוא בכלל יכול להתחיל להוריד משהו מאותו דומיין. המסלול הזה בלבד יכול לעלות 100-300 מילישניות תלוי בחיבור של המשתמש.
preconnect מבצע את שלושת השלבים מראש:
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>dns-prefetch היא גרסה קלה יותר שרק פותרת DNS, שימושית כגיבוי לדפדפנים שלא תומכים ב-preconnect, או למקורות שלא בטוחים ב-100% שתשתמשו בהם:
<link rel="dns-prefetch" href="//www.googletagmanager.com">כלל אצבע טוב: בצעו preconnect למקורות שאתם יודעים שתטענו מהם משאבים כמעט מיד, ושמרו על הרשימה קצרה. כל preconnect פותח חיבור שצורך CPU וזיכרון, כך שביצוע preconnect לעשרה דומיינים שונים יכול דווקא לפגוע ולהאט דברים.
כמה רמזי משאבים זה יותר מדי
כאן הרבה מפתחים עם כוונות טובות טועים. רמזי משאבים אינם חינמיים. כל אחד מהם מתחרה על רוחב פס וחיבורים מול המשאבים שהדף שלכם באמת צריך עכשיו.
- הגבילו preconnect ל-3-4 מקורות צד שלישי קריטיים לכל היותר
- בצעו preload רק למשאבים שמופיעים מעל הקיפול ושהיו מתגלים מאוחר
- אל תעשו prefetch לכל קישור בדף, בחרו את 1-3 היעדים הבאים הכי סבירים
- בדקו עם פאנל הרשת של Chrome DevTools כדי לוודא שהרמז באמת משנה את תזמון הבקשות
ראינו אתרים שעשו preload לתריסר גופנים, כשחצי מהם אפילו לא היו בשימוש בהצגה הראשונה. התוצאה הייתה רינדור ראשוני איטי יותר, לא מהיר יותר, כי הדפדפן היה עסוק בהבאת דברים שהמשתמש עדיין לא צריך.
מדידת ההשפעה
אל תנחשו, מדדו. הריצו את הדף שלכם דרך Lighthouse או WebPageTest לפני ואחרי הוספת הרמזים, ועקבו אחרי המספרים הספציפיים האלה:
- Time to First Byte (TTFB) - לא מושפע מרמזי משאבים, אבל טוב כבסיס להשוואה
- Largest Contentful Paint (LCP) - אמור לרדת כשאתם עושים preload נכון למשאב ה-LCP
- Total Blocking Time (TBT) - שימו לב לנסיגות אם אתם עושים preload ליותר מדי JS
אם אתם לא בטוחים אילו מדדים הכי חשובים או איך לקרוא את הדוח, כלי ניתוח מהירות הדף שלנו מפרק את זה בלי לדרוש מכם לפענח גרפי מפל גולמיים.
איך זה מתחבר ל-WordPress
אם אתם מריצים WordPress, לא בהכרח צריך לכתוב את התגיות האלה ידנית. כלי שיפור ביצועים טוב מטפל ב-preload של LCP וגופנים כהגדרה שאפשר לקבוע, כך שתוכלו לסמן את תמונת ה-hero שלכם או את הגופנים המרכזיים בלי לערוך קבצי תבנית. זה בדיוק מה שבנינו בתוך לוח הבקרה שלנו לשיפור ביצועים, שבו לשונית Preload ו-LCP מאפשרת להגדיר את זה בכמה קליקים במקום לחפש בתבנית ה-header של הערכת העיצוב שלכם.
כיסינו את התמונה הרחבה יותר של מה שבאמת עוזר למהירות WordPress בשיפור מהירות WordPress: מדריך מעשי שבאמת עובד, ואם טעינת גופנים ספציפית הטרידה אתכם, איך אסטרטגיות טעינת גופנים מונעות הבזק של טקסט בלתי נראה שמאט אתכם צולל עמוק יותר לנושא הזה.
לסיכום
רמזי משאבים זולים להוספה וכשמשתמשים בהם בתבונה, הם באמת יעילים לשיפור זמן טעינת דף. בצעו preload למה שהדף הנוכחי צריך עכשיו. בצעו prefetch למה שהמשתמש כנראה ילחץ עליו הבא. בצעו preconnect לכמה מקורות צד שלישי שאי אפשר להימנע מהם. ותמיד מדדו לפני ואחרי, כי הקו בין "רמז מועיל" ל"בזבוז רוחב פס" דק יותר ממה שנראה.
התחילו עם תמונת ה-LCP שלכם והגופן הכי בשימוש. שני השינויים האלה לבדם בדרך כלל נותנים את השיפור הנראה לעין הגדול ביותר עבור הכי פחות מאמץ, כצעד חשוב בשיפור זמן טעינת דף. לצלילה עמוקה יותר באסטרטגיות מטמון קשורות שמגדילות את התועלות האלה, ראו הסקירה שלנו על מטמון בצד השרת.
