TTFB גבוה – מה זה ולמה האחסון הוא החשוד הראשון

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

בקצרה: TTFB (Time to First Byte) הוא הזמן מרגע שהדפדפן מבקש עמוד ועד שמגיע הבייט הראשון של התשובה מהשרת. לפי web.dev, TTFB טוב הוא עד 0.8 שניות ו-TTFB גרוע הוא מעל 1.8 שניות. כשה-TTFB גבוה, האחסון הוא החשוד הראשון: שרת עמוס או חלש, עמודים שלא יוצאים מקאש, או שרת שנמצא רחוק מהגולשים. את הסיבה מאתרים ב-10 דקות עם בדיקה של עמוד מהקאש מול עמוד בלי קאש.

⏱ זמן אבחון: 10–20 דקות · רמת קושי: בינוני · נבדק לאחרונה מול web.dev ו-PageSpeed Insights: 06.11.2026

מה זה TTFB, ומה נכלל בו?

TTFB (זמן עד הבייט הראשון) מודד כמה זמן לוקח לשרת להתחיל לענות. הוא לא רק "זמן עיבוד בשרת". לפי ההגדרה של web.dev, הוא כולל את כל מה שקורה לפני שהתשובה מתחילה להגיע:

• הפניות (Redirects): כל הפניה, למשל מ-http ל-https ומשם ל-www, מוסיפה סבב שלם.
• DNS: מציאת כתובת ה-IP של הדומיין.
• חיבור ו-TLS: פתיחת החיבור המאובטח לשרת. כאן המרחק הפיזי מורגש הכי הרבה.
• זמן התגובה של השרת: עד שהשרת מכין את העמוד ומתחיל לשלוח אותו. בוורדפרס בלי קאש, זה הזמן שבו PHP ומסד הנתונים בונים את העמוד.

TTFB הוא לא אחד משלושת מדדי הליבה של Core Web Vitals, אבל הוא בא לפני כולם. כל אלפית שנייה בו מתווספת ל-FCP ול-LCP. אם ה-TTFB הוא 2 שניות, כמעט אי אפשר להגיע ל-LCP של 2.5 שניות.

TTFB (אחוזון 75)	הדירוג לפי Google	מה זה אומר בפועל
עד 0.8 שניות	טוב	השרת לא מעכב. אם האתר איטי, חפשו בתמונות וב-JavaScript
0.8–1.8 שניות	דורש שיפור	כנראה חלק מהעמודים לא יוצאים מקאש, או שהשרת רחוק
מעל 1.8 שניות	גרוע	השרת עמוס, חלש או בלי קאש. כאן האחסון הוא הבעיה העיקרית

הספים לפי web.dev ו-PageSpeed Insights, נכון לנובמבר 2026. ב-PageSpeed הם מופיעים בנתוני השטח תחת TTFB, שמסומן שם כמדד ניסיוני.

איך מודדים TTFB?

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

1. PageSpeed Insights: בנתוני השטח תראו את ה-TTFB של גולשים אמיתיים. בבדיקת המעבדה, האבחון שנקרא בערך "צמצום זמן התגובה הראשוני של השרת" מראה כמה זמן לקחה הבקשה הראשית.
2. כלי המפתחים בדפדפן: פתחו F12, לשונית Network, טענו את העמוד ולחצו על הבקשה הראשונה. בלשונית Timing השורה "Waiting for server response" היא זמן התגובה של השרת.
3. שורת פקודה: הפקודה curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.co.il/ מחזירה את ה-TTFB בשניות. הריצו אותה 5 פעמים ברצף והסתכלו על התוצאות מהשנייה והלאה.

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

איך מפרקים את ה-TTFB לחלקים עם curl?

מוסיפים ל-curl תבנית פלט עם משתני הזמן שלו, ומחסרים אותם זה מזה. כך רואים כמה זמן לקחו DNS, החיבור, ה-TLS והשרת עצמו, ומבינים איפה לחפש. הפקודה עובדת ב-Linux, ב-Mac וב-Windows (ב-PowerShell כתבו curl.exe ובמקום /dev/null כתבו NUL):

curl -s -o /dev/null -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} pre=%{time_pretransfer} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.co.il/

כל המשתנים נמדדים בשניות מתחילת הבקשה, ולכן כל אחד כולל את מה שלפניו. לפי התיעוד של curl:

