שיפור מהירות אתר וורדפרס

שיפור מהירות אתר וורדפרס שמטפל בסיבה

שיפור מהירות אתר וורדפרס מתחיל בשלילת המובן מאליו: אחסון הוא לעתים רחוקות הסיבה. בכמעט כל אתר וורדפרס איטי שאנו בודקים, העיכוב נובע מהעומס שנטען (Payload): בילדר (בונה עמודים) ששולח קבצי CSS ו-JavaScript עבור רכיבים שהעמוד לעולם אינו משתמש בהם, מספר תוספים שכל אחד מהם טוען עותק משלו של אותה ספריית קוד, ותמונות ראשיות (Hero images) שמוגשות ברזולוציה של 4,000 פיקסלים לתוך משבצת של 400 פיקסלים בלבד. השרת עונה מהר. הדפדפן, לאחר מכן, מבלה שניות ארוכות בהורדה ובהפעלה של כל מה שנזרק עליו.

זו הסיבה שתוסף קאש (Cache) מאכזב כל כך הרבה פעמים. קאש שומר את ה-HTML הסופי כדי שהשרת לא יצטרך לבנות אותו מחדש, מה שעוזר בביקורים חוזרים ומפחית את העומס על השרת. אבל הוא לא מפחית את מה שהדפדפן חייב להוריד ולהריץ לאחר מכן, והביקור הראשון הוא בדיוק זה שגוגל מודדת, וזה שמשתמש חדש (ליד פוטנציאלי) חווה. קודם כל יש להפחית את העומס הנטען (Payload), ורק אז להפעיל קאש על מה שנשאר. כך שני השינויים האלו משלימים זה את זה במקום להסתיר אחד את השני.

ששת הדברים של התהליך שיפור מהירות

שישה שלבים, בסדר הזה. מדידה בסוף היא הסיבה שרוב עבודות האופטימיזציה נשארות בלתי ניתנות להוכחה.

קבצי CSS ו-JavaScript שחוסמים תצוגה (Render-blocking)

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

תמונות בגודל שגוי

תמונה שמוגשת בגודל כבד בהרבה מהמקום שלה, בפורמט מיושן, ללא הגדרת רוחב וגובה, כך שגם פריסת העמוד "קופצת" (Layout Shift) כשהיא נטענת.

הבילדר (בונה העמודים) עצמו

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

תוספים שנטענים בכל עמוד

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

סקריפטים של צד שלישי (Third-party)

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

פונטים שנטענים בצורה איטית

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

מה שיפור מהירות אתר וורדפרס יכול ולא יכול לתקן

כדאי לדעת לפני שמשלמים, כי "תקרת הזכוכית" של המהירות תלויה במה שהאתר נבנה איתו.

01

כמעט תמיד ניתן לתיקון

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

ניתן לתיקון עם פשרות (Trade-offs)

עומס תוספים. חלק מהתוספים יכולים להיות מוגבלים לעמוד אחד או מוחלפים בקוד נקי, אבל תוסף שעושה עבודה אמיתית חייב להישאר, וה"מחיר" שלו (בזמן טעינה) נשאר איתו.
03

הבילדר הוא התקרה

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

לא בעיית מהירות בכלל

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

לאן העבודה מכוונת

0.1 סף יציבות הפריסה לפני שהדף נחשב קופצני

800 ms זמן התגובה הראשון של השרת שגוגל מגדירה כתקין

0 תוספים מיותרים

4 ארבעה שבועות עד שגוגל אוספת נתוני תנועה

תוסף קאש מול צמצום העומס

תוסף קאש ואחסון מהיר יותר

ביקורים חוזרים משתפרים, הביקור הראשון לא.
קבצי CSS ו-JavaScript שאינם בשימוש עדיין נטענים.
הציון בכלי הבדיקה עולה.
עוד תוסף שנוסף כדי לתקן תוספים אחרים.
המצב יחזור לאחור אחרי עדכון התבנית הבא.

