אתר וורדפרס איטי הוא לא רק מטרד. הוא דליפה שקטה של מבקרים ושל כסף: לקוחות נוטשים לפני שהעמוד בכלל נטען, וגוגל מוריד אתרים איטיים בדירוג. החדשות הטובות הן שכמעט תמיד מדובר בכמה גורמים ספציפיים שאפשר לזהות ולתקן. המדריך הזה מסביר איך לאבחן מה מאט את האתר שלכם, ואיך מורידים זמן טעינה מסדר גודל של חמש שניות לחצי שנייה.
קודם כל: למה מהירות בכלל חשובה
מבקר שנכנס לאתר מצפה לראות תוכן כמעט מיד. ככל שהטעינה מתארכת, אחוז הנוטשים עולה בחדות, וזה נכון במיוחד בנייד, שם רוב התנועה מגיעה היום. מעבר לחוויית המשתמש, גוגל מודד את מהירות האתר דרך מדדי Core Web Vitals ומשתמש בהם כאות דירוג. אתר איטי מתחיל את המרוץ עם חיסרון כפול: פחות מבקרים נשארים, ופחות מבקרים בכלל מגיעים.
שלושת המדדים שגוגל בודק:
- LCP (זמן טעינת התוכן המרכזי) מודד תוך כמה זמן מופיע האלמנט הגדול בעמוד. יעד טוב: מתחת ל-2.5 שניות.
- INP (תגובתיות לאינטראקציה) מודד כמה מהר האתר מגיב ללחיצה או הקלדה. יעד טוב: מתחת ל-200 מילי-שנייה.
- CLS (יציבות ויזואלית) מודד כמה האלמנטים "קופצים" בזמן הטעינה. יעד טוב: מתחת ל-0.1.
הרחבנו על שלושת המדדים ועל איך מתקנים כל אחד מהם במדריך Core Web Vitals אדום.
ארבעת החשודים המיידיים
ברוב המכריע של האתרים האיטיים, האשם נמצא באחד מארבעה מקומות. כדאי לעבור עליהם בסדר הזה, מהמשפיע ביותר לפחות.
1. תמונות כבדות
זו הסיבה השכיחה ביותר, ולרוב גם הקלה ביותר לתיקון. בעלי אתרים מעלים תמונות ישירות מהמצלמה או מהבנק תמונות במשקל של 3 עד 8 מגה-בייט ליחידה, ווורדפרס מגיש אותן כמו שהן. עמוד עם חמש תמונות כאלה נאלץ למשוך עשרות מגה-בייט לפני שהמבקר רואה משהו.
הפתרון בנוי משלושה רבדים: כיווץ (דחיסת התמונות בלי לאבד איכות נראית), המרה לפורמט מודרני כמו WebP שמשקלו נמוך משמעותית מ-JPEG, וטעינה עצלה (lazy loading) שמושכת תמונות רק כשהמבקר גולל אליהן. לבד, השלב הזה לרוב חותך שניות מזמן הטעינה.
2. עומס תוספים
כל תוסף מוסיף קוד, בקשות לשרת ולעיתים שאילתות למסד הנתונים. אתר עם 40 תוספים, שחלקם חופפים בתפקיד וחלקם כבר לא בשימוש, נושא משקל מיותר בכל טעינת עמוד. במיוחד בעייתיים תוספי "עמוד בונה" (page builders) כבדים, תוספי סליידרים, ותוספים שטוענים ספריות עיצוב בכל עמוד גם כשהן נחוצות רק באחד.
האבחון פשוט: עוברים על רשימת התוספים, מזהים כפילויות ותוספים מתים, ובודקים בכלי מדידה אילו תוספים מזריקים הכי הרבה קוד. כל תוסף שאפשר להסיר או להחליף בפתרון קל יותר הוא ניצחון נקי.
3. אחסון חלש
זה הגורם שהכי הרבה בעלי אתרים מתעלמים ממנו. אחסון משותף וזול מארח מאות אתרים על אותו שרת, ובשעות עומס זמן התגובה של השרת (TTFB, הזמן עד הבייט הראשון) מזנק. אפשר לעשות את כל האופטימיזציות שבעולם, אבל אם השרת עצמה לוקח שנייה וחצי רק כדי להתחיל לענות, יש תקרה שלא תעברו.
סימן ההיכר: האתר איטי גם בעמודים פשוטים, וגם אחרי שכיווצתם תמונות. אם זה המצב, מעבר לאחסון איכותי או לשרת ייעודי הוא לעיתים השדרוג הכי משמעותי. עשינו את זה לא פעם בלי downtime, כפי שהסברנו בהעברת אתר וורדפרס לשרת חדש.
4. מסד נתונים מנופח
ככל שהאתר מתבגר, מסד הנתונים אוגר "שומן": גרסאות ישנות של פוסטים (revisions), פריטים בפח, תגובות ספאם, ונתונים זמניים (transients) שתוספים מותירים אחריהם. מסד נתונים נקי מגיב מהר יותר לכל שאילתה, וההשפעה מורגשת במיוחד באתרי תוכן גדולים ובחנויות.
איך מאבחנים נכון, לפי הסדר
לפני שנוגעים במשהו, מודדים. בלי מדידה לפני ואחרי אי אפשר לדעת אם תיקנתם או רק הזזתם בעיה.
- מריצים בדיקה ב-PageSpeed Insights של גוגל ובכלי כמו GTmetrix. שמים לב במיוחד ל-TTFB (מצביע על אחסון) ולמשקל העמוד הכולל (מצביע על תמונות ותוספים).
- בודקים את משקל העמוד. עמוד תקין שוקל בדרך כלל מתחת ל-2 מגה-בייט. אם הוא שוקל 8, התשובה כמעט תמיד תמונות.
- מודדים TTFB. מעל 600 מילי-שנייה מצביע על שרת איטי או על קוד כבד שרץ בכל טעינה.
- בודקים את רשימת התוספים ומזהים את הכבדים והמיותרים.
רק אחרי שיש תמונת אבחון, מתקנים. אחרת קל "להתקין תוסף קאשינג" ולקוות לטוב, בלי לגעת בבעיה האמיתית.
Case אמיתי: מ-5.4 שניות ל-0.6
אתר תדמית של עסק שירותים הגיע אלינו עם טעינה של מעל חמש שניות בנייד ושיעור נטישה גבוה. האבחון חשף את הסיפור המוכר: עמוד הבית שקל 11 מגה-בייט בגלל תמונות באנר לא דחוסות, רצו 38 תוספים שמתוכם כמה כפולים, ומסד הנתונים נשא אלפי revisions ו-transients ישנים.
הטיפול היה שיטתי: דחסנו והמרנו את כל התמונות ל-WebP עם טעינה עצלה (משקל העמוד ירד מ-11 ל-1.8 מגה-בייט), הסרנו 14 תוספים מיותרים, ניקינו את מסד הנתונים, והוספנו שכבת קאשינג מתאימה. בלי לגעת באחסון, זמן הטעינה ירד ל-0.6 שניות וכל שלושת מדדי Core Web Vitals עברו לירוק. מאמר רוחב על הגישה הכוללת שלנו נמצא בהאצת אתרים.
כשהאתר הוא חנות
חנות WooCommerce היא מקרה מורכב יותר. עמוד מוצר וצ'קאאוט אינם ניתנים לקאשינג מלא כמו עמוד תדמית, כי הם דינמיים, וכל שאילתה מיותרת מורגשת ישירות בשורה התחתונה. אם זה המצב שלכם, כתבנו מדריך ייעודי לWooCommerce איטי בעמוד מוצר וצ'קאאוט.
מהירות היא לא פרויקט חד-פעמי
הנקודה החשובה ביותר: אתר מהיר נשאר מהיר רק אם שומרים עליו. תמונות חדשות נכנסות, תוספים מתעדכנים ולעיתים מאטים, ומסד הנתונים מתנפח שוב. בלי תחזוקה שוטפת, אתר שאיצנו חוזר תוך חודשים להיות איטי.
בחבילת אחריות 360 של OCW, פילר התחזוקה הטכנית כולל ניטור ביצועים שוטף, ניקוי מסד נתונים תקופתי, ושמירה על האתר מהיר לאורך זמן, לצד שלושת הפילרים הנוספים: אבטחה, נגישות ופרטיות. אם האתר שלכם איטי ואתם רוצים אבחון מסודר ותוכנית תיקון, דברו איתנו ונבדוק מה בדיוק מאט אותו.
שאלות נפוצות
למה האתר שלי איטי רק בנייד?
ברוב המקרים בגלל תמונות כבדות ו-JavaScript של תוספים. מכשירי נייד חלשים יותר ומחוברים לרשת איטית יותר ממחשב, ולכן כל קילו-בייט מיותר מורגש שם הרבה יותר. דחיסת תמונות וצמצום תוספים הם הצעד הראשון.
האם תוסף קאשינג לבדו יפתור את הבעיה?
לא תמיד. קאשינג עוזר מאוד, אבל הוא לא מתקן תמונות של 8 מגה-בייט, לא מנקה מסד נתונים מנופח ולא משדרג שרת חלש. הוא רובד אחד מתוך כמה, לא קסם.
כמה מהר באמת אפשר לצפות שהאתר ייטען?
אתר תדמית מותאם היטב יכול להגיע לזמן טעינה מתחת לשנייה. חנות דינמית תהיה מעט איטית יותר מטבעה, אבל גם שם אפשר להגיע לטווח של שנייה עד שתיים בעמודים המרכזיים.
האם שיפור מהירות ישפר לי את הדירוג בגוגל?
מהירות היא אחד מאותות הדירוג, לא היחיד. שיפור משמעותי במדדי Core Web Vitals עוזר, במיוחד כשמתחרים עליכם קרובים, אבל הוא פועל לצד תוכן איכותי וקישורים, לא במקומם.