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

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

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

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

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

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

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

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

שמירת תגובות HTML במטמון

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

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

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

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

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 יכול לכלול כמה מדדים, וגם לגבי כל אחת מהן. לאחר מכן ניתן לאסוף את הנתונים האלה ממשתמשים בשדה באמצעות API של תזמון הניווט וניתוח שלו כדי לבדוק אם המשתמשים חווים ועיכובים. בקטע הקוד הקודם, כותרת התגובה כוללת שני תזמונים:

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

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

דחיסה

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

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

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

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

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

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

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

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

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