צמצום מה שהעמוד טוען (גישה נכונה)

הביקור הראשון הופך למהיר יותר, וזה מה שגוגל מודדת.
משאבים כבדים מאותרים עד למקור שלהם ונחתכים משם.
נתוני שטח (Field data) ממבקרים אמיתיים עולים.
פחות תוספים רצים מאשר קודם.
הכל מתועד, כדי שאף אחד לא יתקין מחדש את מה שגרם לבעיה.

למי השירות הזה פחות מתאים

עבודת מהירות משתלמת רק בחלק מהמצבים. זו אינה הרכישה הנכונה אם:

האתר שלכם כבר מהיר. אם דוח Core Web Vitals ירוק במובייל, עוד עבודת מהירות לא תזיז את הדירוג ולא את שיעור ההמרה. עדיף להשקיע בתוכן או בקישורים, ונאמר לכם את זה לפני שתשלמו.

אתם עומדים לבנות את האתר מחדש. אופטימיזציה לאתר שיוחלף בעוד שלושה חודשים היא כסף שמשולם פעמיים. עדיף לצרף אותנו לבנייה עצמה, שם ביצועים לא עולים תוספת כי הם מתוכננים מראש.

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

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

שאלות נפוצות

מהי אופטימיזציית מהירות לוורדפרס?

אופטימיזציית מהירות לוורדפרס היא העבודה של צמצום מה שהדפדפן חייב להוריד ולהריץ לפני שעמוד הופך לשמיש, ולאחר מכן אימות השינוי עם נתוני מבקרים אמיתיים ולא רק ציון של כלי בדיקה. בפועל זה מכסה חמישה תחומים: הקבצים שחוסמים את תצוגת העמוד, הגשת התמונות, מצבור התוספים, סקריפטים של צד שלישי והגדרות קאש (מטמון). זה שונה מעבודת אחסון (שמשנה באיזו מהירות השרת עונה), ומשונה מבנייה מחדש (שמשנה ממה האתר עשוי). רוב אתרי הוורדפרס האיטיים הם איטיים בגלל משקל העמוד (Payload) ולא בגלל השרת, ולכן מעבר לאחסון מהיר יותר לרוב מאכזב בתוצאותיו. היעדים המדידים מפורסמים על ידי גוגל: LCP מתחת ל-2.5 שניות ו-INP מתחת ל-200 אלפיות השנייה.

עד כמה האתר שלי באמת יהפוך למהיר יותר?

זה תלוי לחלוטין במה שמאט אותו, ותשובות כנות ניתנות בטווחים ולא בהבטחות ריקות. אתוסיה, פלטפורמת גיוס ישראלית, ירדה ממעל ל-10 שניות ל-1.4 שניות, מכיוון שהאתר הזה סחב בילדר כבד ורשימת תוספים ארוכה שביצעה פעולות כפולות בכל בקשה. לאתר שכבר נטען ב-3 שניות יש הרבה פחות מה להסיר, והרווח המציאותי שם הרבה יותר קטן. מה שכן אפשר להתחייב עליו לפני תחילת העבודה הוא האבחון: אנו מודדים את העמוד הנוכחי, מנתחים את מפל טעינת הנתונים (Waterfall), ומציינים אילו גורמים מעכבים אפשר להסיר ובכמה זמן הם בערך יעלו. אם סך כל השיפור קטן מכדי להשפיע משמעותית עסקית, אנחנו נגיד לכם זאת במקום למכור לכם את השירות.

למה אתר הוורדפרס שלי איטי גם כשיש לי אחסון טוב?

