התקנת תוסף קאשינג. דחסת את התמונות. עקבת אחרי חמישה מדריכים שונים. ובכל זאת, האתר וורדפרס שלך עדיין נטען כאילו אנחנו ב-2009.
זה קורה הרבה יותר ממה שחושבים. שיפור מהירות וורדפרס הוא לא פתרון אחד — זה שכבות של פתרונות. ואם שכבה אחת שבורה, האחרות יכולות לעשות רק כל כך הרבה. בואו נבין מה באמת גורם לאתר להישאר איטי, גם אחרי שעשית "את כל הדברים הנכונים".
תוסף הקאשינג שלך עובד, אבל לא מספיק
קאשינג של עמודים — שמירת גרסת HTML סטטית של הדפים שלך — הוא בדרך כלל הדבר הראשון שמגדירים. וכן, זה עוזר. אבל קאש של עמודים מכסה רק חלק מהבעיה.
WordPress מבצע עשרות שאילתות למסד הנתונים בכל טעינת עמוד. גם אם ה-HTML שמור בקאש, שאילתות ברמת האובייקט (כמו: סשנים של משתמשים, נתוני ווידג'טים, אפשרויות זמניות) עדיין מגיעות למסד הנתונים בכל בקשה. בלי שכבת קאשינג בזיכרון בין WordPress למסד הנתונים, השאילתות האלו מצטברות מהר.
Redis object caching פותר את זה. הוא שומר את תוצאות השאילתות בזיכרון, כך ש-WordPress מושך נתונים מה-RAM במקום להריץ שאילתות בכל פעם. Redis cache שעובד טוב מגיע לשיעורי היט של מעל 80%, כלומר הרוב המכריע של פניות למסד הנתונים לא מגיע אליו כלל. זה הבדל מורגש בזמן הטעינה.
אם הספק האחסון שלך לא מטפל בזה בשבילך, שווה להגדיר את זה בנפרד. אצלנו זה כלול כאפשרות מובנית — ברגע שמפעילים, ה-cache drop-in מותקן אוטומטית ללא שינויים בקוד מצדך.
ה-JavaScript שלך נטען מוקדם מדי
זה מפתיע הרבה אנשים. יכולים להיות לך קבצי JavaScript קטנים ומוקטנים, אבל אם הם נטענים באופן סינכרוני ב-<head> של העמוד, הדפדפן עוצר הכל עד שכל אחד מהם מסיים להוריד ולרוץ.
הפתרון הוא להשתמש ב-defer או ב-delay על ה-JS שלך. הנה ההבדל:
- Defer — הסקריפט מורד במקביל לעמוד אבל רץ רק אחרי שה-HTML סיים להיטען. מתאים לסקריפטים שצריכים לרוץ בטעינת העמוד אבל לא חוסמים את הרינדור.
- Delay — הסקריפט לא נטען בכלל עד שהמשתמש מתקשר עם העמוד (גלילה, לחיצה, מגע). מצוין עבור analytics, צ'אט ווידג'טים וסקריפטים לא קריטיים אחרים.
דחיית JavaScript לא חיוני יכולה לשפר משמעותית את ציון ה-Largest Contentful Paint (LCP) שלך. החיסרון הוא שחלק מהסקריפטים חייבים לרוץ מיד — כמו סקריפטי קופה בחנות אונליין — אז כדאי להוסיף אותם לרשימת חריגים במקום לדחות הכל באופן גורף.
ה-CSS שלך ענק ורובו לא בשימוש
בוני עמודים ותבניות פרימיום הם עוצמתיים, אבל יש להם מחיר: קבצי CSS ענקיים שנטענים על כל עמוד, גם כשרוב הכללים לא רלוונטיים למה שמוצג על המסך.
דף הבית לא צריך את עיצובי עגלת WooCommerce. פוסט בבלוג לא צריך את ה-CSS של רכיב הסליידר. אבל הרבה תבניות טוענות את הכל בכל מקרה.
כלי Remove Unused CSS (RUCSS) פותרים את זה על ידי ניתוח אילו כללי CSS אכן בשימוש בכל סוג עמוד והסרת כל השאר. התוצאה היא קובץ עיצוב הרבה יותר קטן שמוגש לכל עמוד בנפרד, במקום קובץ נפוח אחד שנטען בכל מקום. זה לוקח קצת זמן — התהליך רץ ברקע — אבל הירידה בגודל הקובץ היא לעתים קרובות דרמטית.
אזהרה: תוכן דינמי וסגנונות שתלויים ב-JavaScript עלולים להיראות "לא בשימוש" בזמן הניתוח אבל בפועל נחוצים בזמן ריצה. תמיד בדוק היטב אחרי הפעלת RUCSS והוסף כל CSS selector מושפע לרשימת החריגים כדי שלא יוסר.
אתה מטפל בתסמינים, לא בסיבת השורש
הנה משהו שאנשים לא מדברים עליו מספיק: לפעמים האיטיות אינה קשורה לנכסים בכלל. היא קשורה להרצת PHP איטית, יותר מדי תוספים שעושים עבודה כפולה, או פונקציה אחת כתובה גרוע שרצה על כל עמוד.
זמן טעינה של 4 שניות שמקורו ב-3.8 שניות של הרצת PHP לא ייפתר על ידי דחיסת תמונות. זה דורש פרופיילינג — מדידה אמיתית של מה לוקח הכי הרבה זמן ברמת הקוד.
פרופיילינג טוב מראה לך זמן טעינה, מספר שאילתות למסד הנתונים, שימוש בזיכרון ואילו רכיבים ספציפיים הם האיטיים ביותר. ברגע שאתה רואה את זה, אתה מפסיק לנחש. ראינו אתרים שחצו את זמן הטעינה שלהם רק על ידי זיהוי והשבתה של שני תוספים שביצעו קריאות API כפולות בכל טעינת עמוד.
אם עדיין לא עשית פרופיילינג לאתר הוורדפרס שלך, זה צריך להיות הצעד הבא לפני שנוגעים בכל דבר אחר. דיברנו על זה בפירוט רב יותר בתיקוני המהירות של WordPress שכדאי לך לעשות (ואלו שלא).
הספק האחסון שלך הוא צוואר הבקבוק
שום כמות של שיפור מהירות וורדפרס לא תפצה על שרת איטי. אם ה-Time to First Byte (TTFB) שלך הוא מעל 600ms, השרת הוא הבעיה — לא התבנית שלך ולא התוספים שלך.
TTFB מודד כמה זמן לוקח לשרת להגיב לבקשה לפני שנשלח כל תוכן. TTFB טוב הוא מתחת ל-200ms. סביבות אחסון משותף, במיוחד עמוסות, חורגות בקביעות ל-1–2 שניות ב-TTFB בלבד. יכול להיות לך אתר WordPress מוכוון לחלוטין ועדיין להרגיש איטי רק בגלל שהשרת לוקח נצח להגיב.
זה אחד החלקים המוזנחים ביותר של שיפור מהירות וורדפרס. צד התוספים מקבל את כל תשומת הלב, אבל התשתית חשובה לא פחות. אם הספק הנוכחי שלך מציג ביצועים גרועים ב-TTFB באופן עקבי, שום תוסף לא יתקן את זה. ראה את סקירת האופטימיזציה של WordPress שלנו לפרטים נוספים על האופן שבו שכבת השרת משתלבת בתמונה.
התמונות שלך נראות מותאמות אבל הגודל שלהן לא נכון
הרצת את התמונות שלך דרך כלי דחיסה. טוב. אבל האם הן מוגשות בגדלים הנכונים?
טעות נפוצה היא להעלות תמונה ברוחב 2400px ולתת ל-CSS לכווץ אותה ל-600px בדפדפן. הדפדפן עדיין מוריד את התמונה המלאה של 2400px — הוא פשוט מציג אותה קטנה יותר. פסולת רוחב הפס הזו מצטברת מהר, במיוחד בחיבורים ניידים.
לפתרון יש שני חלקים:
- הגש תמונות בגודל התצוגה הנכון באמצעות מאפיין srcset של WordPress — תבניות מודרניות עושות זאת אוטומטית אם הגדרת את גדלי התמונה הנכונים.
- השתמש בפורמטים מתקדמים כמו WebP או AVIF, שבדרך כלל מקטינים את גודל הקבצים ב-30–50% בהשוואה ל-JPEG באיכות דומה.
Lazy loading גם שווה לאמת. תמונות מתחת לקו הגלילה לא צריכות להיטען עד שהמשתמש גולל לעברן. רוב תוספי הקאשינג מפעילים את זה, אבל כדאי לוודא שזה אכן פעיל — לא רק להניח שכן.
החלת יותר מדי אופטימיזציות שמתנגשות זו בזו
זה כואב כי זה בא מעשיית הדבר הנכון יותר מדי פעמים.
הרצת שני תוספי קאשינג בו-זמנית, או שימוש גם בתכונת שילוב הנכסים של תוסף וגם בקיצור של הספק שלך, לעתים קרובות מביאה לפריסות שבורות, שגיאות בקונסולה ואתרים איטיים יותר באופן פרדוקסלי. אופטימיזציות יכולות להתנגש בדרכים עדינות — תוסף אחד מטמיע CSS קריטי בפנים בעוד אחר דוחה את אותו קובץ עיצוב, ויוצר התנגשות עיתוי שמשבשת את הרינדור.
הגישה הבטוחה ביותר היא שכבה אחת של אופטימיזציה לכל פונקציה. תוסף קאשינג אחד. מקצר אחד. מייעל תמונות אחד. ואז לבדוק אחרי כל שינוי לפני הוספת השכבה הבאה.
הסברנו בדיוק איך לעשות את זה בלי לגרום לכאוס באיך להשתמש בתוספי קאשינג בלי לשבור את אתר הוורדפרס שלך בטעות.
סדר איתור תקלות מעשי
כשאתה מרגיש שניסית הכל, גישה מסודרת עוזרת. עבור על אלה לפי הסדר:
- מדוד TTFB קודם. השתמש ב-Google PageSpeed Insights או ב-WebPageTest. אם TTFB הוא מעל 500ms, התחל ברמת השרת.
- בצע פרופיילינג של הרצת PHP. מצא hooks איטיים, תוספים איטיים ושאילתות מסד נתונים מיותרות לפני שנוגעים בכל דבר אחר.
- בדוק את קאשינג מסד הנתונים שלך. ודא ש-Redis או Memcached פעילים ושיעור ה-Hit שלך תקין.
- בדוק את טעינת ה-JavaScript שלך. דחה מה שאפשר, השהה סקריפטים לא קריטיים ובדוק שלא נשבר כלום.
- ודא גדלי תמונות ופורמטים. בדוק שה-srcset עובד ושה-WebP מוגש לדפדפנים שתומכים בו.
- נקה עודפי CSS. אם גודל העמוד עדיין גדול, בחן CSS שאינו בשימוש ושקול הפעלת RUCSS.
עבודת מהירות היא תהליך חוזר. המטרה אינה להחיל כל אופטימיזציה בבת אחת — אלא למצוא היכן צוואר הבקבוק הספציפי שלך נמצא ולתקן אותו קודם. ברגע שתעשה זאת, השיפורים מצטברים. לפרטים נוספים על בניית אתר WordPress מהיר מרמת התשתית ומעלה, תיעוד האופטימיזציה של WordPress הוא מקום טוב להעמיק בו.