משתנה	עד מתי נמדד	איך מחשבים את החלק
time_namelookup	עד שהסתיים תרגום הדומיין לכתובת IP	DNS = הערך עצמו
time_connect	עד שחיבור ה-TCP לשרת (או ל-Proxy) הושלם	חיבור = connect פחות namelookup
time_appconnect	עד שלחיצת היד של ה-TLS הושלמה	TLS = appconnect פחות connect
time_pretransfer	רגע לפני שההעברה עצמה מתחילה	בדרך כלל כמעט זהה ל-appconnect ב-HTTPS
time_starttransfer	עד שהגיע הבייט הראשון. כולל את pretransfer ואת הזמן שהשרת חישב את התשובה	זה ה-TTFB. שרת = starttransfer פחות pretransfer
time_total	עד סוף ההורדה	הורדה = total פחות starttransfer

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

דוגמה אמיתית: מדדנו את cw-servers.co.il מישראל

ב-06.11.2026 הרצנו את הפקודה 6 פעמים על דף הבית של האתר הזה, מחיבור ביתי בישראל, ועוד 6 פעמים עם פרמטר אקראי שעוקף את הקאש. האתר יושב מאחורי Cloudflare, והכותרת cf-cache-status: HIT אישרה שהבקשה הרגילה יצאה מהקאש. אלה החציונים, במילישניות:

חלק	דף הבית מהקאש	אותו עמוד בלי קאש
DNS	18	12
חיבור TCP	79	78
TLS	92	90
זמן שרת (כולל הלוך-חזור אחד)	107	855
TTFB	297 (טווח 286–310)	1,035 (טווח 1,013–1,279)

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

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

למה ה-TTFB שלי גבוה?

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

1. מדדו עמוד שאמור לצאת מהקאש (דף הבית, גולש לא מחובר), כמה פעמים ברצף. אם הוא עדיין מעל 0.8 שניות, הבעיה היא ברשת (מרחק, DNS, הפניות) או שהקאש לא עובד.
2. בדקו אם הקאש פועל: בכותרות התגובה בכלי המפתחים חפשו את הכותרת x-cache: בשרתי קלאודוויז עם Varnish היא מראה HIT כשהעמוד הוצא מהקאש ו-MISS כשלא (כשיש גם Cloudflare לפני השרת, יש כותרת נוספת, cf-cache-status). אם תמיד MISS, הקאש לא עובד, וזה התיקון הראשון.
3. מדדו עמוד שלא יוצא מהקאש: הוסיפו לכתובת פרמטר אקראי כמו ?nocache=123 (אם הקאש לא מוגדר להתעלם ממנו), או מדדו את העגלה. זה זמן העבודה האמיתי של PHP ומסד הנתונים.
4. ספרו הפניות: בלשונית Network, אם הבקשה הראשונה היא 301 או 302, תקנו את הקישורים כך שיצביעו ישר לכתובת הסופית.
5. בדקו איפה השרת: שרת בארצות הברית מוסיף לכל גולש ישראלי זמן חיבור משמעותי לפני שהשרת בכלל מתחיל לעבוד.

מה מצאתם	הסיבה	התיקון
עמוד מהקאש מהיר, עמוד בלי קאש מעל 1.5 שניות	PHP או מסד נתונים איטיים: תוסף כבד, שאילתות, שרת חלש	Redis ו-Object Cache Pro, איתור התוסף, שרת חזק יותר
גם עמוד "מהקאש" איטי ותמיד MISS	קאש עמודים לא מוגדר או נעקף על ידי עוגייה	הפעלת קאש בצד השרת והחרגה נכונה של עוגיות
TTFB טוב מאירופה, גרוע מישראל	מרחק או ניתוב	שרת קרוב יותר, CDN
TTFB קופץ רק בשעות מסוימות	שרת משותף עמוס או משימות רקע	משאבים ייעודיים, Cron אמיתי במקום WP-Cron
בקשה ראשונה היא 301	הפניות מיותרות	עדכון כתובת האתר והקישורים

אילו דברים בוורדפרס עצמו מעלים את ה-TTFB?

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