מפני שהאחסון קובע באיזו מהירות השרת מגיב, לא כמה עבודה הדפדפן נדרש לעשות לאחר מכן. שרת מהיר יכול למסור עמוד שעדיין דורש מהדפדפן להוריד תשתית בילדר שלמה, מספר קבצי CSS של תוספים, כמה משקלי פונט משרתים חיצוניים, ווידג’ט צ’אט ותמונות שגדולות פי כמה מהמקום שהן תופסות. כל זה קורה לאחר שהשרת כבר סיים לענות, וכל זה מעכב את הרגע שבו העמוד הופך לשמיש באמת. זו גם הסיבה ששדרוג חבילת אחסון לרוב מספק שיפור קטן מהצפוי. זמן תגובת השרת מעולם לא היה החלק הגדול ביותר של ההמתנה. הפחתת העומס (Payload) היא זו שמזיזה את המחוג מבחינת מה שהמבקר חווה בפועל.

האם אתם יכולים לעשות אתר אלמנטור (Elementor) או דיווי (Divi) למהיר?

מהיר יותר, כן. מהיר באמת – רק עד גבול מסוים, ושווה להבין את הגבול הזה לפני שאתם מוציאים שקל. בילדר טוען תשתית (Framework) כדי שכל רכיב יוכל להופיע בכל מקום, מה שאומר שהעמוד שלכם משלם בביצועים על יכולות שהוא בכלל לא משתמש בהן, בכל בקשה. הגשת תמונות, קבצים חוסמי-תצוגה, פונטים וסקריפטים חיצונים – את כולם אפשר לתקן באתר מבוסס-בילדר, וזה לרוב מביא שיפור אמיתי. מה שאי אפשר להסיר זה את הבילדר עצמו. באתר שנבנה בצורה כבדה, ה”תקרה” הזו מגיעה מוקדם, ומעבר לה, הדרך היחידה היא בנייה מחדש של האתר בקוד נקי. אנחנו נגיד לכם בדיוק איפה התקרה של האתר הספציפי שלכם כבר בשלב הבדיקה, לפני שתתחייבו למשהו, ולא אחרי שתקבלו את החשבונית.

האם מהירות האתר באמת משפיעה על דירוג בגוגל?

היא משפיעה, אבל פחות ישירות ממה שרוב האנשים חושבים. מדדי Core Web Vitals הם סיגנל דירוג מאומת וגוגל מפרסמת את רף הדרישות, ובכל זאת – מהירות נטו כמעט אף פעם לא תקפיץ עמוד ממיקום 30 למיקום 3, כי רלוונטיות וסמכות קובעות הרבה יותר. היכן שמהירות כן מכריעה זה בין עמודים שמתחרים ראש בראש (כשהתוכן והסמכות דומים), ובמה שקורה אחרי הקליק. מבקר שמחכה 10 שניות, לרוב עוזב לפני שהוא רואה משהו, כך שהתנועה שכבר הרווחתם בדירוג – ממירה גרוע ממה שהיא צריכה. הדרך הנכונה ביותר להתייחס למהירות היא כהסרת מכשול, ולא כמנוף צמיחה קסום. צורת המחשבה הזו גם משאירה את התקציב פרופורציונלי למה שעבודת המהירות יכולה להחזיר לכם.

מה אני מקבל/ת בסוף?

שיפור מהירות אתר וורדפרס אמור להסתיים בשני דברים: אתר מהיר יותר, והתיעוד שדרוש כדי לשמור עליו כזה. התוצר כולל השוואה של “לפני ואחרי” על בסיס אותן בדיקות, רשימה כתובה של מה השתנה ולמה, והערה קצרה על מה לא מומלץ להתקין מחדש (שכן רוב האתרים שאנו מתקנים הפכו לאיטיים בהדרגה בעקבות התקנת תוספים מכוונות טובות). היכן שתוסף הוחלף בקוד, הקוד הזה יושב בתבנית שלכם ושייך לכם. אנחנו גם נבדוק שוב את דוח ה-Core Web Vitals לאחר שגוגל תאסוף מספיק נתוני תנועה אמיתיים, כך שהתוצאה מאומתת על ידי המבקרים שלכם ולא רק על ידי כלי בדיקה במחשב שלנו. אם משהו הדרדר בחזרה בינתיים, אנחנו נעדיף לעלות על זה בעצמנו מאשר שאתם תגלו את זה מאוחר יותר.