"וורדפרס איטי" הוא משפט שנשמע בכל דיון על בניית אתרים, והוא לא מדויק. וורדפרס עצמו הוא שכבה דקה יחסית. מה שמאט אתרים הוא מה שמערימים עליו: תבנית כבדה, בונה עמודים ויזואלי, עשרים תוספים ותמונות שלא נגעו בהן.
אנחנו בונים אתרי וורדפרס כבר יותר מ-12 שנה, והדפוס חוזר. בכל אתר איטי שאנחנו מקבלים לידיים, אותן ארבע סיבות מסבירות את רוב הפער, ורק אחריהן מגיעות העצות הטכניות שמופיעות בכל פורום.
המאמר הזה מסודר לפי סדר ההשפעה בפועל, ולא לפי מה שקל ליישם. בסוף יש גם רשימה של מה שלא שווה את הזמן שמושקע בו.
למה מהירות אתר משנה בכלל?
כי היא משפיעה גם על מי שנשאר וגם על הדירוג. גולש שממתין לטעינה במובייל בחיבור סלולרי נוטש הרבה לפני שראה משהו, וגוגל מודדת את חוויית העמוד כחלק מהדירוג. שני האפקטים מצטברים, ולכן אתר איטי מפסיד פעמיים.
המדד שהכי משפיע הוא LCP, שמודד כמה זמן לוקח עד שהאלמנט הגדול ביותר בעמוד מוצג. ברוב האתרים זו התמונה בראש העמוד, ולכן היא גם הנקודה שהכי משתלם לטפל בה.
שני מדדים נוספים משלימים את התמונה: INP, שמודד כמה מהר העמוד מגיב ללחיצה, ו-CLS, שמודד כמה אלמנטים קופצים ממקומם בזמן הטעינה. השני נגרם כמעט תמיד מתמונות בלי מידות מוגדרות.
והכי חשוב: מודדים במובייל. הציון בדסקטופ כמעט תמיד גבוה יותר, והוא לא מייצג את הרוב המכריע של הגולשים בישראל.
מה באמת מאט אתרי וורדפרס?
ארבעה גורמים, בסדר הזה: תמונות שלא טופלו, תבנית או בונה עמודים כבד, ריבוי תוספים, ואחסון זול. יחד הם מסבירים את רוב הפער בכל אתר שאנחנו בודקים, והשאר, כולל רוב העצות שמופיעות בפורומים, משפיע הרבה פחות.
| הגורם | כמה משפיע | כמה קשה לתקן |
|---|---|---|
| תמונות לא דחוסות | מאוד | קל, פעולה אחת על כל הספרייה |
| בונה עמודים ויזואלי | מאוד | קשה, דורש בנייה מחדש |
| ריבוי תוספים | בינוני עד גבוה | בינוני, דורש בדיקה אחד אחד |
| אחסון איטי | גבוה | קל, מעבר ספק |
| קאשינג לא מוגדר | בינוני | קל |
| גופנים חיצוניים | נמוך עד בינוני | קל |
| מיזעור קוד | נמוך | קל |
שימו לב לשורה השנייה. בונה עמודים ויזואלי מוסיף משקל קבוע לכל עמוד באתר, וזה מחיר שמשלמים כל יום ולא פעם אחת. אי אפשר לפתור אותו באופטימיזציה, רק בהחלטה אחרת בשלב הבנייה.
זו הסיבה שבבניית אתרים אנחנו עובדים על תבנית מותאמת ולא על בונה עמודים. ההפרש בזמן הבנייה מוחזר תוך חודשים בביצועים ובעלות התחזוקה.
איך מטפלים בתמונות נכון?
בשלושה שלבים פשוטים: לשנות גודל למה שבאמת מוצג במסך, להמיר לפורמט מודרני כמו WebP, ולטעון בעצלות את כל מה שיושב מתחת לקו הקיפול. שלושת השלבים יחד לוקחים כשעה ומורידים לרוב את משקל העמוד בעשרות אחוזים, בלי לגעת בעיצוב או בתוכן.
הטעות הנפוצה היא העלאת תמונה בגודל המקורי מהמצלמה. תמונה ברוחב חמשת אלפים פיקסלים שמוצגת ברוחב שמונה מאות היא בזבוז של פי כמה, והדפדפן עדיין מוריד את כולה.
פורמט מודרני כמו WebP מקטין את המשקל משמעותית באותה איכות נראית. רוב תוספי האופטימיזציה ממירים אוטומטית ומשאירים גיבוי לדפדפנים ישנים, כך שאין סיכון ממשי.
ולתמונה בראש העמוד יש כלל הפוך: אותה דווקא לא מטעינים בעצלות. היא בדרך כלל מה שנמדד ב-LCP, וטעינה עצלה שלה מאטה את המדד במקום לשפר אותו.
כמה תוספים זה יותר מדי?
זו לא השאלה הנכונה. תוסף אחד כבד שטוען קוד בכל עמוד באתר גרוע בהרבה מעשרה תוספים קלים שרצים רק היכן שצריך אותם. מה שקובע הוא מה כל תוסף טוען ובאילו עמודים, ולא כמה שורות מופיעות ברשימה בלוח הבקרה.
הבדיקה המעשית היא לכבות תוסף אחד, למדוד, ולהדליק חזרה. זו עבודה מייגעת ולכן כמעט אף אחד לא עושה אותה, והיא זו שמגלה שתוסף אחד אחראי לחצי מהבעיה.
החשודים הקבועים הם תוספי סליידר, תוספי טפסים כבדים, תוספי צ׳אט חיצוניים ותוספי אנימציה. כולם טוענים ספריות בכל עמוד באתר, גם בעמודים שלא משתמשים בהם בכלל.
כלל אצבע שמנחה אותנו: כל תוסף חייב להצדיק את קיומו בפונקציה שהעסק באמת משתמש בה. תוסף שהותקן פעם אחת לניסיון ונשאר הוא הנפוץ ביותר, והוא גם הקל ביותר להסרה.
כמה משפיע האחסון?
יותר ממה שרוב העסקים מניחים. שרת משותף זול מריץ מאות אתרים על אותם משאבים, וזמן התגובה שלו נמדד ישירות כ-TTFB. אתר עם זמן תגובה איטי מתחיל את המרוץ באיחור, ושום אופטימיזציה בצד הלקוח לא תפצה על כך.
המדד שכדאי להסתכל עליו הוא זמן התגובה של השרת לבקשה הראשונה. כשהוא גבוה, הבעיה היא באחסון או בקאשינג ולא בעמוד עצמו, וכל שעה שמושקעת בדחיסת תמונות לא תשנה אותו.
לאתרים שפונים לקהל ישראלי, שרת בישראל או קרוב אליה מקצר את זמן התגובה בפועל. זה נשמע כמו פרט טכני, וההשפעה שלו מורגשת מיד.
קאשינג ברמת העמוד המלא הוא ההשלמה לזה. הוא הופך עמוד שנבנה מחדש בכל בקשה לקובץ מוכן, וזה ההבדל הגדול ביותר שאפשר לעשות בהגדרה אחת.
מה משתנה בחנות מקוונת?
המשוואה נעשית קשה בהרבה. חנות לא יכולה להשתמש בקאשינג מלא על עמודי העגלה והתשלום, יש בה פי כמה תמונות מאתר תדמית, והקטלוג מייצר עמודים דינמיים בכל סינון. לכן חנות מהירה דורשת החלטות מבניות כבר בשלב הבנייה, ולא אופטימיזציה בדיעבד.
מה שכן אפשר לעשות: להוציא מהקאשינג רק את מה שחייב, לדחוס תמונות מוצר באופן שיטתי, ולוודא שהקטלוג לא טוען את כל התמונות בעמוד קטגוריה בבת אחת.
בפרויקטים של בניית אתר איקומרס אנחנו קובעים את זה כבר באפיון: כמה מוצרים בעמוד קטגוריה, איך נטענות התמונות, ומה קורה בסינון. אחר כך זה הרבה יותר יקר לשנות.
באתר תדמית התמונה פשוטה יותר. אתר תדמית לעסק עם חמישה או שישה עמודים יכול להגיע לציונים גבוהים כמעט תמיד, ואם הוא לא מגיע, הסיבה היא כמעט תמיד התבנית.
מה לא שווה את הזמן?
רדיפה אחרי ציון מושלם בכלי המדידה. ההבדל בין ציון תשעים לתשעים ותשע כמעט לא מורגש לגולש אמיתי, ולעיתים קרובות הוא דורש ויתור על אלמנטים שמייצרים המרות בפועל. המדד שחשוב הוא מה הגולש חווה כשהוא נכנס מהטלפון, ולא המספר הצבעוני שמופיע במסך.
- מיזעור קוד ידני. תוסף קאשינג טוב עושה את זה לבד
- הסרת כל האנימציות. אם הן קלות, הן לא הבעיה
- שינוי ספק אחסון בכל שנה. אחרי מעבר אחד לספק סביר, התשואה יורדת
- אופטימיזציה של דסקטופ. הוא ממילא בציון גבוה. מובייל הוא הזירה
- מרדף אחרי 100. תשעים ומעלה במובייל הוא הישג מצוין
מה שכן שווה תמיד: מדידה חוזרת אחרי כל שינוי משמעותי באתר. תוסף חדש, סליידר שנוסף לעמוד הבית או שינוי תבנית יכולים למחוק חודשי עבודה, ואם לא מודדים, זה מתגלה חודשים אחר כך.
וכדאי לזכור שמהירות היא תנאי ולא יתרון. היא לא תדרג אתכם במקום שהתוכן לא מצדיק, אבל היעדרה יעצור אתכם גם כשהכל אחר תקין. בעבודת חברת מיתוג או עיצוב זה השיקול שנוטים לוותר עליו ראשון, וזו כמעט תמיד טעות.
אף לקוח לא אמר לנו שהאתר יפה מדי. הרבה אמרו שהוא נטען לאט, ואת זה הם אומרים בעזיבה.
אור פלתה, מנכ״ל U Digital Studio
שאלות ותשובות
האם וורדפרס איטי מטבעו?
לא. וורדפרס עצמו הוא שכבה דקה יחסית, ומה שמאט אתרים הוא מה שמערימים עליו: תבנית כבדה, בונה עמודים ויזואלי, ריבוי תוספים ותמונות שלא טופלו. אותו וורדפרס עם תבנית מותאמת ומעט תוספים מגיע לציונים גבוהים במובייל.
מה הכי משפיע על מהירות אתר וורדפרס?
התמונות, כמעט בכל אתר שאנחנו בודקים. שינוי גודל למה שבאמת מוצג, המרה לפורמט מודרני וטעינה עצלה למה שמתחת לקו הקיפול לוקחים כשעה ומורידים את משקל העמוד בעשרות אחוזים בלי לגעת בעיצוב או בתוכן.
כמה תוספים זה יותר מדי?
זו לא השאלה הנכונה. תוסף אחד כבד שטוען קוד בכל עמוד גרוע יותר מעשרה תוספים קלים שרצים רק היכן שצריך. הבדיקה המעשית היא לכבות תוסף אחד, למדוד, ולהדליק חזרה, וכך לגלות מי אחראי בפועל לרוב הבעיה.
האם כדאי להשתמש באלמנטור?
לאתר קטן שמתוחזק על ידי בעל העסק, הנוחות שווה את המחיר. לאתר שהמהירות שלו חשובה, בונה עמודים ויזואלי מוסיף משקל קבוע לכל עמוד וזה מחיר שמשלמים כל יום. אי אפשר לפתור אותו באופטימיזציה, רק בהחלטה בשלב הבנייה.
כמה משפיע האחסון על המהירות?
יותר ממה שרוב העסקים מניחים. שרת משותף זול מריץ מאות אתרים על אותם משאבים, וזמן התגובה שלו נמדד ישירות. אתר עם זמן תגובה איטי מתחיל את המרוץ באיחור, ושום דחיסת תמונות לא תפצה על כך.
מה זה LCP ולמה הוא חשוב?
המדד שמודד כמה זמן לוקח עד שהאלמנט הגדול ביותר בעמוד מוצג, ברוב האתרים התמונה בראש העמוד. היעד הוא מתחת לשתי שניות וחצי במובייל. זה המדד שהכי משפיע מבין מדדי חוויית העמוד, ולכן גם המקום שהכי משתלם לטפל בו.
איזה ציון מהירות נחשב טוב?
תשעים ומעלה במובייל הוא הישג מצוין ורוב האתרים רחוקים ממנו. אין טעם לרדוף אחרי מאה: ההבדל בין תשעים לתשעים ותשע כמעט לא מורגש למשתמש ולעיתים דורש ויתור על אלמנטים שמייצרים המרות. מודדים במובייל ולא בדסקטופ.
למה חנות מקוונת קשה יותר להאצה?
כי אי אפשר להשתמש בקאשינג מלא על עמודי עגלה ותשלום, יש בה הרבה יותר תמונות, והקטלוג מייצר עמודים דינמיים. לכן חנות מהירה דורשת החלטות מבניות בשלב האפיון, כמו כמה מוצרים בעמוד קטגוריה ואיך נטענות התמונות.