תוכן העניינים
אם יש לכם אתר אלמנטור איטי, לא תמיד ברור מה השתנה. בניתם אותו, הוא נראה טוב, ובהתחלה גם רץ מהר. ואז, בלי שקרה משהו דרמטי, הוא סתם נהיה איטי. הדף נטען לאט, העריכה מקרטעת, ואתם לא בטוחים אם הבעיה היא אלמנטור עצמו, משהו שהצטבר באתר, או שפשוט הגיע הזמן להתחיל הכול מחדש.
התשובה הקצרה: כמעט תמיד אפשר לתקן את זה בלי לבנות מחדש. אלמנטור לא "איטי מטבעו" – אבל אתר שנבנה איתו יכול לצבור עם הזמן שכבות, תוספים ומשאבים מיותרים, ורוב המשקל הזה אפשר לאתר ולהוריד בלי לגעת בעיצוב. בואו נעבור על זה בסדר הנכון: מה קורה בפועל, מה לבדוק, ומה לתקן קודם.
עיקרי הדברים
-
- אתר אלמנטור לא נהיה איטי "סתם" – כמעט תמיד יש שילוב של גורמים ספציפיים שאפשר לאתר.
- יש הבדל בין עורך אלמנטור שמקרטע (בעיה שלכם, בעריכה) לבין האתר שאיטי אצל מבקרים (בעיה שהם חווים).
- לפני שמתקנים – בודקים. תיקון בלי אבחון הוא ניחוש.
- רוב התיקונים היעילים ביותר לא קשורים לעיצוב ולא דורשים לבנות מחדש.
- בנייה מחדש נדרשת רק במקרים נדירים, לא כברירת מחדל.
שני דברים שונים שקוראים להם "אלמנטור איטי"
כשמישהו אומר לי "האתר שלי איטי", לרוב מתברר שיש כאן אחת משתי בעיות שונות, ולפעמים שתיהן ביחד.
עורך אלמנטור מול העמוד המתפרסם העורך של אלמנטור (המסך שבו אתם בונים ועורכים את העמודים) הוא כלי כבד בפני עצמו – הוא טוען המון סקריפטים כדי לאפשר לכם גרירה ועריכה חיה. איטיות שם משפיעה רק עליכם, בזמן העבודה. העמוד שמתפרסם באתר, לעומת זאת, אמור להיות הרבה יותר קליל – וזו האיטיות שהמבקרים בפועל חווים.
הבלבול הנפוץ הוא לחשוב שאם העריכה איטית, גם האתר עצמו איטי – וזה לא בהכרח נכון. אפשר לעבוד עם עורך שמקרטע קצת ועדיין לפרסם עמוד שנטען מהר, וגם ההפך. חשוב להבחין ביניהם כי הפתרון לכל אחד שונה, וזה חוסך לכם לתקן דברים שלא קשורים לבעיה שהמבקרים שלכם חווים בפועל.
קודם בודקים, אחר כך מתקנים
לפני שנוגעים בכל תיקון – כדאי לדעת בדיוק כמה איטי האתר, ואיפה בדיוק זה קורה. בלי זה, אתם עלולים להשקיע זמן בתיקון שלא באמת נוגע בבעיה.
הכלי הסטנדרטי לזה הוא PageSpeed Insights של גוגל, שמציג את מדדי Core Web Vitals – למשל כמה זמן לוקח לתוכן העיקרי בעמוד להיטען (LCP) – וגם מדדי אבחון נוספים כמו TTFB (הזמן שלוקח לשרת להתחיל להגיב). TTFB עצמו הוא לא אחד ממדדי ה-Core Web Vitals, אבל הוא כלי אבחון שימושי: TTFB גבוה יכול לרמוז על בעיה בשרת, בקאש, או במסד הנתונים – לא בהכרח שהאחסון עצמו גרוע. אם כבר עברתן את השלב הזה ואתן רק צריכות לדעת איך לקרוא את התוצאה ולהבין אם הבעיה בשרת או בעמוד עצמו, כתבתי על זה מדריך המלא לבדיקת מהירות אתר וורדפרס שמתמקד בדיוק בזה. כאן נתמקד בסיבות שספציפיות לאתרי אלמנטור.
מה באמת גורם לאתר אלמנטור איטי
מהניסיון שלי, ברוב האתרים שנבנו באלמנטור הבעיה היא לא "משהו אחד גדול" אלא כמה גורמים קטנים שהצטברו יחד. הסדר הבא הוא סדר עדיפויות: מתחילים למעלה, ורק אם זה לא מספיק ממשיכים למטה.
קודם כול: התיקונים המהירים והבטוחים
אלה שינויים שכמעט תמיד שווה לבדוק קודם, כי הם זולים, מהירים, ולא נוגעים בעיצוב:
- תמונות לא מותאמות. תמונה שהועלתה ישירות מהטלפון או מהמצלמה בלי דחיסה יכולה לשקול פי כמה מהנדרש. בדוח של PageSpeed Insights (מהשלב הקודם) יש בדרך כלל רשימה מפורשת של התמונות הכי כבדות בעמוד – זו נקודת ההתחלה. דחסו אותן (אפשר בתוסף דחיסה, או לפני ההעלאה בכל כלי עריכת תמונות) והעלו אותן בגודל שבאמת מוצג באתר, לא בגודל המקורי של המצלמה. זו כנראה התוצאה הכי משתלמת ביחס למאמץ.
- תוספים (plugins) שלא בשימוש. תוסף פעיל יכול להוסיף קוד, שאילתות או קבצים לטעינה – אבל ההשפעה משתנה מאוד מתוסף לתוסף. לכן שווה לזהות תוספים שאין בהם צורך: כבו אחד בכל פעם (רצוי בשעות שקטות) ובדקו אם משהו נשבר או אם הביצועים משתפרים. תוסף שאתם לא זוכרים למה הוא שם, ושהכיבוי שלו לא שינה כלום – כנראה אפשר להסיר.
- אלמנטים ו-widgets שלא רואים בפועל. סקשנים ואלמנטים חבויים – פופאפים כפולים, ווידג'טים ישנים שהוחלפו אבל לא נמחקו – עדיין יכולים להישאר במבנה העמוד ולהוסיף DOM ומשאבים מיותרים, בהתאם לאופן שבו הם בנויים. עדיף למחוק רכיבים שכבר לא בשימוש, לא רק להסתיר אותם. בעורך אלמנטור יש פאנל בשם Navigator שמציג את כל הסקשנים והאלמנטים בעמוד, כולל המוסתרים – מעבר עליו הוא תיקון של כמה דקות.
- הגדרות ביצועים מובנות באלמנטור שלא כולם יודעים שקיימות. מתחת ל-Elementor ← Settings בלוח הבקרה יש כמה הגדרות אמיתיות שנועדו בדיוק לזה – לצמצם קוד מיותר בלי לגעת בעיצוב. הטבלה הבאה מפרטת אותן.
הגדרות שכדאי לבדוק תחת Elementor ← Settings
| הגדרה | איפה נמצאת | מה עושים | מה זה עשוי להשפיע |
|---|---|---|---|
| Google Fonts | לשונית Advanced | לכבות, אבל רק אם אין באתר שום שימוש בפונטים מגוגל (למשל כשכל הפונטים מותאמים אישית או מועלים ישירות) | כל טקסט שמוגדר לפונט מגוגל יחזור לפונט ברירת המחדל של הדפדפן – חובה לעבור על העמודים אחרי הכיבוי ולוודא שהטקסט עדיין נראה טוב |
| Load Google Fonts Locally | לשונית Performance | להפעיל | הפונטים נטענים מהשרת שלכם במקום משרתי גוגל – טעינה מהירה יותר ופחות בקשות לשרת חיצוני, כמעט בלי סיכון חזותי |
| Optimized Gutenberg Loading | לשונית Performance | בדרך כלל אפשר להפעיל | אלמנטור נמנע מטעינת קבצי Gutenberg שלא נדרשים. אחרי ההפעלה, בדקו עמודים שבכל זאת משתמשים בבלוקים |
| Optimized Image Loading | לשונית Performance | להפעיל | אלמנטור נותן עדיפות טעינה לתמונה המרכזית, ומפעיל lazy loading רק במקומות שבהם זה מועיל – לא בתמונות שמופיעות מיד במסך הראשון. כמעט תמיד בטוח ומומלץ |
| Lazy Load Background Images | לשונית Performance | להפעיל | תמונות רקע (חוץ מהראשונה בעמוד) ייטענו רק בגלילה. אחרי ההפעלה, עברו על העמודים המרכזיים וודאו שתמונות הרקע מופיעות כרגיל |
| CSS Print Method | לשונית Advanced | בדרך כלל להשאיר על "External File" | זו ברירת המחדל המומלצת של אלמנטור. "Internal Embedding" משמש לפעמים לפתרון בעיות CSS או הבהוב עיצוב אחרי מעבר דומיין – אם ההגדרה שונתה בעבר, שווה להבין למה לפני שמחזירים אותה |
השמות והמיקומים המדויקים יכולים להשתנות מעט בין גרסאות אלמנטור (אצלכם זה עשוי להופיע גם תחת Elementor ← Editor ← Settings) – אם משהו נראה קצת אחרת, זה בסדר, הרעיון הכללי (לכבות מה שלא בשימוש, ולהעדיף טעינה מקומית/עצלה איפה שאפשר) נשאר תקף.
אחר כך: הרגלי בנייה שכדאי לתקן
אם התיקונים המהירים לא הספיקו, לרוב הבעיה היא בדרך שבה העמודים נבנו – לא באלמנטור עצמו:
- קינון מיותר של קונטיינרים. קינון בפני עצמו נורמלי ונתמך באלמנטור – הבעיה היא קינון מיותר: קונטיינר בתוך קונטיינר בלי הצדקה עיצובית מגדיל את ה-DOM (מבנה הקוד שהדפדפן מעבד) בלי תועלת. אלמנטור עצמו ממליץ על כמה שפחות רמות קינון. פאנל ה-Navigator מראה כמה רמות עומק יש לעמוד. בעמודים הכבדים ביותר, לפעמים משתלם לבנות מחדש רק אותם עם מבנה ה-Container של אלמנטור, שמחליף את הסקשנים והעמודות הישנות ומייצר בדרך כלל DOM קטן יותר.
- אנימציות ואפקטי גלילה רבים. הם מוסיפים עבודה לדפדפן ועלולים לפגוע בתחושת החלקות, במיוחד במכשירים חלשים – אבל אנימציית כניסה בודדת בדרך כלל לא הופכת עמוד לאיטי מהותית. אם יש הרבה מהן, שווה להתחיל מהאלמנטים המורכבים שנמצאים כבר במסך הראשון. אפשר לכבות אנימציית כניסה לכל אלמנט בנפרד, תחת הלשונית Advanced ← Motion Effects שלו.
- פונטים מרובים. כל משפחת פונט נוספת מוסיפה עוד קבצי פונט שהדפדפן צריך לטעון. אם הפונטים נטענים ישירות מגוגל (ולא הופעלה טעינה מקומית, כמו בטבלה למעלה), זה גם מוסיף בקשות לשרת חיצוני. בהגדרות האתר (Site Settings) יש בדרך כלל מסך שמרכז את כל הפונטים הגלובליים בשימוש – מעבר עליו ואיחוד פונטים כפולים לוקח כמה דקות. משפחת פונט אחת או שתיים בדרך כלל מספיקות לרוב האתרים.
הנקודה החשובה באמת: ברוב המקרים, שתי הקטגוריות האלה – תיקונים מהירים והרגלי בנייה – פותרות את רוב הבעיה, בלי לגעת בעיצוב ובלי לבנות שום דבר מחדש. זה בדיוק המקום שבו רוב האתרים שאני בודק מתייעלים משמעותית.
רק אם זה עדיין לא מספיק: אחסון וקאשינג
אם עברתם על שתי הקטגוריות הקודמות והאתר עדיין איטי, שווה לבדוק את התשתית:
- איכות האחסון (hosting). שרת חלש או עמוס גורם לזמן תגובה איטי לכל בקשה, עוד לפני שהדפדפן מתחיל לטעון תוכן. TTFB גבוה יכול לרמוז על זה – אבל כמו שהוזכר קודם, הוא לא מוכיח שהאחסון עצמו הבעיה, כי קאש לא מוגדר נכון או מסד נתונים עמוס יכולים לגרום לאותה תסמונת. אם בדקתם קאש ותוספים וה-TTFB עדיין גבוה בעקביות, זה הזמן לדבר עם חברת האחסון.
- שכבת קאשינג (cache). בלי קאש של העמוד, בקשות רבות דורשות מוורדפרס להריץ PHP ולשלוף נתונים לפני שהעמוד נשלח למבקר. תוסף קאש (יש כמה טובים ברמות מחיר שונות, כולל אופציות חינמיות) שומר גרסה מוכנה ומגיש אותה ישר, וזה יכול לצמצם משמעותית את זמן הטעינה. חשוב לבדוק את האתר אחרי ההפעלה – קאש שמוגדר לא נכון יכול להציג לביקורים גרסה ישנה של העמוד.
אלה שכבות חשובות, אבל לפני שמשדרגים אחסון או מוסיפים עוד פתרון אופטימיזציה, כדאי לוודא שהבעיה באמת נמצאת שם – קאשינג בפרט הוא לרוב מהשינויים הזולים והמהירים ביותר להטמיע, ולא בהכרח "היקר" מבין השלושה.
אז האם צריך לבנות את האתר מחדש?
ברוב המקרים – לא. אם עברתם על שלוש הקטגוריות למעלה ותיקנתם בהדרגה, לרוב תראו שיפור משמעותי בלי לגעת בעיצוב או במבנה העמודים.
יש מקרים חריגים שבהם בנייה מחדש כן הגיונית: אתר ישן מאוד, עם ערמת תוספי הרחבה כבדים שהצטברו זה על גבי זה, ושאף אחת מהשכבות שלמעלה לא מספיקה לתקן. זה קורה, אבל זה לא ברירת המחדל – וכדאי לחשוד בכל המלצה לבנייה מחדש שלא קדם לה אבחון ממשי.
מתי כדאי לפנות למפתח
חלק מהתיקונים למעלה – דחיסת תמונות, מחיקת תוספים, בחירת תוסף קאש – אפשר לעשות לבד גם בלי רקע טכני. אחרים, כמו זיהוי בעיות בקוד או החלטה על שדרוג אחסון, דורשים יותר ניסיון כדי לא לשבור דבר אחד בזמן שמתקנים דבר אחר.
אם בדקתן, תיקנתן את מה שיכולתן לבד, והאתר עדיין לא מספיק מהיר – זה הזמן לפנות למישהו שיעשה אבחון מסודר במקום לנחש. אני מציע את זה כחלק מהעבודה שלי סביב ביצועים ו-SEO טכני, ותמיד אחרי בדיקה אמיתית, לא כתירוץ למכור שדרוג.
שאלות נפוצות
האם אלמנטור עצמו הוא הבעיה, או משהו שעשיתי בבנייה?
ברוב המקרים – הבנייה, לא הכלי עצמו. אלמנטור מקל מאוד להוסיף עוד שכבות, תוספים, קינון מיותר ואפקטים – ולכן אתר שלא מתחזקים לאורך זמן יכול לצבור משקל. אתר אלמנטור בנוי בזהירות יכול לרוץ מהר לגמרי.
האם עדיף לעבור לעורך עמודים אחר כדי שהאתר יהיה מהיר?
לרוב לא נדרש. מעבר לעורך אחר הוא פרויקט משמעותי בפני עצמו, ובמקרים רבים אותם גורמי איטיות (תמונות, תוספים, קאשינג) יחזרו גם בעורך החדש אם לא מטפלים בהם ישירות.
כמה תוספים זה יותר מדי לאתר אלמנטור?
אין מספר קבוע – זה תלוי במה כל תוסף עושה ובאיכות הכתיבה שלו. השאלה הרלוונטית היא לא "כמה" אלא "כמה מהם באמת בשימוש כרגע". תוסף איכותי שבשימוש עדיף על שלושה תוספים בינוניים שלא.
האם אחסון יקר יותר פותר את הבעיה?
לפעמים כן, אבל זה לרוב לא הצעד הראשון. אם לא בדקתם קודם תמונות, תוספים והרגלי בנייה, שדרוג אחסון עלול לטשטש בעיה במקום לפתור אותה.
לסיכום
אתר אלמנטור איטי הוא כמעט תמיד סימן שמשהו הצטבר עם הזמן – לא פסק דין על הכלי או על העיצוב שלכם. הדרך הכי יעילה להתמודד עם זה: לבדוק לפני שמתקנים, ואז לעבוד בסדר הנכון – קודם התיקונים המהירים, אחר כך הרגלי הבנייה, ורק בסוף התשתית. ברוב הפעמים תגלו שבנייה מחדש פשוט לא היתה נחוצה.
שלחו לי את כתובת האתר ואחזור עם אבחון ראשוני – דברו איתי.