שיקולים כלליים לגבי ביצועי HTML

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

הבקשה הראשונית ל-HTML עוברת מספר שלבים, וכל אחד מהם נמשך זמן מה. אם מקצרים את משך הזמן בכל שלב, Time to First Byte (TTFB) מהיר יותר. בכל הקשור למהירות הטעינה של דפים, TTFB הוא לא המדד היחיד שבו צריך להתמקד. עם זאת, ערך גבוה של TTFB מקשה על להגיע לערכי הסף ה'טובים' במדדים כמו Largest Contentful Paint (LCP) ו-First Contentful Paint (FCP).

צמצם הפניות מחדש

כשמבקשים משאב, השרת עשוי להגיב באמצעות הפניה אוטומטית, עם הפניה אוטומטית קבועה (תשובת 301 Moved Permanently) או באמצעות הפניה זמנית (תגובת 302 Found).

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

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

לרוב, מודעות, שירותי קיצור כתובות URL ושירותים אחרים של צד שלישי משתמשים בהפניות אוטומטיות ממקורות שונים. למרות שהפניות אוטומטיות ממקורות שונים לא בשליטתכם, עדיין כדאי לבדוק שאתם נמנעים מהפניות אוטומטיות מרובות, לדוגמה: במקרה שיש לכם מודעה שמקשרת לדף HTTP שמפנה לדף המקביל ב-HTTPS, או הפניה אוטומטית ממקורות שונים שמגיעה למקור שלכם, ואז מפעילה הפניה אוטומטית ממקור זהה.

מטמון תגובות HTML

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

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

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

גישה זהירה לשמירת HTML במטמון יכולה להיות שימוש בכותרות התגובות ETag או Last-Modified. כותרת ETag, שנקראת גם תג ישות, היא מזהה שמייצג באופן ייחודי את המשאב המבוקש, בדרך כלל באמצעות גיבוב של תוכן המשאב:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

בכל פעם שהמשאב משתנה, צריך ליצור ערך ETag חדש. בבקשות הבאות, הדפדפן שולח את הערך ETag דרך כותרת הבקשה If-None-Match. אם הערך ETag בשרת תואם לזה שנשלח על ידי הדפדפן, השרת מגיב עם התשובה 304 Not Modified והדפדפן משתמש במשאב מהמטמון. המצב הזה עדיין כרוך בזמן אחזור של הרשת, אבל התגובה של 304 Not Modified קטנה הרבה ממשאב HTML שלם.

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

מדידת זמני התגובה של השרת

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

אם המשתמשים נתקלים ב-TTDFB איטי בשדה, תוכלו לחשוף מידע על הזמן שבו המשתמש הוקדש בשרת באמצעות Server-Timing כותרת התגובה:

Server-Timing: auth;dur=55.5, db;dur=220

ערך של כותרת Server-Timing יכול לכלול כמה מדדים, וגם משך זמן לכל אחד מהם. לאחר מכן ניתן לאסוף את הנתונים האלה ממשתמשים בשדה באמצעות Navigation Timing API ולנתח אותם, כדי לראות אם יש עיכובים במשתמשים. בקטע הקוד הקודם, כותרת התגובה כוללת שני תזמונים:

• משך הזמן לאימות המשתמש (auth) נמשך 55.5 אלפיות השנייה.
• זמן הגישה למסד הנתונים (db), שנמשך 220 אלפיות השנייה.

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

דחיסה

יש לדחוס תגובות מבוססות טקסט, כמו HTML , JavaScript , CSS ו-SVG, כדי לצמצם את גודל ההעברה ברשת על מנת שאפשר יהיה להוריד אותן מהר יותר. האלגוריתמים הנפוצים ביותר לדחיסה הם gzip ו-Brotli. Brotli מניב שיפור של כ-15% עד 20% בהשוואה ל-gzip.

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

1. משתמשים ב-Brotli כשהדבר אפשרי. כפי שצוין קודם, Brotli מספק שיפור די משמעותי לעומת gzip, ו-Brotli נתמך בכל הדפדפנים העיקריים. השתמשו ב-Brotli כשאפשר, אבל אם מספר רב של משתמשים בדפדפנים מדור קודם משתמשים באתר שלכם, ודאו ש-gzip משמש כחלופה, כי כל דחיסה עדיפה על כל דחיסה.
2. לגודל הקובץ יש חשיבות. משאבים קטנים מאוד – פחות מ-1KiB – לא דחוסים כמו שצריך, ולפעמים לא נדחסים בכלל. היעילות של כל סוג של דחיסת נתונים תלויה בכמות גדולה של נתונים שאלגוריתם הדחיסה יכול לעבוד איתם כדי למצוא יותר ביטים של נתונים שאפשר לדחוס. ככל שהקובץ גדול יותר, כך הדחיסה טובה יותר – אבל לא כדאי לשלוח משאבים גדולים במיוחד כי אפשר לדחוס אותם בצורה יעילה יותר. במשאבים גדולים כמו JavaScript ו-CSS, למשל, נדרש הרבה יותר זמן לניתוח ולהערכה אחרי שהדפדפן פורץ אותם, והם עשויים להשתנות בתדירות גבוהה יותר גם אם הם השתנו באופן שולי, כי שינויים כלשהם גורמים לגיבוב של קבצים אחר.
3. הסבר על דחיסה דינמית לעומת דחיסה סטטית דחיסה דינמית וסטטית הן גישות שונות לגבי המצבים שבהם צריך לדחוס משאב. כשמשתמשים בדחיסה דינמית, המערכת דוחסת את המשאב בזמן שליחת הבקשה, ולפעמים בכל פעם שמתקבלת בקשה. מצד שני, דחיסה סטטית דוחסת קבצים לפני זמן מה, כך שאין צורך לבצע דחיסה בזמן הבקשה. דחיסה סטטית מסירה את זמן האחזור שכרוך בדחיסה עצמה, מה שיכול להאריך את זמני התגובה של השרת במקרה של דחיסה דינמית. משאבים סטטיים כמו JavaScript , CSS ותמונות SVG צריכים להיות דחוסים באופן סטטי, ואילו משאבי HTML במיוחד שנוצרים באופן דינמי למשתמשים מאומתים צריכים להיות דחוסים באופן דינמי.

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

רשתות להעברת תוכן (CDN)

רשת להעברת תוכן (CDN) היא רשת מבוזרת של שרתים ששומרים משאבים מהשרת המקורי שלכם, וכתוצאה מכך מציגים אותם משרתי קצה שנמצאים פיזית בקרבת המשתמשים. הקרבה הפיזית למשתמשים מפחיתה את זמן הלוך ושוב (RTT), ואופטימיזציות כמו HTTP/2 או HTTP/3, שמירה במטמון ודחיסה מאפשרות ל-CDN להציג תוכן מהר יותר מאשר אם הוא מאוחזר משרת המקור שלכם. שימוש ב-CDFB יכול לשפר באופן משמעותי את TTFB של האתר במקרים מסוימים.

בוחנים את הידע

השלב הבא: הבנת הנתיב הקריטי

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