צור חיבורי רשת בשלב מוקדם כדי לשפר את מהירות הדף הנתפסת

למידע נוסף על רמזים של המשאבים 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 של סקריפט עם שם הגרסה.
דוגמה לכתובת URL עם גרסה.

המקרה הנפוץ הנוסף הוא טעינת תמונות מ-CDN של תמונה, שבו הנתיב המדויק של תמונה תלוי בשאילתות מדיה או בבדיקות של תכונות זמן ריצה בדפדפן של המשתמש.

כתובת אתר של תמונה CDN עם הפרמטרים size=300x400 ו-quality=auto.
דוגמה לכתובת URL של תמונה מסוג CDN.

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

סטרימינג של מדיה

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

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

איך מטמיעים את 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 לכל השאר ולמדוד תמיד את ההשפעה בעולם האמיתי.