איך לקצר את זמן תגובת השרת: אבחון ושיפור TTFB

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

Time to First Byte, או TTFB, הוא הזמן עד שהדפדפן מקבל את הבייט הראשון בתגובה לבקשת הניווט. הוא רחב יותר מהזמן שהיישום משקיע ביצירת HTML. המטרה המעשית היא לספק תוכן שימושי מוקדם יותר, ולכן בודקים את ההשפעה על הרינדור לצד הבייט הראשון.

מגדירים את המדידה לפני בחירת היעד

הנחיות Google לשיפור TTFB מתייחסות ל-800 אלפיות שנייה או פחות כאל יעד טוב בקירוב. TTFB עצמו אינו אחד משלושת מדדי Core Web Vitals. ערך גבוה יותר מצדיק בדיקה, אבל ההכרעה צריכה לכלול את מהירות הופעתו של תוכן משמעותי.

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

גם היקף המדידות שונה. TTFB של ניווט בנתוני שטח עשוי לכלול השהיות שבדיקת מעבדה של המסמך הסופי אינה כוללת. הבדיקה הישנה של Lighthouse לזמן תגובת שרת לא ייצגה את כל רצף ה-DNS, ההפניות והחיבור. ההנחיות הנוכחיות של Chrome משתמשות גם בתובנה Document request latency, ולכן שם ישן במדריך לא בהכרח תואם לדוח שלכם.

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

עוקבים אחר הבקשה מהניווט ועד ל-HTML שימושי

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

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

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

יוצרים קו בסיס בדפדפן במסלול האמיתי של המבקר

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

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

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

אם יש שירות בדיקה או ניטור מתאים, חוזרים על הבדיקה מאזורים שחשובים לקהל. בקשה מהירה ממחשב קרוב למקור אינה ראיה חזקה לחוויית מבקרים מרוחקים. מתארים את המיקום והתנאים במקום להציג מדידה אחת כתוצאה עולמית.

משתמשים ב-curl להפרדת נקודות זמן מצטברות

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

curl --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://example.com/'

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

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

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

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

מודדים בתוך היישום בלי לחשוף מידע פרטי

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

כותרת התגובה Server-Timing מציגה לכלי הדפדפן משכי זמן בעלי שמות. דוגמת PHP המלאה הבאה מודדת יצירת תגובת HTML ציבורית קטנה. היא משתמשת ב-hrtime, הזמין מ-PHP 7.3; בסביבת ייצור צריך להשתמש בגרסה תואמת שעדיין נתמכת.

<?php
declare(strict_types=1);

$started = hrtime(true);
$title = htmlspecialchars('Performance example', ENT_QUOTES, 'UTF-8');
$html = '<!doctype html><html lang="en"><meta charset="utf-8">'
      . '<title>' . $title . '</title><h1>' . $title . '</h1></html>';
$durationMs = (hrtime(true) - $started) / 1e6;

header('Content-Type: text/html; charset=utf-8');
header('Cache-Control: no-store');
header('Server-Timing: render;dur=' . number_format($durationMs, 3, '.', ''));
echo $html;

משך הזמן נמדד כשהדוגמה רצה; אין כאן תוצאת מבחן ביצועים נטענת. מדיניות no-store מונעת שמירת תגובת האבחון במטמוני HTTP. היא אינה המלצה לכל דף ציבורי.

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

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

בוחרים במטמון שמסיר את העבודה היקרה

מטמון דפים, מטמון אובייקטים ומטמון opcode פותרים בעיות שונות. הם יכולים לפעול יחד, אך הפעלת אחד אינה מוכיחה שהאחרים קיימים או מועילים.

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

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

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

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

מגינים על סשנים, עגלות ותוכן אישי

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

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

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

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

מתקנים את המקור האיטי גם כשהמטמון עובד

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

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

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

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

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

משתמשים ב-CDN כאשר המרחק והשימוש החוזר מצדיקים זאת

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

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

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

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

מתייחסים לפרוטוקולים כחלק אחד ממסלול ההגשה

ריבוב HTTP/2 ותעבורת QUIC של HTTP/3 יכולים לשפר את שיתוף החיבורים. ההשפעה תלויה בחיבור, ברשת ובמימוש השרת. אף פרוטוקול אינו מבטל עבודה איטית במסד נתונים או מבטיח בייט ראשון מהיר יותר בכל בקשה.

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

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

Early Hints יכול לשנות גם את משמעות מדידת הבייט הראשון. Chrome סופר כיום את תגובת הביניים ב-responseStart, בעוד finalResponseHeadersStart, כאשר הוא זמין, מזהה את תחילת כותרות התגובה הסופית. מתעדים דפדפן ושדה זמן בהשוואות כאלה. תגובת ביניים מוקדמת אינה מוכיחה שה-HTML הסופי הגיע קודם.

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

מזהים מתי האחסון הוא צוואר הבקבוק

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

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

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

מאמתים את השיפור במסלול שנכשל

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

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