למידע נוסף על רמזים של משאבים rel=preconnect ו- rel=dns-prefetch ואיך להשתמש בהם.
לפני שהדפדפן יכול לבקש משאב משרת, הוא צריך ליצור חיבור. יצירת חיבור מאובטח כוללת שלושה שלבים:
מחפשים את שם הדומיין ופותרים את הבעיה בכתובת IP.
מגדירים חיבור לשרת.
להצפין את החיבור מטעמי אבטחה.
בכל אחד מהשלבים האלה, הדפדפן שולח קטע נתונים לשרת והשרת שולח תגובה בחזרה. המסע הזה, מהמוצא ליעד ובחזרה, נקרא נסיעה הלוך ושוב.
בהתאם לתנאי הרשת, טיסה הלוך ושוב עשויה להימשך זמן רב. תהליך הגדרת החיבור עשוי לכלול עד שלוש נסיעות הלוך ושוב במקרים לא מותאמים.
טיפול מזמן מראש גורם לאפליקציות להרגיש הרבה יותר מהר. בפוסט הזה מוסבר איך להשיג זאת באמצעות שני רמזים של משאבים: <link rel=preconnect>
ו-<link rel=dns-prefetch>
.
יצירת קשרים מוקדמים עם rel=preconnect
דפדפנים מודרניים עושים כמיטב יכולתם כדי לחזות אילו חיבורים יידרשו לדף, אבל הם לא יכולים לחזות את כולם בצורה אמינה. החדשות הטובות הן שאתם יכולים לתת להם רמז (משאב 😉).
הוספה של rel=preconnect
אל <link>
מיידעת את הדפדפן על כך שהדף שלך מתכוון ליצור חיבור לדומיין אחר ושברצונך שהתהליך יתחיל בהקדם האפשרי. משאבים ייטענו מהר יותר כי תהליך ההגדרה כבר יושלם עד שהדפדפן יבקש אותם.
השם של הרמזים למשאבים הוא לא חובה. הם מספקים את המידע על מה שרוצים שיקרה, אבל בסופו של דבר, הדפדפן הוא זה שיחליט אם להפעיל אותם. ההגדרה והשמירה של חיבור פתוח דורשות עבודה רבה, לכן הדפדפן עשוי להתעלם מרמזים של משאבים או לבצע אותם באופן חלקי בהתאם לסיטואציה.
עדכון הדפדפן לגבי הכוונה שלכם צריך להיות פשוט להוסיף תג <link>
לדף:
<link rel="preconnect" href="https://example.com">
אפשר להאיץ את זמן הטעינה ב-100 עד 500 אלפיות השנייה על ידי יצירת חיבורים מוקדמים למקורות חשובים של צד שלישי. הנתונים האלה עשויים להיראות קטנים, אבל הם משפיעים על האופן שבו המשתמשים תופסים את הביצועים של דפי האינטרנט.
תרחישים לדוגמה של rel=preconnect
לדעת מאיפה, אבל לא מה אתם שולפים
בגלל יחסי תלות בין גרסאות, לפעמים מגיעים למצב שבו אפשר לדעת שתבקשו משאב מ-CDN מסוים, אבל לא את הנתיב המדויק בשבילו.
![כתובת URL של סקריפט עם שם הגרסה.](https://web.dev/static/articles/preconnect-and-dns-prefetch/image/a-url-a-script-the-vers-ba309041ca368.png?authuser=5&hl=he)
המקרה הנפוץ השני הוא טעינת תמונות מ-CDN של תמונות, שבו הנתיב המדויק של תמונה תלוי בשאילתות מדיה או בבדיקות של תכונות זמן ריצה בדפדפן של המשתמש.
![כתובת URL של תמונה מסוג CDN עבור הפרמטרים size=300x400 ו-quality=auto.](https://web.dev/static/articles/preconnect-and-dns-prefetch/image/an-image-cdn-url-the-par-a5f41bc0b8107.png?authuser=5&hl=he)
במצבים אלה, אם המשאב שתאחזר חשוב, כדאי שתחסוך זמן רב ככל האפשר על ידי התחברות מראש לשרת. הדפדפן לא יוריד את הקובץ לפני שהדף יבקש אותו, אבל הוא יכול לטפל מראש בהיבטים של החיבור, וכך לחסוך מהמשתמש את הצורך להמתין למספר נסיעות הלוך ושוב.
מדיה בסטרימינג
דוגמה נוספת שבה יכול להיות שתרצו לחסוך זמן בשלב החיבור, אבל לא בהכרח להתחיל לאחזר תוכן באופן מיידי, היא כאשר סטרימינג של מדיה מגיע ממקור אחר.
בהתאם לאופן שבו הדף יטפל בתוכן הסטרימינג, מומלץ להמתין עד שהסקריפטים ייטענו ויהיו מוכנים לעיבוד הסטרימינג. חיבור מראש עוזר לקצר את זמן ההמתנה לנסיעה הלוך ושוב כשיתאים לך להתחיל לשלוף.
איך מטמיעים את rel=preconnect
אחת הדרכים להתחיל preconnect
היא להוסיף תג <link>
ל-<head>
של המסמך.
<head>
<link rel="preconnect" href="https://example.com">
</head>
קישור מראש יעיל רק לדומיינים שאינם דומיין המקור, ולכן לא מומלץ להשתמש בו באתר שלכם.
אפשר גם ליזום חיבור מראש באמצעות כותרת ה-HTTP Link
:
Link: <https://example.com/>; rel=preconnect
סוגי משאבים מסוימים, כמו גופנים, נטענים במצב אנונימי. עבור אלמנטים כאלה, צריך להגדיר את המאפיין crossorigin
עם הרמז preconnect
:
<link rel="preconnect" href="https://example.com/ComicSans" crossorigin>
אם משמיטים את המאפיין crossorigin
, הדפדפן יבצע רק את חיפוש ה-DNS.
תיקון שם הדומיין בשלב מוקדם עם rel=dns-prefetch
אתרים זוכרים אתרים לפי השמות שלהם, אבל השרתים שומרים אותם לפי כתובות IP. לכן קיימת מערכת שמות הדומיינים (DNS). הדפדפן משתמש ב-DNS כדי להמיר את שם האתר לכתובת IP. התהליך הזה – רזולוציית שם הדומיין – הוא השלב הראשון ביצירת חיבור.
אם דף מסוים צריך ליצור חיבורים לדומיינים רבים של צד שלישי, קישור מראש של כולם לא יהיה יעיל. הרמז preconnect
מתאים במיוחד לחיבורים הכי קריטיים. בכל השאר, משתמשים ב-<link rel=dns-prefetch>
כדי לחסוך זמן בשלב הראשון – חיפוש ה-DNS, שבדרך כלל נמשך 20-120 אלפיות השנייה.
רזולוציית ה-DNS מופעלת באופן דומה ל-preconnect
: על ידי הוספה של תג <link>
ל-<head>
של המסמך.
<link rel="dns-prefetch" href="http://example.com">
התמיכה בדפדפן dns-prefetch
שונה מעט מהתמיכה preconnect
, כך ש-dns-prefetch
יכול לשמש כחלופה לדפדפנים שלא תומכים ב-preconnect
.
<link rel="preconnect" href="http://example.com"> <link rel="dns-prefetch" href="http://example.com">כדי להטמיע באופן בטוח את שיטת הגיבוי, צריך להשתמש בתגי קישור נפרדים.
<link rel="preconnect dns-prefetch" href="http://example.com">הטמעת החלופה של
dns-prefetch
באותו תג <link>
גורמת לבאג ב-Safari שבו preconnect
מתבטל.
ההשפעה על Largest Contentful Paint (LCP)
באמצעות dns-prefetch
ו-preconnect
, אתרים יכולים לקצר את משך הזמן שנדרש כדי להתחבר למקור אחר. המטרה האולטימטיבית היא לצמצם ככל האפשר את הזמן לטעינת משאב ממקור אחר.
כשיש חששות לגבי המהירות שבה נטען רכיב התוכן הכי גדול (LCP), עדיף שהמשאבים יהיו גלויים באופן מיידי, כי מועמדי LCP הם חלקים חיוניים בחוויית המשתמש. ערך fetchpriority
של "high"
במשאבי LCP יכול לשפר את המצב הזה כי הוא מרמז על החשיבות של הנכס הזה לדפדפן, כדי שאפשר יהיה לאחזר אותו בשלב מוקדם.
במקרים שבהם אי אפשר להגדיר נכסי LCP שגלויים באופן מיידי, קישור preload
– גם עם הערך fetchpriority
של "high"
– עדיין מאפשר לדפדפן לטעון את המשאב בהקדם האפשרי.
אם אף אחת מהאפשרויות האלה לא זמינה – כי המשאב המדויק לא יהיה ידוע עד מאוחר יותר בטעינת הדף – אפשר להשתמש ב-preconnect
במשאבים ממקורות שונים כדי לצמצם ככל האפשר את ההשפעה של הגילוי מאוחר של המשאב.
בנוסף, preconnect
זול יותר מ-preload
מבחינת השימוש ברוחב הפס, אבל עדיין לא נטול סיכונים. כמו במקרה של כמות מוגזמת של רמזים של preload
, שימוש מוגזם ברמזים של preconnect
עדיין צורך רוחב פס במקרים של אישורי TLS. הקפידו לא להתחבר מראש למקורות רבים מדי, מכיוון שהדבר עלול לגרום להתנגשות בין רוחב פס.
סיכום
שני הרמזים האלה יעזרו לשפר את מהירות הדף אם ידוע לכם שבקרוב תתבצע הורדה של משהו מדומיין של צד שלישי, אבל לא תדעו מהי כתובת ה-URL המדויקת של המשאב. לדוגמה, רשתות CDN שמפיצות ספריות, תמונות או גופנים של JavaScript. חשוב לשים לב למגבלות – מומלץ להשתמש ב-preconnect
רק למשאבים החשובים ביותר, להסתמך על dns-prefetch
בכל השאר, ולמדוד תמיד את ההשפעה בעולם האמיתי.