ביצועי אלמנטור: תקנו את הבעיות האמיתיות, לא רק את הסימפטומים

למה אתרי אלמנטור נעשים איטיים?

אלמנטור בונה עמודים מאלמנטי div שמקוננים זה בתוך זה. בפריסות ישנות שבנויות מ-Sections, מ-Columns ומ-Inner Sections, כרטיס או כפתור בודד יכולים לשבת בתוך שכבות רבות של עטיפות. ככל שה-DOM גדול יותר, הדפדפן עובד קשה יותר בכל חישוב של סגנונות ופריסה, והעמוד מוצג מאוחר יותר. בעמוד קצר זה לא מורגש; בעמוד ארוך עם עשרות סקשנים — מאוד.

האשם השני הוא JavaScript. גרסאות עדכניות של אלמנטור טוענות את הסקריפטים של ווידג'ט רק בעמודים שמשתמשים בו, אבל כל סוג ווידג'ט בעמוד עדיין מביא איתו סקריפט משלו: סליידר, גלריה, טופס, מונה, פופאפ. חבילות הרחבה של צד שלישי גרועות יותר לא פעם — רבות מהן טוענות את הקבצים שלהן בכל האתר, בין אם העמוד משתמש בהן ובין אם לא.

ושלישית: סגנונות שנכתבים בתוך העמוד. בהתאם להגדרת CSS Print Method, אלמנטור כותב את הסגנונות שהוא מייצר לכל עמוד לתוך בלוק <style> בתוך ה-HTML, במקום לקובץ נפרד. ה-HTML נעשה כבד יותר, והדפדפן לא יכול לשלוף את הסגנונות האלה מהמטמון בעמוד הבא.

איך מקטינים את עומק ה-DOM בלי לשבור את הפריסה?

אלמנטור לא ישטח בשבילכם פריסה קיימת, אבל אפשר לבדוק אותה. פתחו את Chrome DevTools (Ctrl+Shift+I, לשונית Elements) בעמוד הכבד ביותר באתר וחפשו עטיפות בתוך עטיפות שלא מוסיפות שום דבר נראה. אם האתר עדיין בנוי מ-Sections ומ-Columns, העבירו את הפריסות ל-Flexbox Containers, וכך יורדות שכבות עטיפה מכל בלוק. לכל סקשן ישן יש באלמנטור אפשרות Convert תחת Layout; היא יוצרת עותק בקונטיינר מתחת לסקשן המקורי, אז השוו בין השניים, תקנו ריווחים שזזו, ומחקו את הסקשן הישן.

בסקשנים שאתם בונים בעצמכם, הסתפקו בקונטיינר אחד לכל בלוק עם הגדרות Flexbox או Grid, במקום קונטיינרים שמקוננים שלוש רמות לעומק. מחקו אלמנטים של רווח ועטיפה שקיימים רק כדי ליצור שוליים — padding ו-gap על הקונטיינר עושים את אותה עבודה עם פחות קוד.

כבו ווידג'טים וחבילות הרחבה שאינכם משתמשים בהם

באלמנטור יש Element Manager (בתפריט הניהול של אלמנטור) שמציג את כל הווידג'טים, יודע לסרוק כמה פעמים כל אחד מהם בשימוש, ומאפשר לכבות את אלה שאף פעם לא נוגעים בהם. ווידג'ט כבוי נעלם מחלונית העורך, כך שהעורך נעשה קל יותר ואף אחד בצוות לא מוסיף אותו בטעות. באתר עצמו אל תצפו להרבה: לפי התיעוד של אלמנטור, הווידג'טים המובנים שלו טוענים את הקבצים שלהם רק בעמודים שמשתמשים בהם. בדקו את נתוני השימוש לפני שאתם מכבים משהו.

הרווח הגדול יותר מגיע בדרך כלל מחבילות ההרחבה. אם התקנתם חבילה בשביל שני ווידג'טים, חפשו בהגדרות שלה אפשרות לכבות ווידג'טים בודדים או לטעון אותם רק כשצריך — האפשרויות האלה כבויות לא פעם כברירת מחדל, וצריך להפעיל אותן. אם אין כאלה, בנו מחדש את שני הווידג'טים והסירו את החבילה.

בדקו והוציאו את ה-CSS המוטבע לקובץ חיצוני

ב-Elementor > Settings > Performance, העבירו את CSS Print Method ל-External File. מעכשיו אלמנטור כותב את הסגנונות של כל עמוד לקובץ נפרד שהדפדפן שומר במטמון בין ביקורים, במקום להוריד אותם שוב בתוך ה-HTML של כל עמוד. אם יש באתר תוסף מטמון, נקו את המטמון שלו אחרי השינוי.

אם עדיין נטענים בעמוד קובצי סגנון וסקריפטים שהוא לא צריך, תוסף כמו Asset CleanUp או Perfmatters מאפשר לבטל את טעינתם עמוד אחר עמוד. בדקו כל שינוי קודם על עותק staging — ביטול של הקובץ הלא נכון שובר את העיצוב.

בדקו ומדדו תוצאות אמיתיות

לפני ואחרי כל שינוי, הריצו Google PageSpeed Insights (https://pagespeed.web.dev/) ובדקו את שלושת מדדי Core Web Vitals: LCP, INP ו-CLS. מדד INP (Interaction to Next Paint) החליף את FID כחלק מ-Core Web Vitals ב-12 במרץ 2024. נתונים של גולשים אמיתיים חשובים יותר מציון המעבדה: PageSpeed Insights מציג אותם בראש הדוח כש-Chrome אסף מספיק נתונים על האתר שלכם, וב-Search Console יש דוח Core Web Vitals לפי קבוצות של כתובות. ב-Google Analytics 4 אין דוח Web Vitals מובנה — אם אתם רוצים את המספרים שם, תצטרכו לשלוח אותם בעצמכם עם ספריית web-vitals של Google, שהיא בקוד פתוח.

מה נחשב "טוב" לפי הספים של Google, ב-75% מהביקורים: LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS של 0.1 או פחות. כשמגיעים לשם, המהירות מפסיקה לעמוד בדרך של המכירות. כמה זה יעלה את ההמרות תלוי בכמה האתר האיטי עלה לכם, אז השוו את המספרים שלכם לפני ואחרי. כדי לעקוב אחרי מה שכבר נעשה, צ'קליסט הביצועים שלי מרכז 20 סעיפים שאפשר לסמן.