TTFB מוסבר: איך למדוד ולתקן זמן תגובה איטי של השרת

זמן טעינת הדף שלך מורכב מהרבה שלבים. אבל מדד אחד יושב ממש בתחילת השרשרת ומשפיע על כל מה שבא אחריו: Time to First Byte, או TTFB.

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

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

מה TTFB בעצם מודד

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

• DNS lookup — תרגום הדומיין שלך לכתובת IP
• TCP connection + TLS handshake — יצירת חיבור מאובטח לשרת
• זמן עיבוד השרת — השרת מייצר ומתחיל לשלוח את התגובה

הנחיות Core Web Vitals של Google מגדירות TTFB כטוב מתחת ל-800ms, זקוק לשיפור בין 800ms ל-1800ms, וגרוע מעל 1800ms. אבל במציאות, כדאי לשאוף לפחות מ-200ms לרוב הדפים, ומתחת ל-500ms גם לתוכן דינמי שמבוסס על מסד נתונים.

איך למדוד TTFB נכון

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

Browser DevTools

פתח את Chrome DevTools, עבור ללשונית Network, טען מחדש את הדף ולחץ על בקשת המסמך הראשית. תחת לשונית Timing, תראה את ה-TTFB מסומן כ-"Waiting (TTFB)". הרץ את זה כמה פעמים ושים לב גם לטעינה הראשונה וגם לטעינות הבאות.

WebPageTest

WebPageTest הוא הכלי החינמי המפורט ביותר הקיים. הרץ בדיקה ממיקום קרוב למשתמשים האמיתיים שלך. הסתכל על תרשים ה-waterfall — הפס הכחול-ירקרק של מסמך ה-HTML שלך מציג את ה-TTFB בבירור. הרץ לפחות 3 בדיקות והשתמש בתוצאת החציון.

curl למדידה גולמית

למדידה מדויקת וניתנת לחזרה ללא עומס הדפדפן, השתמש ב-curl:

curl -o /dev/null -s -w \ "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \ https://yourdomain.com

זה מפרק כל שלב. אם time_namelookup גבוה (מעל 100ms), ה-DNS שלך הוא צוואר הבקבוק. אם time_appconnect פחות time_connect גבוה, הגדרות ה-TLS שלך זקוקות לעבודה. אם אלה בסדר וה-TTFB עדיין איטי, הבעיה היא בצד השרת.

הסיבות הנפוצות ביותר ל-TTFB גבוה

1. אין Page Caching

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

דף שמגיע מהמטמון מוגש בפחות מ-10ms. דף WordPress ללא מטמון על שרת סביר לוקח בדרך כלל 200–800ms. על שרת עמוס או חלש, זה יכול לעלות על 2 שניות.

עבור WordPress, תוספים כמו W3 Total Cache, WP Super Cache, או LiteSpeed Cache עובדים טוב. Caching ברמת השרת (שמנוהל על ידי Nginx FastCGI cache או Varnish) מהיר אפילו יותר כי הוא עוקף את PHP לגמרי.

2. שאילתות מסד נתונים איטיות

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

הפעל את MySQL slow query log כדי לאתר בעייתיים:

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

לאחר מכן השתמש ב-EXPLAIN על שאילתות איטיות כדי לבדוק אם אינדקסים נמצאים בשימוש. אינדקסים חסרים על עמודות שמשמשות ב-WHERE, JOIN, או ORDER BY הם סיבה נפוצה מאוד לשאילתות שלוקחות שניות כשהן אמורות לקחת מילישניות.

3. הגדרות PHP ו-Opcache

PHP צריך לנתח ולקמפל את קוד האפליקציה שלך בכל בקשה — אלא אם יש לך opcode cache. OPcache שומר את ה-bytecode המקומפל בזיכרון כך ש-PHP מדלג על שלב הניתוח לגמרי.

בדוק אם OPcache פעיל:

php -r "echo opcache_get_status()['opcache_enabled'] ? 'Enabled' : 'Disabled';"

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