• תוסף או תבנית כבדים: התקינו את Query Monitor (תוסף חינמי עם יותר מ-200,000 התקנות פעילות). הוא מציג לכל עמוד את שאילתות מסד הנתונים, מסמן שאילתות איטיות וכפולות, ומקבץ אותן לפי התוסף או התבנית שאחראים להן. פתחו את העמוד האיטי כשאתם מחוברים, וחפשו את הרכיב עם הכי הרבה זמן שאילתות. כבו את התוסף בסוף הבדיקה.
• אפשרויות שנטענות בכל עמוד (autoload): וורדפרס טוען בכל בקשה את האפשרויות בטבלת wp_options שמסומנות לטעינה אוטומטית. תוספים שהוסרו משאירים אותן שם. לפי צוות הליבה של וורדפרס, מגרסה 6.6 בדיקת Site Health מציגה בעיה קריטית כשהסך שלהן עובר 800KB, ואפשרות בודדת מעל 150KB כבר לא נטענת אוטומטית כברירת מחדל. בדקו ב-כלים > בריאות האתר.
• WP-Cron: לפי התיעוד של וורדפרס, WP-Cron רץ בטעינת עמודים ולא ברציפות. באתר עם הרבה משימות מתוזמנות, גולש מסוים "משלם" על הריצה. הפתרון: להוסיף define( 'DISABLE_WP_CRON', true ); ל-wp-config.php ולהריץ את wp-cron.php ממתזמן של השרת. בקלאודוויז עושים את זה ב-Cron Job Management של האפליקציה.
• admin-ajax ו-Heartbeat: לפי התיעוד של Heartbeat API, הוא שולח בקשה לשרת כל 15 עד 120 שניות מכל דף פתוח. כמה עורכים עם לוח ניהול פתוח, ועוד תוספים שמשתמשים ב-admin-ajax, יוצרים עומס קבוע. ב-Query Monitor רואים גם קריאות AJAX.
• קריאות HTTP חיצוניות: תוסף שפונה ל-API חיצוני (רישוי, שערי מטבע, רשתות חברתיות) בזמן בניית העמוד מוסיף את זמן התגובה של אותו שירות ל-TTFB. Query Monitor מציג אותן בחלונית HTTP API Calls.

אחרי כל שינוי, מדדו שוב עם פקודת ה-curl שלמעלה על עמוד בלי קאש. אם שורת "זמן השרת" ירדה, מצאתם את הסיבה. אם היא לא זזה, והשרת עמוס גם בגרפים של הפאנל, הגיע הזמן לשרת חזק יותר או ל-Object Cache Pro.

למה האחסון הוא החשוד הראשון?

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

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

יש גם מקרים שבהם האחסון חף מפשע: תוסף שמריץ שאילתה כבדה בכל עמוד, ערכת עיצוב שקוראת ל-API חיצוני, או אתר עם עשרות הפניות. לכן מאבחנים לפני שמחליפים. ל-PHP איטי יש כלי שמראה בדיוק איזו פונקציה מאטה: New Relic בקלאודוויז.

איך מורידים TTFB בשרת קלאודוויז?

אם האתר כבר בקלאודוויז (Cloudways), או שאתם בודקים אותו בשרת ניסיון, אלה ארבע הפעולות שמשפיעות הכי הרבה:

1. Varnish: שכבת קאש בצד השרת שמגישה עמודים מוכנים בלי להריץ PHP. הוא מותקן מראש בשרתי קלאודוויז ותואם לוורדפרס ולווקומרס. ההפעלה וההחרגות: Varnish בקלאודוויז.
2. Breeze: תוסף הקאש של קלאודוויז, שמנהל את Varnish ואת קאש העמודים מתוך וורדפרס: המדריך ל-Breeze.
3. Redis ו-Object Cache Pro: לעמודים שלא יכולים לצאת מקאש, כמו עגלה ואזור אישי. Redis פועל כברירת מחדל בשרת, ו-Object Cache Pro כלול בחינם משרת של 4GB ומעלה: Object Cache Pro.
4. מיקום שרת קרוב לישראל: בוחרים ספק ענן ומרכז נתונים כשפותחים את השרת. האפשרויות: מיקומי שרתים בקלאודוויז.

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

אילו טעויות נפוצות עושים במדידת TTFB?

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

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

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

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

שאלות נפוצות

מדריכים קשורים

• בדיקת מהירות אתר: איך בודקים נכון
• Core Web Vitals בעברית: LCP, INP ו-CLS
• Varnish בקלאודוויז
• ביקורת קלאודוויז
• כל המדריכים בתחום: ביצועים ומהירות

מקורות רשמיים: Time to First Byte (TTFB) (web.dev), About PageSpeed Insights (Google), curl man page, Options API: Disabling autoload for large options, Hooking WP-Cron Into the System Task Scheduler, Heartbeat API (WordPress), Query Monitor, How to Use Varnish at Cloudways ו-Speed Up Your WordPress Application Using Object Cache Pro (Cloudways Knowledge Base). נכתב ונבדק על ידי עשהאל דרייר · עודכן: 06.11.2026

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