השלב הראשון ביצירת אתר שנטען במהירות הוא קבלת תגובה מהירה מהשרת לגבי קוד ה-HTML של הדף. כשמזינים כתובת URL בסרגל הכתובות של הדפדפן, הדפדפן שולח בקשת GET לשרת כדי לאחזר אותה. הבקשה הראשונה לדף אינטרנט היא למשאב HTML – והבטחה שקובץ ה-HTML יגיע במהירות עם עיכובים מינימליים היא יעד חשוב לשיפור הביצועים.
הבקשה הראשונית לקובץ HTML עוברת כמה שלבים, וכל אחד מהם לוקח זמן. קיצור הזמן שמוקדש לכל שלב יאפשר לכם לקבל זמן מהיר יותר עד לביט הראשון (TTFB). המדד TTFB הוא לא המדד היחיד שצריך להתמקד בו כשבודקים כמה מהר הדפים נטענים, אבל ערך גבוה של TTFB מקשה להגיע לסף הנדרש של 'טוב' במדדים כמו הצגת חלק התוכן הגדול ביותר (LCP) והצגת תוכן ראשוני (FCP).
צמצם הפניות מחדש
כשמתבצעת בקשה למשאב, השרת עשוי להשיב בהפניה אוטומטית, או בהפניה אוטומטית קבועה (תשובה 301 Moved Permanently) או בהפניה אוטומטית זמנית (תשובה 302 Found).
הפניות אוטומטיות מאטות את מהירות טעינת הדף כי הן מחייבות את הדפדפן לשלוח בקשת HTTP נוספת במיקום החדש כדי לאחזר את המשאב. יש שני סוגים של הפניות אוטומטיות:
- הפניות מאותו מקור שמתרחשות כולן בתוך המקור שלכם. סוגי ההפניות האלה נמצאים בשליטה מלאה שלכם, כי הלוגיקה לניהול שלהן נמצאת כולה בשרת האינטרנט שלכם.
- הפניות אוטומטיות ממקורות שונים שמופעלות על ידי מקור אחר. בדרך כלל אין לכם שליטה בסוגים האלה של הפניות אוטומטיות.
הפניות לכתובות אחרות מדומיין אחר משמשות לעיתים קרובות מודעות, שירותים לקיצור כתובות 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 בכלל.
מדידת זמני התגובה של השרת
אם התגובה לא נשמרת במטמון, זמן התגובה של השרת תלוי מאוד בספק האירוח ובחבילת האפליקציות של ה-Backend. דף אינטרנט שמציג תגובה שנוצרת באופן דינמי – כמו שליפת נתונים ממסד נתונים, למשל – עשוי להיות בעל TTFB גבוה יותר מדף אינטרנט סטטי שאפשר להציג באופן מיידי בלי זמן חישוב משמעותי בקצה העורפי. הצגת אנימציית טעינה ואז אחזור של כל הנתונים בצד הלקוח מעבירה את המאמץ מסביבה צד-שרת צפויה יותר לסביבה צד-לקוח שעלולה להיות בלתי צפויה. צמצום המאמץ בצד הלקוח בדרך כלל מוביל לשיפור במדדים שמתמקדים במשתמש.
אם המשתמשים חווים TTFB איטי בשדה, אפשר לחשוף מידע על הזמן שהוקדש לשרת באמצעות 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.
בדרך כלל, רוב ספקי אירוח האתרים מגדירים דחיסה באופן אוטומטי, אבל אם אתם יכולים להגדיר או לשנות את הגדרות הדחיסה בעצמכם, יש כמה דברים חשובים שכדאי לקחת בחשבון:
- מומלץ להשתמש ב-Brotli כשהדבר אפשרי. כמו שציינו קודם, Brotli מספק שיפור משמעותי בהשוואה ל-gzip, וBrotli נתמך בכל הדפדפנים העיקריים. מומלץ להשתמש ב-Brotli כשזה אפשרי, אבל אם באתר שלכם משתמשים הרבה אנשים בדפדפנים מדור קודם, חשוב לוודא שנעשה שימוש ב-gzip כגיבוי, כי כל דחיסה עדיפה על אף דחיסה.
- גודל הקובץ חשוב. דחיסה של משאבים קטנים מאוד – פחות מ-1KiB – לא תמיד יעילה, ולפעמים היא לא מתבצעת בכלל. היעילות של כל סוג של דחיסת נתונים תלויה בכמות גדולה של נתונים שאלגוריתם הדחיסה יכול לעבוד איתם כדי למצוא עוד ביטים של נתונים שניתנים לדחיסה. ככל שהקובץ גדול יותר, כך הדחיסה יעילה יותר. עם זאת, אל תשלחו משאבים גדולים מאוד רק בגלל שאפשר לדחוס אותם בצורה יעילה יותר. ניתוח והערכה של משאבים גדולים – כמו JavaScript ו-CSS – לוקחים הרבה יותר זמן אחרי שהדפדפן מבטל את הדחיסה שלהם. יכול להיות שהם ישתנו לעיתים קרובות יותר, גם אם השינויים קלים, כי כל שינוי יוצר גיבוב קבצים שונה.
- הסבר על דחיסה דינמית לעומת דחיסה סטטית דחיסה דינמית ודחיסה סטטית הן גישות שונות למתי צריך לדחוס משאב. דחיסה דינמית דוחסת משאב בזמן הבקשה, ולפעמים בכל פעם שמתקבלת בקשה למשאב. לעומת זאת, דחיסה סטטית דוחסת קבצים מראש, כך שלא נדרשת דחיסה בזמן הבקשה. דחיסה סטטית מסירה את זמן האחזור שקשור לדחיסה עצמה, שיכול להתווסף לזמני התגובה של השרת במקרה של דחיסה דינמית. משאבים סטטיים – כמו JavaScript, CSS ותמונות SVG – צריכים להיות דחוסים באופן סטטי, בעוד שמשאבי HTML – במיוחד אם הם נוצרים באופן דינמי עבור משתמשים מאומתים – צריכים להיות דחוסים באופן דינמי.
קשה לבצע דחיסה בצורה נכונה לבד, ולכן לרוב עדיף להשתמש ברשת להעברת תוכן (CDN) – שמוסבר עליה בקטע הבא – כדי שהיא תבצע את הדחיסה בשבילכם. עם זאת, היכרות עם המושגים האלה יכולה לעזור לכם להבין אם ספק האירוח שלכם משתמש בדחיסה בצורה נכונה. הידע הזה יכול לעזור לכם למצוא הזדמנויות לשפר את הגדרות הדחיסה כדי להפיק את התועלת המקסימלית מהאתר.
רשתות להעברת תוכן (CDN)
רשת להעברת תוכן (CDN) היא רשת מבוזרת של שרתים ששומרים במטמון משאבים משרת המקור שלכם, ומציגים אותם משרתי קצה שנמצאים קרוב יותר פיזית למשתמשים שלכם. הקרבה הפיזית למשתמשים מקצרת את זמן הלוך ושוב (RTT), ואילו אופטימיזציות כמו HTTP/2 או HTTP/3, שמירה במטמון ודחיסה מאפשרות ל-CDN להציג תוכן מהר יותר מאשר אם הוא היה נשלף משרת המקור. שימוש ב-CDN יכול לשפר באופן משמעותי את מדד TTFB של האתר שלכם במקרים מסוימים.
בוחנים את הידע
איזה סוג של הפניה אוטומטית נמצא בשליטה מלאה שלכם?
הכותרת Server-Timing יכולה להכיל כמה מדדים.
איזה סוג שרת הכי קרוב פיזית למשתמשי הקצה שלכם?
השלב הבא: הסבר על הנתיב הקריטי
עכשיו, אחרי שקיבלתם מידע על כמה שיקולים שקשורים לביצועים של קובץ ה-HTML באתר, אתם יכולים לוודא שהוא נטען במהירות האפשרית. אבל זה רק השלב הראשון בתהליך הלמידה על ביצועי אתרים. בהמשך, נסביר על התיאוריה שמאחורי נתיב העיבוד הקריטי. במודול הזה מתוארים מושגי מפתח כמו משאבים שחוסמים עיבוד ומשאבים שחוסמים ניתוח, והתפקיד שלהם בעיבוד הראשוני של דף בדפדפן במהירות האפשרית.