; php.ini opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0 ; Disable in production for max speed

4. מרחק גיאוגרפי מהשרת

הפיזיקה לא מתפשרת. בקשה מסידני לשרת בפרנקפורט עוברת כ-17,000 ק"מ. גם במהירות האור, הלוך ושוב מוסיף 100–150ms לפני שהשרת עושה משהו. הוסף נקודות ניתוב ומספר זה גדל.

אם הקהל שלך הוא בינלאומי, CDN פותר את זה על ידי הגשת תגובות ממטמון מ-edge nodes קרובים למשתמשים שלך. Cloudflare, BunnyCDN ו-Fastly כולם עובדים טוב למטרה זו. עבור אפליקציות דינמיות גלובליות באמת, כדאי לשקול מיקום שרת קרוב יותר לקהל הראשי שלך, או ארכיטקטורה שמשכפלת נתונים למספר אזורים.

5. תחרות על משאבים ב-Shared Hosting

ב-shared hosting, ה-CPU והזיכרון של השרת שלך מחולקים עם עשרות או מאות אתרים אחרים. עלייה בתנועה באתר של שכן יכולה לגרום ל-TTFB שלך לקפוץ מ-200ms ל-3 שניות ללא שום שינוי מצדך. זהו אחד הסימנים הברורים ביותר שהגיע הזמן לעבור ל-VPS או לסביבת dedicated managed שבה המשאבים שלך הם באמת שלך.

שיפורים מהירים שאפשר לבצע היום

• הפעל HTTP/2 או HTTP/3. שניהם מפחיתים דרמטית את עומס החיבור דרך multiplexing. בדוק עם curl -I --http2 https://yourdomain.com — חפש HTTP/2 200 בתגובה.
• השתמש בספק DNS מהיר. עבור מה-DNS ברירת המחדל של ה-registrar שלך ל-Cloudflare (1.1.1.1) או Amazon Route 53. זמן ה-DNS lookup יורד מ-50–200ms לפחות מ-10ms.
• הפעל Keep-Alive. חיבורים מתמשכים משתמשים מחדש ב-TCP handshake לבקשות הבאות. ב-Nginx: keepalive_timeout 65;
• דחוס את התגובות שלך. הפעל Gzip או Brotli ברמת השרת. Brotli דוחס HTML, CSS ו-JS בכ-15–20% טוב יותר מ-Gzip.
• כוון את PHP-FPM pool שלך. אם pm.max_children נמוך מדי, בקשות נכנסות לתור המתנה. עקוב אחר pm.status והגדל את גודל ה-pool אם אתה מגיע באופן עקבי למגבלה.

איך לדעת שתיקנת את זה

הרץ מדידת baseline מלאה לפני שאתה מתחיל לשנות משהו. תעד את ה-TTFB לפחות ל-5 כתובות URL — דף הבית שלך, דף קטגוריה, דף מוצר או פוסט, וכל דף דינמי. מדוד ממספר מיקומים באמצעות WebPageTest.

אחרי כל שינוי, מדוד שוב. שיפורי TTFB מצטברים מהר: תיקון OPcache עשוי לחסוך 80ms, הוספת page caching חוסכת עוד 400ms, ומעבר ל-DNS מהיר יותר חוסך 60ms. פתאום אתה יורד מ-700ms למתחת ל-200ms בלי לגעת בשורת קוד אחת של האפליקציה.

על שרת managed מוגדר היטב, ה-TTFB לדפים ממטמון אמור לשבת בנוחות מתחת ל-50ms. לדפים דינמיים ללא מטמון, פחות מ-300ms ניתן להשגה לרוב אפליקציות WordPress או PHP. אם אתה משמעותית מעל המספרים האלה אחרי שעברת על כל הרשימה, צוואר הבקבוק הוא כמעט בוודאות ברמת התשתית — משאבי שרת, מיקום, או הגדרות — ולא באפליקציה שלך.