TTFB (Time to First Byte) הוא הזמן שעובר מהרגע שהדפדפן מבקש עמוד ועד שמגיע הבייט הראשון של התשובה מהשרת. הוא כולל הפניות, חיפוש DNS, יצירת חיבור מאובטח, וזמן העבודה של השרת עצמו. לפי web.dev, TTFB טוב הוא 0.8 שניות או פחות, ו-TTFB גרוע הוא יותר מ-1.8 שניות. כל עוד הבייט הראשון לא הגיע, הדפדפן לא יכול להתחיל לצייר שום דבר — ולכן TTFB איטי מאט את כל השאר.
ממה מורכב TTFB
| שלב | מה קורה | מה משפיע עליו |
|---|---|---|
| הפניות | הדפדפן נשלח לכתובת אחרת לפני העמוד האמיתי | הפניות מיותרות, למשל http ל-https ואז www |
| DNS | תרגום שם הדומיין לכתובת IP | ספק ה-DNS ומטמון |
| חיבור והצפנה | פתיחת חיבור ו-TLS | המרחק לשרת, CDN, גרסת הפרוטוקול |
| זמן השרת | הרצת קוד, שאילתות למסד הנתונים, בניית HTML | מטמון עמודים, קוד, תוספים, שרת |
web.dev מדגישה ש-TTFB הוא לא אחד ממדדי Core Web Vitals. הוא מדד אבחון: הוא לא נמדד לבד בהערכה של גוגל, אבל הוא חלק מכל טעינה, ו-TTFB גבוה כמעט תמיד גורר LCP גבוה.
איך מודדים בלי להטעות את עצמכם
מדידה אחת לא אומרת הרבה. TTFB משתנה לפי המיקום של הגולש, החיבור שלו, והאם העמוד הוגש ממטמון. כשמדדתי את דף הבית של האתר הזה כמה פעמים מהמחשב שלי, הכתובת הרגילה החזירה את הבייט הראשון אחרי כ-0.27–0.32 שניות, וכתובת עם פרמטר אקראי — שלא מוגשת ממטמון העמודים — אחרי כ-0.39–0.49 שניות. ההבדל הזה הוא בדיוק העבודה שהשרת חוסך כשיש מטמון.
כדי לקבל תמונה אמיתית:
- בדקו נתוני שטח של גולשים אמיתיים, לא רק בדיקת מעבדה אחת — ראו בדיקת מהירות אתר.
- בדקו גם עמודים שלא נשמרים במטמון: עמוד חיפוש, עגלה, עמוד שנפתח בפעם הראשונה.
- בכלי המפתחים, בלשונית הרשת, בחרו את בקשת העמוד והסתכלו בפירוט הזמנים: "Waiting for server response" הוא זמן השרת.
מה מקצר TTFB, לפי סדר העדיפויות
1. אחסון מתאים
במדריך של web.dev לשיפור TTFB, האחסון הוא הדבר הראשון שצריך לבדוק — לפני כל אופטימיזציה אחרת. שרת משותף עמוס, גרסת PHP ישנה או מסד נתונים איטי יעקפו כל טריק אחר. על ההבדלים בין סוגי האחסון כתבתי במאמר סוגי שרתי אחסון.
2. מטמון עמודים
באתר דינמי כמו וורדפרס, כל עמוד נבנה מחדש בכל בקשה. מטמון עמודים שומר את ה-HTML המוכן ומדלג על רוב העבודה. זה השיפור הגדול ביותר ברוב אתרי התוכן — עם הסייג שעמודים אישיים, כמו עגלה ואזור לקוחות, לא נשמרים כך. הרחבתי במאמר מטמון באתר.
3. CDN
רשת הפצת תוכן מקצרת את המרחק בין הגולש לשרת, ובעיקר את זמן יצירת החיבור. אם ה-CDN שומר גם את ה-HTML, רוב הגולשים בכלל לא מגיעים לשרת המקור.
4. ביטול הפניות
כל הפניה היא עוד סבב שלם. web.dev ממליצה להתחיל מהפניות בתוך אותו דומיין, שהן בשליטה מלאה שלכם: קישורים פנימיים לכתובת הישנה, הפניה שרשרת של http → https → www, או כתובת בלי לוכסן בסוף שמפנה לכתובת עם לוכסן.
5. קוד ושאילתות
כשהמטמון לא עוזר — כי העמוד אישי או כי יש אלפי וריאציות — הבעיה בקוד: תוסף שמריץ עשרות שאילתות, שאילתה בלי אינדקס, או קריאה לשירות חיצוני בזמן בניית העמוד. כאן צריך למדוד בפועל מה לוקח זמן. כותרת Server-Timing מאפשרת לשרת לדווח לדפדפן כמה זמן לקח כל שלב, ולראות את זה ישירות בכלי המפתחים.
6. 103 Early Hints
טכניקה מתקדמת: השרת שולח לדפדפן רמזים על קבצים חשובים — עיצוב, גופן — עוד לפני שהעמוד מוכן, כך שהדפדפן מתחיל להוריד אותם בזמן שהשרת עובד.
TTFB באינדקסים ובאתרים גדולים
באתרים עם אלפי עמודים, כמו אינדקסים, הרבה מהביקורים מגיעים לעמודים שאף אחד לא ביקר בהם לאחרונה — ולכן הם לא במטמון. שם זמן השרת "הקר" חשוב לא פחות מזמן השרת עם מטמון, ושאילתות יעילות ומטמון אובייקטים הם ההבדל בין אתר שמחזיק לאתר שמאט כשהוא גדל.
שאלות נפוצות
האם TTFB משפיע על הדירוג בגוגל?
TTFB עצמו לא נמדד כמדד Core Web Vitals, אבל הוא חלק מ-LCP — ו-LCP כן. TTFB גבוה מקשה מאוד להגיע ל-LCP טוב.
למה הבדיקה שלי מהירה והגולשים מתלוננים?
כנראה שאתם פוגעים במטמון, או שאתם קרובים לשרת. נסו כתובת שלא נשמרה במטמון, ובדקו את נתוני השטח של גולשים מהטלפון.
מאמרים קשורים: גרסת PHP בוורדפרס: מה מומלץ, מה כבר לא נתמך ואיך משדרגים בלי לשבור.
אבחון TTFB הוא חלק בסיסי בעבודת שיפור מהירות אתר. אם השרת שלכם איטי ואתם לא בטוחים למה, שלחו לי את הכתובת ואבדוק איפה הזמן הולך.
אהבתם את המאמר?
