בקצרה: אתרי WordPress איטיים נובעים לרוב מאותם גורמים — תמונות כבדות, תוספים מיותרים, אחסון שאינו מתאים, תבנית עמוסה, סקריפטים חיצוניים והיעדר קאש. ברוב המקרים אפשר להגיע לשיפור משמעותי בלי לבנות את האתר מחדש.
אתר איטי מקשה על המבקרים ועלול לגרום להם לעזוב לפני שהגיעו למידע החשוב. הבעיה היא שרוב בעלי האתרים לא יודעים למה האתר שלהם איטי, ומקבלים תשובות מעורפלות בסגנון "צריך לעשות אופטימיזציה".
במדריך הזה נפרק את הגורמים הנפוצים, נסביר איך לקרוא נכון את תוצאות הבדיקה, ונראה מה כדאי לבדוק לפני שמשקיעים כסף.
קודם כול — איך קוראים נכון בדיקת מהירות
הכלי המקובל הוא PageSpeed Insights של גוגל, וחשוב להבין שהוא מציג שני סוגי נתונים שונים לגמרי:
- נתוני מעבדה (Lab): נוצרים בבדיקה מדומה של Lighthouse בסביבה מבוקרת. מכאן מגיע ציון ה־Performance שבין 0 ל־100. נתוני המעבדה שימושיים במיוחד לאיתור תקלות ולהשוואת שינויים לפני ואחרי, כל עוד משווים באותו כלי ובאותו סוג בדיקה. גם כאן ייתכנו הבדלים מסוימים בין הרצות.
- נתוני שטח (Field): מגיעים ממשתמשים אמיתיים דרך דוח CrUX של גוגל, כשיש מספיק תנועה כדי לאסוף אותם. על נתוני השטח מבוססת הערכת Core Web Vitals — כלומר האם האתר "עובר" את המדדים.
ההבחנה הזו חשובה: ציון Performance גבוה אינו זהה למעבר Core Web Vitals, ואפשר בהחלט שאתר יקבל ציון מעבדה יפה בזמן שהמשתמשים בשטח חווים משהו אחר — או להפך.
שלושת המדדים עצמם: LCP — כמה זמן עד שהתוכן המרכזי נראה על המסך. CLS — כמה העמוד "קופץ" בזמן הטעינה (תמונה בלי מידות מוגדרות תדחוף את הטקסט למטה). INP — כמה מהר האתר מגיב ללחיצה או להקלדה.
בבדיקות המעבדה של PageSpeed, ציון הנייד נמוך לעיתים קרובות מציון הדסקטופ, משום שהבדיקה מדמה מכשיר וחיבור מוגבלים יותר. הציון עשוי גם להשתנות בין בדיקות, ולכן חשוב לבחון את המדדים ולא רק מספר בודד.
הגורמים הנפוצים שמאטים אתרי WordPress
הסדר כאן אינו סדר השפעה קבוע — הוא משתנה מאתר לאתר. באתר אחד התמונות יהיו החלק הכבד, ובאחר דווקא השרת או הסקריפטים החיצוניים.
תמונות שלא הותאמו לתצוגה
באתרים רבים התמונות הן מהמשאבים הכבדים ביותר בעמוד. לדוגמה, תמונה ברוחב 4,000 פיקסלים ובמשקל של כמה מגה־בייט עשויה להיטען גם כשהיא מוצגת בפועל ברוחב קטן בהרבה.
מה עושים: מקטינים את התמונות לגודל שבו הן באמת מוצגות, שומרים בפורמט מודרני כמו WebP, מגדירים לכל תמונה רוחב וגובה בקוד (זה מונע קפיצות ומשפר CLS), וטוענים בעצלתיים את מה שנמצא מתחת לקו הגלילה.
תוספים כבדים, כפולים או לא נחוצים
כל תוסף מוסיף קוד שרץ בטעינה, ולעיתים גם קובצי CSS ו־JavaScript משלו בכל עמוד באתר — גם כשהוא רלוונטי רק לעמוד אחד. מספר התוספים לבדו אינו קובע את מהירות האתר: אתר עם 30 תוספים קלים יכול להיות מהיר, ואתר עם 8 תוספים כבדים יכול להיות איטי. מה שקובע הוא מה כל תוסף עושה ומה הוא טוען.
מה עושים: מוחקים תוספים שאינם בשימוש (לא מספיק לכבות), מאתרים שני תוספים שעושים את אותו דבר, ומחליפים תוספים כבדים בפתרון קל יותר. בונוס: פחות תוספים זה גם פחות משטח לתקיפה ופחות עדכונים לתחזק.
אחסון או שרת שאינם מתאימים לאתר
זה הגורם שהכי קשה לראות מבחוץ. באחסון משותף עמוס המשאבים מתחלקים בין אתרים רבים, וגם אתר מוקפד ימתין. הסימן המובהק הוא זמן תגובת שרת ארוך — הדפדפן ממתין לפני שהוא בכלל מתחיל לקבל תוכן. המחיר לבדו אינו מדד: מה שחשוב הוא התאמת המשאבים לסוג האתר ולנפח התנועה שלו.
מה עושים: בודקים את זמן תגובת השרת בדוח. אם הוא נשאר גבוה גם אחרי הקטנת תמונות וניקוי תוספים — הבעיה בשרת, ואופטימיזציה בצד הקוד לא תפצה עליה. גם גרסת PHP ישנה משפיעה, וזה שינוי פשוט אצל רוב ספקי האחסון.
תבנית, בונה עמודים או קוד שמעמיסים משאבים
תבניות "רב־תכליתיות" מביאות איתן קוד נרחב שנטען גם כשמשתמשים בחלק קטן ממנו, ובוני עמודים ויזואליים מוסיפים שכבות HTML ומחוללים דפים עם יותר קוד מהנדרש. זה לא אומר שאסור להשתמש בהם — אבל המחיר בביצועים אמיתי וכדאי להכיר אותו מראש.
מה עושים: מבטלים טעינה של רכיבים שאינם בשימוש, מצמצמים את מספר משפחות הגופנים והמשקלים, ומוותרים על אנימציות שאינן תורמות. באתר חדש — בוחרים בסיס נקי מלכתחילה.
סקריפטים חיצוניים, הטמעות וגופנים
כלי פרסום ומעקב, צ'אט, מפות, סרטונים מוטמעים, גופנים ושירותי צד שלישי יכולים להוסיף בקשות רשת, JavaScript וזמן טעינה — לעיתים יותר מכל שאר האתר יחד. כל שירות כזה נטען משרת אחר, ולכם אין שליטה על מהירותו.
מה עושים: בודקים אילו כלים באמת בשימוש ומסירים את השאר, טוענים סרטונים רק בלחיצה במקום אוטומטית, מארחים גופנים באופן מקומי, ומגבילים את מספר קודי המעקב.
היעדר קאש
בלי מנגנון קאש, וורדפרס בונה כל עמוד מחדש בכל כניסה: שאילתות לבסיס הנתונים, הרצת קוד וייצור HTML. קאש שומר את התוצאה המוכנה ומגיש אותה מיד, ולרוב זה השיפור הגדול ביותר ביחס למאמץ.
שימו לב: קאש דורש הגדרה נכונה. עמודים דינמיים — עגלת קניות, אזור אישי, טפסים עם אימות — צריכים להיות מוחרגים, אחרת נוצרות תקלות שקשה לאתר.
דוגמאות ממדידות שביצענו
| האתר | לפני | אחרי | סוג הבדיקה | תאריך |
|---|---|---|---|---|
| אתר "תיקון גורל" | 60 | 97 | PageSpeed Insights — דסקטופ | 13.2.2024 |
| חנות אוזניות (סביבת פיתוח) | 62 | 99 | PageSpeed Insights — דסקטופ | 14.2.2024 |
| חנות ציוד כושר | 70 | 93 | PageSpeed Insights — דסקטופ | 12.7.2023 |
אלה מדידות מעבדה היסטוריות שבוצעו בנקודת זמן מסוימת. הן אינן מבטיחות תוצאה דומה בכל אתר, והציונים עשויים להשתנות בעקבות שינויים באתר, באחסון ובתנאי הבדיקה.
באתר "תיקון גורל", LCP בבדיקת המעבדה של PageSpeed Insights ירד מ־5.3 ל־1.2 שניות. הצילומים המלאים מוצגים בעמוד שיפור מהירות וביצועים לאתרי WordPress.
העבודות בוצעו על ידי יוסף סעדה בתקופת עבודתו בהופה פתרונות טכנולוגיים ומוצגות באישור החברה.
סדר הפעולות שאנחנו ממליצים עליו
- מדדו לפני שנוגעים. בלי מדידת בסיס אי אפשר לדעת אם משהו עזר.
- תמונות. לרוב הזול והמשמעותי ביותר.
- קאש. שיפור גדול במאמץ קטן.
- ניקוי תוספים וסקריפטים חיצוניים. משפר גם אבטחה ותחזוקה.
- בדקו את השרת. אם זמן התגובה עדיין גבוה — הבעיה באחסון.
- מדדו שוב, באותו כלי ובאותו סוג מכשיר, והשוו גם לנתוני השטח אם יש.
מתי אופטימיזציה כבר לא מספיקה
לפעמים הבעיה אינה בהגדרות אלא בבסיס: תבנית ישנה שאינה נתמכת, בונה עמודים שמייצר קוד כבד בכל עמוד, או אתר שנבנה לפני שנים רבות ונטלא מאז עשרות פעמים. במצבים כאלה אפשר לשפר במידה מסוימת, אבל התקרה נמוכה. אם האתר גם נראה מיושן וגם איטי, לרוב שדרוג ועיצוב מחדש יהיה משתלם יותר מרדיפה אחרי נקודות ביצועים.
שורה תחתונה
ברוב האתרים האיטיים אין תעלומה — יש תמונות כבדות, תוספים מיותרים, סקריפטים חיצוניים, אחסון שאינו מתאים ואין קאש. הסדר שלמעלה פותר את רוב המקרים בלי לבנות מחדש. רוצים לדעת מה מאט דווקא את האתר שלכם? שלחו לנו את הכתובת ונחזור אליכם עם הממצאים המרכזיים.
שאלות נפוצות
איזה ציון נחשב טוב?
Lighthouse מגדיר ציון 90 ומעלה כטוב. בנייד לעיתים קשה יותר להגיע אליו בגלל תנאי הבדיקה המחמירים, אבל לא נכון להסתכל רק על המספר. חשוב לבדוק גם את זמני הטעינה, את Core Web Vitals של משתמשים אמיתיים ואת השיפור ביחס למצב ההתחלתי.
למה הציון בנייד נמוך מהדסקטופ?
מפני שבדיקת המעבדה בנייד מדמה מכשיר וחיבור מוגבלים יותר, בזמן שבדיקת הדסקטופ מניחה תנאים חזקים יותר. זה פער צפוי ולא בהכרח סימן לתקלה — רק ודאו שאתם משווים בדיקות מאותו סוג.
מהירות משפיעה על הדירוג בגוגל?
Core Web Vitals משמשים את מערכות הדירוג של Google כחלק ממכלול רחב יותר של אותות. ביצועים טובים יכולים לתרום לחוויית המשתמש ולהצלחה בחיפוש, אבל ציון גבוה אינו מבטיח מיקום גבוה, ואין צורך לרדוף אחרי ציון 100.
כמה זמן לוקח לשפר אתר קיים?
תלוי במצב הפתיחה, בגודל האתר ובגורם שמאט אותו. באתר קטן חלק מהשיפורים יכולים להיות יחסית נקודתיים, בעוד שאתרים גדולים, חנויות או מקרים שדורשים טיפול בתבנית, בקוד או באחסון מצריכים עבודה רחבה יותר. לכן נכון לאמוד את היקף העבודה רק לאחר בדיקה ראשונית.