למה אתר WordPress איטי — ומה באמת מזיז את המחט
ברוב האתרים האיטיים הזמן הולך לשלושה מקומות: שרת שמחשב כל עמוד מחדש, תמונות במשקל מלא, וסקריפטים של צד שלישי. מטמון, המרת תמונות ל-WebP וניקוי סקריפטים פותרים את רוב הבעיה.
כשאומרים «האתר איטי» מתכוונים בדרך כלל לשני דברים שונים לגמרי: כמה זמן עובר עד שמשהו מופיע על המסך, וכמה זמן עובר עד שאפשר לגלול ולהקליק. שני החלקים נשברים ממקורות אחרים, ולכן חשוב לפרק.
השלב הראשון: זמן תגובת השרת
לפני שהדפדפן מצייר פיקסל אחד, הוא מחכה לתשובה הראשונה מהשרת. באתר WordPress ללא מטמון, כל בקשה מפעילה PHP, שמריץ את הליבה, טוען את כל התוספים הפעילים, מבצע עשרות שאילתות למסד הנתונים ובונה את ה-HTML מאפס — עבור כל מבקר, כל פעם, גם אם העמוד לא השתנה חודש.
זמן תגובה סביר לעמוד שמוגש ממטמון הוא עשרות מילישניות בודדות. עמוד שמחושב מחדש בכל פעם מגיע בקלות ל-800 מילישניות ויותר, ועל אחסון עמוס גם לשתי שניות. זה החלק שמשפיע על כל שאר המדידות במורד הזרם.
- מטמון עמודים: התוצאה נשמרת ומוגשת ישירות, בלי PHP ובלי מסד נתונים.
- מטמון אובייקטים: שאילתות חוזרות נשמרות בזיכרון.
- OPcache: קוד PHP מקומפל נשמר, במקום להיקרא מחדש בכל בקשה.
- PHP עדכני: המעבר מ-7.4 ל-8.2 לבדו נותן שיפור מדיד בביצועים.
השלב השני: מה שיורד לדפדפן
אחרי התשובה הראשונה, הדפדפן מוריד תמונות, גופנים, קובצי סגנון וסקריפטים. כאן נמצא הרוב המוחלט של המשקל.
תמונות
התמונה היא הנכס הכבד ביותר כמעט בכל אתר. תמונה שצולמה בטלפון ועלתה כמו שהיא יכולה לשקול 4 מגה-בייט ולהיות מוצגת ברוחב 600 פיקסלים. הדפדפן עדיין מוריד את כל המשקל.
- המירו ל-WebP או AVIF — חיסכון טיפוסי של 25 עד 50 אחוז בלי הבדל נראה לעין.
- הגישו גודל שמתאים למקום שבו התמונה מוצגת, לא את המקור.
- הפעילו טעינה עצלה לכל מה שמתחת לקו הקיפול.
- הימנעו מטעינה עצלה דווקא בתמונה הראשית של העמוד — היא מה שהמבקר רואה ראשון, וטעינה עצלה שם מאטה את המדד שנמדד.
גופנים
כל משפחת גופנים היא כמה קבצים. שתי משפחות עם ארבעה משקלים כל אחת הן שמונה הורדות לפני שהטקסט מוצג. השתמשו בשתי משפחות לכל היותר, במשקלים שבאמת בשימוש, והוסיפו font-display: swap כדי שהטקסט יוצג מיד בגופן חלופי.
JavaScript של צד שלישי
זה החלק שהכי קל להתעלם ממנו וגם הכי כואב. פיקסל פרסום, צ׳אט, כלי מפות חום, טופס חיצוני, שני מנהלי תגיות — כל אחד מהם מושך קוד מאתר אחר, שאתם לא שולטים במהירות שלו.
שווה לבדוק פעם בשנה איזה סקריפטים באמת רצים באתר. כמעט תמיד מתגלה פיקסל של קמפיין שנגמר לפני שנתיים ועדיין נטען לכל מבקר.
מה שבאמת אשם: לא כמות התוספים, אלא איזה
אמירה נפוצה היא ש«יותר מדי תוספים מאטים אתר». זה לא מדויק. עשרים תוספים קלים שרצים רק בלוח הבקרה לא ישפיעו כמעט. לעומת זאת תוסף אחד שמוסיף שאילתה כבדה לכל טעינת עמוד יכול להכפיל את זמן התגובה לבדו.
| סוג תוסף | השפעה טיפוסית |
|---|---|
| בוני עמודים כבדים | גבוהה — הרבה CSS ו-JS בכל עמוד |
| סליידרים וגלריות | גבוהה — תמונות גדולות וסקריפטים |
| תוספי סטטיסטיקה שכותבים למסד בכל בקשה | גבוהה מאוד |
| תוספי SEO | נמוכה — רצים בעיקר בניהול |
| תוספי גיבוי | נמוכה, אלא אם הגיבוי רץ בשעת עומס |
סדר עבודה שמחזיר הכי הרבה בהכי מעט זמן
- הפעילו מטמון עמודים. זה הצעד הבודד עם התשואה הגבוהה ביותר.
- עדכנו את גרסת PHP.
- המירו תמונות ל-WebP והגישו גדלים מותאמים.
- מחקו סקריפטים חיצוניים שלא בשימוש.
- צמצמו גופנים.
- רק בסוף — חפשו את התוסף הכבד. עד השלב הזה כבר תדעו אם נשארה בעיה בכלל.
אצלנו מטמון, OPcache ו-CDN דלוקים מהרגע הראשון, וגרסת PHP עדכנית כברירת מחדל — כלומר שלושת הסעיפים הראשונים כבר מסודרים לפני שנגעתם בכלום.
איך למדוד בלי לרדוף אחרי מספר
ציון של כלי מדידה הוא לא המטרה. אפשר להגיע ל-100 בכלי אחד ולתת חוויה גרועה, וגם להפך. מדדו שלושה דברים לאורך זמן: זמן תגובת השרת, משקל העמוד הכולל, ומספר הבקשות. אם שלושתם יורדים, האתר באמת נהיה מהיר יותר.
אחסון WordPress ב-Siteyvo
כל מה שתואר כאן קורה במערכת אוטומטית, על כל אתר, בלי שתצטרכו לזכור.
תקנו עם Siteyvo