אתם לוחצים על כפתור באתר ושום דבר לא קורה במשך שנייה או שתיים. לעיכוב הקטן והמעצבן הזה יש שם: First Input Delay. ולמרות שרוב האנשים חושבים שזו בעיה של JavaScript, האמת היא שעוצמת העיבוד של שרת האחסון שלכם משחקת תפקיד הרבה יותר גדול ממה שרוב המפתחים מבינים.
אם אתם מחפשים הגדרת Core Web Vitals באחסון שתשפר את הציונים שלכם, הבנת המקור האמיתי של FID תחסוך לכם שעות של רדיפה אחרי הפתרון הלא נכון.
מה First Input Delay באמת מודד
First Input Delay עוקב אחרי הזמן שבין האינטראקציה הראשונה של המשתמש (לחיצה, הקשה, לחיצת מקש) לבין הרגע שבו ה-thread הראשי של הדפדפן באמת פנוי להגיב לה. גוגל מחשיבה כל ערך מתחת ל-100 מילישניות כטוב, 100-300 מילישניות כטעון שיפור, וכל דבר מעל 300 מילישניות כגרוע.
הנה החלק שרוב האנשים מפספסים: FID לא מודד כמה מהר ה-JavaScript שלכם רץ. הוא מודד כמה עמוס ה-thread הראשי של הדפדפן כשהמשתמש מנסה לבצע אינטראקציה. אם ה-thread עסוק בפענוח חבילת JavaScript ענקית או ממתין לתגובה איטית מהשרת כדי לעבד תוכן, הלחיצה של המשתמש פשוט מחכה בתור.
שימו לב שגוגל החליפה את FID במדד Interaction to Next Paint (INP) כמדד הרשמי של Core Web Vitals. אבל הלקח הבסיסי זהה: הרספונסיביות תלויה במה שקורה גם בדפדפן וגם בשרת, עוד לפני שהדף בכלל הופך לאינטראקטיבי.
למה השרת חשוב יותר ממה שחשבתם
שרת איטי מעכב הכל בהמשך השרשרת. אם ה-Time to First Byte שלכם עומד על 800 מילישניות במקום 200, הדפדפן אפילו לא מתחיל לבנות את הדף עד שהתגובה מגיעה. זה דוחה את הפענוח, את העיבוד, ואת הנקודה שבה ה-thread הראשי נהיה פנוי לטפל בקלט מהמשתמש.
תחשבו על זה כעל שרשרת של תגובות:
- תגובת שרת איטית מעכבת את מסירת ה-HTML
- HTML מעוכב מעכב את פענוח ה-CSS וה-JS
- פענוח מעוכב משאיר את ה-thread הראשי עסוק זמן רב יותר
- thread ראשי עמוס אומר שהלחיצה או ההקשה שלכם מחכות בתור
כתבנו בעבר על למה Time to First Byte גורם לכם לאבד המרות, ואותם מנגנונים חלים גם כאן. מהירות השרת היא לא נושא נפרד מרספונסיביות הקלט. היא הדומינו הראשון.
עוצמת CPU ועיבוד PHP מאחורי הקלעים
אם אתם מריצים WordPress, WooCommerce, או כל CMS דינמי אחר, כל בקשת דף בדרך כלל מפעילה ריצת PHP, שאילתות למסד נתונים, ולפעמים גם עיבוד ברמת התוספים לפני שהשרת שולח בחזרה משהו. כל זה קורה על ה-CPU של השרת שלכם.
על שרת שיתופי חלש או עמוס מדי, ה-PHP-FPM workers שלכם אולי מתחרים עם עשרות אתרים אחרים על אותם מחזורי CPU. זה אומר:
- זמן ריצת PHP איטי יותר לכל בקשה
- זמני המתנה ארוכים יותר בזמן עומסי תנועה
- שאילתות מסד נתונים שממתינות לזמינות CPU
- זמני תגובה לא עקביים שקופצים תחת עומס
כיסינו את המנגנונים האלה באיך הגדרת pool של PHP-FPM משפיעה על תגובת השרת שלכם תחת עומס. בקצרה: אם ה-worker pool שלכם מוגדר לא נכון או שה-CPU שלכם במקסימום, כל בקשה לוקחת יותר זמן לעיבוד, והעיכוב הזה מתגלגל קדימה ומשפיע על המהירות שבה הדף הופך לשמיש עבור המבקר.
חיבור מסד הנתונים שכנראה לא חשבתם עליו
שאילתות איטיות מוסיפות מילישניות אמיתיות לזמן העיבוד של השרת. דף מוצר שמריץ 40 שאילתות לא מותאמות על שרת מסד נתונים חלש יכול בקלות להוסיף 300-500 מילישניות לזמן התגובה. תכפילו את זה במבקרים בו זמנית ותקבלו שרת שתמיד מפגר מאחור, מה שאומר תגובות איטיות יותר ורספונסיביות קלט גרועה יותר עבור כל מי שנכנס לאתר באותו זמן.
אינדוקס של העמודות הנכונות, שמירה במטמון של תוצאות שאילתות חוזרות, ושימוש ב-connection pooling, כל אלה מפחיתים את עבודת ה-CPU שהשרת שלכם צריך לבצע לכל בקשה. פחות עבודת CPU לכל בקשה אומר יותר מרווח נשימה כשתנועה אמיתית מגיעה.
איך caching מפחית את העומס על ה-CPU שלכם
caching של דף שלם ו-object caching קיימים בדיוק בשביל להוריד עומס מהמעבד. במקום להריץ PHP ולפנות למסד הנתונים בכל בקשה, תגובה שמורה במטמון מוגשת כמעט מיידית, ישירות מהזיכרון.
object caching מבוסס Redis הוא דוגמה טובה. הוא שומר בזיכרון תוצאות של שאילתות מסד נתונים שנגשים אליהן הרבה, כך שהשרת שלכם מדלג על הטיול היקר אל מסד הנתונים עבור דברים שכבר חושבו. ראינו אתרי WordPress שהפחיתו דרמטית את זמן שאילתות מסד הנתונים אחרי הפעלת object cache, פשוט כי ל-CPU יש פחות עבודה לעשות.
אם אתם רוצים הסבר מעמיק יותר על איך להגדיר את זה כמו שצריך, כיסינו את זה באיך להגדיר Redis caching בשרת שלכם בלי לשבור שום דבר.
איך נראה אחסון טוב עבור Core Web Vitals
כשאנשים מחפשים Core Web Vitals באחסון, הם בדרך כלל מחפשים ספק שמסדר את היסודות לפני שהם בכלל נוגעים בקוד שלהם. זה אומר:
- מספיק מרווח CPU לכל אתר, לא משאבים שיתופיים עמוסים מדי
- אחסון NVMe ל-I/O דיסק מהיר יותר בזמן ביצוע שאילתות
- pools של PHP-FPM מכוילים כראוי שמתאימים את עצמם לתנועה
- caching ברמת השרת זמין כברירת מחדל
- ניטור שמזהה קפיצות CPU לפני שהן הופכות לתגובות איטיות
ספק אחסון מנוהל שעוקב באופן יזום אחרי שימוש במשאבי שרת יכול לתפוס צוואר בקבוק ב-CPU לפני שהוא בכלל מופיע כציון FID או INP גרוע בדוח Search Console שלכם. זו גם הסיבה שאנחנו עוקבים אחרי הקצאת המשאבים בכל השרתים שלנו, ולא רק מוכרים מספר על דף מפרט.
מה אתם באמת יכולים לעשות בנידון
אם דוח Core Web Vitals שלכם מראה ציוני רספונסיביות גרועים, אל תתחילו בכתיבה מחדש של ה-JavaScript. התחילו מכאן:
- בדקו את זמן התגובה הממוצע של השרת שלכם תחת תנועה אמיתית, לא רק בדיקה במצב סרק
- הסתכלו על השאילתות האיטיות ביותר במסד הנתונים שלכם והוסיפו אינדקסים היכן שצריך
- הפעילו object caching אם ה-CMS שלכם תומך בזה
- וודאו שה-worker pool של PHP שלכם לא במקסימום בשעות העומס
- שקלו אם התוכנית הנוכחית שלכם נותנת לכם משאבי CPU ייעודיים או שיתופיים
עברנו על התמונה הרחבה יותר בCore Web Vitals ואחסון: למה השרת שלכם או עוזר או פוגע בציונים שלכם, שמשתלב טוב עם זה אם אתם רוצים את התמונה המלאה מעבר רק לעיכוב קלט.
לסיכום
First Input Delay מרגיש כמו בעיה של front-end כי הוא מופיע בדפדפן. אבל חלק גדול ממה שגורם לו קורה עוד לפני שהדפדפן בכלל מקבל הזדמנות לעבד את הדף שלכם. עוצמת CPU של השרת, יעילות עיבוד PHP, וזמן תגובה של מסד הנתונים, כולם מזינים ישירות את המהירות שבה הדף שלכם הופך לאינטראקטיבי.
אם שיפרתם את גודל חבילת ה-JavaScript שלכם ועדיין רואים ציוני רספונסיביות גרועים, כדאי לבדוק את השרת שלכם, לא את הקוד. לפעמים התיקון הכי מהיר הוא לא שורת קוד בכלל. זה פשוט מעבר לאחסון שנותן לאתר שלכם את מרווח העיבוד שהוא באמת צריך.
