כשאנחנו בודקים ספקי אחסון ואומרים "Kinsta הכי מהיר ב-312ms" — אנחנו מדברים על TTFB. זה המדד הכי חשוב לביצועי שרת, והכי פחות מוסבר בבהירות.
מה זה TTFB בפשטות
TTFB = Time to First Byte.
זה הזמן שעובר מרגע שהדפדפן שולח בקשה לשרת, עד שהבית הראשון של התגובה מגיע.
[Browser sends request]
|
↓ ← TTFB מתחיל כאן
[DNS lookup: ~5–50ms]
[TCP connection: ~10–100ms]
[Server processing: ~50–400ms] ← הגורם העיקרי
[First byte arrives] ← TTFB נגמר כאן
|
↓
[Browser downloads full HTML]
[Browser renders page]
[LCP ← משתמש רואה תוכן]
לכן TTFB קריטי: אם השרת לוקח 700ms להחזיר את הבית הראשון, המשתמש לא רואה כלום 700ms. אחרי ה-HTML, עוד צריך לטעון CSS, JavaScript, ותמונות. TTFB גבוה = LCP גבוה — ולא ניתן לפצות על זה בצד הלקוח.
מה בדיוק מרכיב את ה-TTFB?
TTFB מורכב מ-3 שלבים:
1. Redirect time — אם האתר שלכם מבצע redirect (http→https, www→non-www), זה מוסיף 50–200ms לכל בקשה ראשונה.
2. Connection time — DNS lookup + TCP handshake + TLS negotiation. לדפדפן חדש שמבקר לראשונה: 50–200ms. CDN מקרוב: 5–20ms.
3. Server processing time — כמה זמן לוקח לשרת לייצר את ה-HTML. זה הגורם שספק האחסון שולט בו.
שרת שמריץ PHP + MySQL ללא קאשינג: 200–500ms. שרת עם FastCGI page cache: 5–50ms. שרת עם Redis + CDN: 10–30ms.
איך מודדים TTFB?
שיטה 1 — Chrome DevTools (הכי מדויק):
- פתחו Chrome, נכנסו לאתר שלכם
- F12 → Network tab
- Ctrl+Shift+R (טעינה מחדש ללא cache)
- לחצו על הבקשה הראשונה (HTML)
- Timing tab → "Waiting (TTFB)"
שיטה 2 — GTmetrix: נכנסים ל-gtmetrix.com, מכניסים URL. ה-Waterfall chart מראה TTFB בתחילת הבקשה הראשונה.
שיטה 3 — WebPageTest: נכנסים ל-webpagetest.org, בוחרים מיקום בדיקה. יותר מדויק כי בוחרים מיקום גיאוגרפי.
שיטה 4 — curl (מהטרמינל):
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yoursite.com
מה הציון שלכם אומר?
| TTFB | פירוש | מה לעשות |
|---|---|---|
| מתחת ל-200ms | מצוין | שרת עם cache מלא — שמרו כך |
| 200–400ms | טוב | ביצועים תקינים לאחסון מנוהל |
| 400–600ms | בינוני | תבדקו קאשינג וRedis |
| 600ms–1s | גרוע | TTFB הזה ייצור LCP בעייתי — דרוש פתרון |
| מעל 1s | קריטי | הספק שלכם לא מתאים לצרכים שלכם |
הנתונים מהבדיקות שלנו:
| ספק | TTFB (ללא קאשינג) | TTFB (עם קאשינג) |
|---|---|---|
| Kinsta | 312ms | ~147ms |
| Cloudways | 387ms | ~210ms |
| WP Engine | 398ms | ~185ms |
| SiteGround | 441ms | ~280ms |
| DreamHost | 489ms | ~350ms |
למה TTFB משתנה לפי מיקום?
השוואה: TTFB ל-Kinsta מ-3 מיקומים:
- ניו יורק: 298ms
- פרנקפורט: 319ms
- סינגפור: 320ms
ו-TTFB ל-uPress מ-3 מיקומים:
- תל אביב: 89ms
- פרנקפורט: 198ms
- ניו יורק: 287ms
ה-physical distance לשרת חשוב. גם CDN מצוין לא מפחית ל-0 את זמן ה-server processing — CDN עוזר לנכסים סטטיים (CSS, JS, תמונות), לא לעמוד ה-HTML עצמו (אלא אם Edge Side Caching מופעל).
מה ספק אחסון יכול לעשות להוריד TTFB?
FastCGI Page Cache: שומר HTML מוכן לפי URL. בקשה שניה לאותו URL מוגשת ב-5–50ms.
Redis Object Cache: מפחית database queries כפולות. לא מוריד TTFB דרמטית עבור pages שכבר cached, אבל עוזר לעמודים דינמיים (checkout, account).
PHP 8.3 + OPcache: PHP 8.3 מהיר ב-30–40% מ-PHP 7.4. OPcache שומר PHP bytecode בזיכרון.
Google Cloud C2 (Kinsta): מעבדי AMD EPYC compute-optimized עם more single-thread performance. זה הסיבה ש-Kinsta מנצחת ב-TTFB.
שרת קרוב פיזית לגולשים: uPress עם שרת ישראלי → 89ms מתל אביב. Kinsta עם שרת פרנקפורט → 285ms מתל אביב.
קשר בין TTFB ל-LCP
גוגל מגדיר יעד TTFB של מתחת ל-800ms. אבל בפועל:
- TTFB 800ms → LCP יהיה בקלות 3–4 שניות (fail)
- TTFB 400ms → LCP של 1.5–2.5 שניות (borderline)
- TTFB 200ms → LCP של 0.8–1.5 שניות (pass)
TTFB הוא הבסיס — ה-LCP לא יכול להיות טוב יותר מה-TTFB. לכן תמיד מתחילים מהשרת, לא מהתמונות.