מה ההבדל בין אתר שמרגיש איטי לאתר שנכשל במדדי Core Web Vitals?
שתי תלונות שנשמעות זהות ומגיעות משני מקומות שונים לגמרי. הראשונה: האתר מרגיש איטי, לוחצים על קישור ומחכים. השנייה: הדוח של גוגל מסמן את הכתובות שלכם באדום במדדי Core Web Vitals, למרות שכשאתם פותחים את האתר הוא נראה בסדר. אלה לא אותה בעיה, והן גם לא מתוקנות באותה דרך. איטיות מורגשת מתחילה ברוב המקרים בצד השרת, כלומר בזמן שלוקח לו להתחיל לענות. כישלון במדדים מתרחש בדרך כלל בדפדפן, אחרי שהתשובה כבר הגיעה, בגלל מה שנטען ומה שקופץ על המסך. במאמר הזה אני מפריד בין השניים, מראה איך לבדוק בעצמכם תוך עשר דקות לאיזה צד אתם שייכים, ומה עולה כל טיפול.
תוכן העניינים 7 פרקים
שתי בעיות שנשמעות אותו דבר
הדרך הפשוטה להבין את ההבדל היא לחשוב על שני שעונים. השעון הראשון מתחיל כשהדפדפן מבקש את הדף ונעצר כשמגיע הבייט הראשון של התשובה. זה TTFB, והוא מודד את השרת ואת מה שקורה בו לפני שהוא בכלל התחיל לשלוח משהו.
השעון השני מתחיל כשהתשובה מגיעה ונמשך עד שהדף שמיש: התמונה הגדולה נטענה, אפשר ללחוץ ולקבל תגובה, וכלום לא זז פתאום. שם יושבים המדדים LCP, INP ו-CLS.
אתר יכול להיכשל בשעון אחד ולהיות מצוין בשני. שרת מהיר עם דף עמוס בסקריפטים ייתן תחושה של פתיחה מהירה ואז קיפאון. שרת איטי עם דף רזה ייתן המתנה בהתחלה ואז חוויה חלקה. הטיפול בכל אחד מהם שונה, וגם המחיר שונה. זו הסיבה שאני מתחיל כל תיקון אתר וורדפרס איטי באבחון ולא בפעולה.
יש עוד הבדל שמבלבל הרבה בעלי אתרים. הדוח שמראה את המדדים בחיפוש מבוסס על נתונים שנאספים מגולשים אמיתיים לאורך תקופה, ולא על בדיקה שרצה עכשיו. לכן שיפור שביצעתם היום לא יופיע שם מחר, ולפעמים חולפים שבועות עד שהתמונה מתעדכנת. בדיקה חד פעמית בכלי מדידה נותנת תשובה מיידית, והיא מודדת מכשיר אחד ורשת אחת ולא את הקהל שלכם.
איטיות שמתחילה בשרת
כשהתלונה היא שהאתר איטי בכל דף, שהניהול כבד, ושזה קורה גם למי שכבר ביקר, המקור כמעט תמיד בצד השרת. אלה החשודים הרגילים:
- אחסון שיתופי עמוס, שבו האתר שלכם מחכה בתור.
- גרסת PHP ישנה שכבר לא מקבלת עדכונים ועובדת לאט יותר.
- שאילתות כבדות למסד הנתונים, לרוב מתוסף שמריץ חיפוש או סינון בכל טעינה.
- טבלאות שהתנפחו: גרסאות ישנות של פוסטים, לוגים, ותוספים שהוסרו והשאירו נתונים.
- מטמון שאינו מוגדר, או מוגדר ומבוטל בפועל על ידי תוסף אחר.
- משימות מתוזמנות שרצות בכל טעינת דף במקום לפי לוח זמנים.
הכלי שאני מתחיל בו הוא Query Monitor, שמראה בדיוק כמה שאילתות רצו, כמה זמן לקחו, ואיזה תוסף אחראי להן. ההבדל בין ניחוש לבין דוח כזה הוא ההבדל בין להסיר חמישה תוספים בתקווה לבין להסיר את אחד שגורם לבעיה.
שווה להגיד גם מה לא פותר את זה: הוספת עוד תוסף שיפור מהירות. אתר איטי עם ארבעה תוספי מטמון הוא תופעה שאני פוגש הרבה, והתוצאה בדרך כלל גרועה יותר מאתר בלי אף אחד מהם.
עוד גורם ששווה לבדוק לפני שמשקיעים בקוד: סוג האחסון. אתר עם תנועה רצינית שיושב בחבילה שיתופית בסיסית יגיע לתקרה בלי קשר לאיכות הבנייה. לפעמים מעבר לחבילה מתאימה עולה פחות מיום עבודה של אופטימיזציה, ופותר יותר. אני בודק את זה מוקדם כדי לא להמליץ על עבודה מיותרת.
כישלון במדדים: מה קורה בדפדפן
הצד השני של הסיפור הוא מה שהדפדפן עושה אחרי שקיבל את הדף. שלושת המדדים בודקים שלושה דברים שונים, וכל אחד מהם נשבר מסיבה אחרת.
LCP מודד מתי מופיע הרכיב הגדול ביותר במסך, בדרך כלל תמונת הבאנר או כותרת ראשית. הוא נשבר בגלל תמונות ענקיות שנטענות בגודל מלא, גופנים שחוסמים תצוגה, או סקריפט שרץ לפני התוכן.
INP מודד כמה מהר הדף מגיב ללחיצה. הוא נשבר בגלל קוד JavaScript כבד שתופס את הדפדפן, לרוב מסקריפטים חיצוניים של מעקב, צאט וקופצים.
CLS מודד קפיצות בפריסה. הוא נשבר בגלל תמונות בלי מידות מוגדרות, באנרים שנטענים מאוחר ודוחפים תוכן, ומודעות שמופיעות אחרי הטעינה הראשונה.
שלושתם מתוקנים בקוד ובנכסים ולא בשרת. זה בדיוק התחום של אופטימיזציית מהירות וורדפרס ו-Core Web Vitals, ₪1,500-₪4,500 חד-פעמי לפני מע״מ, ושם העבודה היא דחיסת תמונות, טעינה עצלה, טיפול בגופנים והסרת קוד שאינו בשימוש.
מבין השלושה, תמונות הן כמעט תמיד ההחזר הגדול ביותר. אתר עסקי ממוצע בעברית נושא תמונות שהועלו במידות מקוריות מהמצלמה או מבנק תמונות, פי כמה ממה שנדרש בפועל. המרה לפורמט מודרני והגדרת מידות נכונות משנות את המדד הראשון בצורה שאף אופטימיזציה של קוד לא משיגה.
בדיקה עצמית של עשר דקות
אפשר לדעת לאיזה צד אתם שייכים בלי ידע טכני. שלושה שלבים:
- פתחו את האתר בחלון פרטי במחשב ובדקו כמה זמן עובר עד שמשהו מופיע. אם הדף לבן שתי שניות ואז נטען כמעט הכול בבת אחת, זה סימן לשרת.
- אם התוכן מופיע מהר ואז הדף קופץ, ממשיך להיטען, או לא מגיב ללחיצה, זה סימן לדפדפן.
- הריצו בדיקת PageSpeed על דף הבית ועל דף תוכן פנימי אחד. אם הציון הרבה יותר טוב בדף הפנימי, הבעיה בבנייה של דף הבית ולא באתר כולו.
בדיקה רביעית ששווה זהב: פתחו את האתר מהטלפון ברשת סלולרית ולא בוואי פיי. רוב הגולשים מגיעים משם, ורוב בעלי האתרים בודקים בוואי פיי מהיר במשרד. הפער בין שתי החוויות האלה הוא לפעמים כל ההסבר לפער בין תחושה טובה לדוח אדום.
מה שלא כדאי להסיק מבדיקה אחת: שהאתר תקין או שבור. הריצו את אותה בדיקה שלוש פעמים בשעות שונות. תוצאה שמשתנה מאוד בין הרצות מצביעה על עומס בשרת, ותוצאה יציבה וגרועה מצביעה על משהו קבוע בבנייה. ההבחנה הזאת לבדה מכוונת את הטיפול.
סימפטום, מקור, טיפול
| מה מרגישים | מקור סביר | מה מטפלים |
|---|---|---|
| כל דף לוקח שתי שניות להתחיל | שרת, PHP, מסד נתונים | אבחון שאילתות, מטמון, שדרוג סביבה |
| הניהול איטי אבל האתר סביר | תוספים שרצים בממשק | איתור התוסף וצמצום |
| התמונה הראשית מופיעה מאוחר | LCP | גודל תמונה, פורמט, סדר טעינה |
| לחיצה על תפריט לא מגיבה מיד | INP | צמצום סקריפטים חיצוניים |
| הכפתור זז בזמן שלוחצים | CLS | מידות לתמונות, שריון מקום |
| היה מהיר ופתאום זוחל | עדכון או תוסף חדש | בדיקת מה השתנה בשבוע האחרון |
השורה האחרונה שווה תשומת לב מיוחדת. כשאתר עבד מהר ופתאום נעשה איטי, כמעט תמיד יש אירוע שקדם לזה: עדכון, תוסף חדש, ייבוא תוכן גדול או שינוי באחסון. שאלה אחת למי שמתחזק את האתר חוסכת שעות אבחון.
באיזה סדר לטפל
הסדר משנה, כי טיפול בצד אחד לפעמים מסתיר את הצד השני. אני עובד כך:
קודם השרת. אין טעם לייעל תמונות כשהשרת מחזיר תשובה אחרי שתי שניות, כי המדדים יישארו אדומים בכל מקרה. אחרי שהתשובה מהירה, עוברים לתמונות ולגופנים, שהם הרווח הגדול ביותר ביחס למאמץ. רק בשלב השלישי נוגעים בסקריפטים חיצוניים, כי שם צריך להחליט מה מוותרים עליו, וזו החלטה עסקית ולא רק טכנית.
נקודה אחרונה על מדידה: אחרי כל שלב, מדדו שוב ותעדו. אתר שעבר חמישה שינויים במקביל ואז השתפר לא מלמד אתכם כלום על הפעם הבאה. אתר שעבר שינוי, נמדד, ואז עוד שינוי, מייצר ידע שנשאר אצלכם.
ולגבי ציפיות: לא כל אתר מגיע לירוק מלא, וזה בסדר. אתר עם חנות, צאט, מפה ושלושה כלי מדידה נושא משקל שלא ייעלם. המטרה הריאלית היא לצאת מהאדום ולהגיע למצב שהחוויה בפועל טובה, ולא לרדוף אחרי ציון מושלם שדורש לוותר על כלים שהעסק צריך.
מה עולה מה
המחיר אצלי לאבחון ולתיקון של אתר וורדפרס איטי הוא מ-₪650 לאבחון + תיקון, לפני מע״מ. זה מכסה את הזיהוי של מה גורם לאיטיות ואת הטיפול בשכבה שהתבררה כאשמה.
עבודה רחבה על המדדים עצמם, כלומר LCP, INP ו-CLS עד ציון ירוק, היא פרויקט אחר בהיקף אחר, ₪1,500-₪4,500 חד-פעמי לפני מע״מ. ואם מדובר בתקלה נקודתית ולא בהאטה כללית, מסך לבן, שגיאת PHP או תוסף שנשבר, זה נכנס תחת פתרון תקלות WordPress, ₪350-₪1,500 לתקלה · חבילת חירום ₪2,500, לפני מע״מ.
ועוד המלצה שחוסכת כסף לאורך זמן: אחרי שהאתר תוקן, בדקו אותו פעם ברבעון. מהירות אינה מצב קבוע, היא נשחקת עם כל תוסף חדש, כל באנר וכל שינוי תבנית. אתר שנבדק ברבעון נשאר במקום שאליו הגיע, ואתר שנבדק פעם בשנתיים חוזר בדיוק לנקודה שממנה התחיל.
מה שאני ממליץ לפני שמזמינים כל אחד מהשלושה: לענות על שלוש השאלות מהבדיקה העצמית. עם התשובות האלה אפשר להגיע להצעה מדויקת במקום להערכה כללית. שלחו לי את הכתובת של האתר ואת מה שראיתם, ואגיד לכם לאיזה צד זה נופל ומה הייתי מתקן ראשון במסגרת תיקון האתר האיטי. הכי מהיר דרך WhatsApp, או בטלפון 054-238-3789. דברו איתי בוואטסאפ ←
