דילוג לתוכן הראשי
אופטימיזציית מהירותביצועיםאחסון וורדפרסCore Web Vitals

אופטימיזציית מהירות לוורדפרס — מ-4 שניות ל-800 מילישניות

שיטת עבודה מסודרת לזירוז אתר וורדפרס: איך למדוד נכון, איפה באמת מתבזבז הזמן, ומה לעשות בכל שלב — לפי סדר התשואה.

אביר

אחראי מידע ותוכן

7 דקות קריאה
תוכן עניינים14 פרקים
  1. קודם כל: למדוד נכון
  2. איפה הזמן באמת הולך
  3. שלב 1 — מטמון (התשואה הגבוהה ביותר)
  4. שלב 2 — גרסת PHP ומגבלת זיכרון
  5. שלב 3 — תמונות
  6. שלב 4 — JavaScript ו-CSS חוסמים
  7. שלב 5 — מסד הנתונים
  8. שלב 6 — CDN
  9. סדר הפעולות המומלץ
  10. מקרה שכיח: האתר מהיר בבדיקה ואיטי אצל הלקוחות
  11. מה למדוד אחרי כל שינוי
  12. עלות ההזנחה, במספרים
  13. מה לא לעשות
  14. מה זה נותן בפועל

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

המדריך הזה בנוי אחרת: קודם מודדים, אחר כך מבינים איפה הזמן הולך, ורק אז מתקנים — לפי סדר התשואה.

קודם כל: למדוד נכון

הבחנה בין שני סוגי נתונים

נתוני מעבדה (Lab Data) נמדדים בסביבה מבוקרת. PageSpeed Insights ו-Lighthouse נותנים את אלה. הם עקביים וניתנים לשחזור, אבל הם לא המשתמשים שלכם.

נתוני שדה (Field Data) נאספים ממבקרים אמיתיים — במכשירים אמיתיים, ברשתות אמיתיות. גוגל אוספת אותם ב-CrUX, והם מה שמשפיע על הדירוג.

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

התחילו תמיד מ-Search Console, בדוח Core Web Vitals. אלה נתוני אמת.

המדד שאף אחד לא מסתכל עליו: TTFB

Time To First Byte הוא הזמן מרגע הבקשה ועד שהבייט הראשון של ה-HTML חוזר. הוא לא מופיע בכותרת של PageSpeed, והוא הבסיס לכל השאר — כל מילישנייה ב-TTFB היא מילישנייה שנוספת לכל מדד אחר.

TTFBהערכה
מתחת ל-200msמצוין
200–500msסביר
500–800msבעייתי
מעל 800msהשרת הוא הבעיה, לא הדף

אם ה-TTFB שלכם הוא 1.2 שניות, שום דחיסת תמונות לא תציל אתכם. תתקנו את השרת קודם.

לבדיקה מהירה מהטרמינל:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.co.il

איפה הזמן באמת הולך

בטעינת דף וורדפרס טיפוסית ללא מטמון, הזמן מתחלק בערך כך:

  • 35% — הרצת PHP: טעינת הליבה, אתחול התוספים, בניית ה-HTML
  • 25% — שאילתות מסד נתונים
  • 20% — הורדת משאבים: תמונות, CSS, JavaScript
  • 15% — עיבוד ורינדור בדפדפן
  • 5% — רשת ו-DNS

המסקנה חשובה: 60% מהזמן מתרחש בשרת, לפני שהדפדפן קיבל תו אחד. רוב מאמצי האופטימיזציה מתמקדים ב-20% של הורדת המשאבים.

שלב 1 — מטמון (התשואה הגבוהה ביותר)

מטמון דפים הופך את 60% הראשונים לכמעט אפס. במקום להריץ PHP ולשאול את מסד הנתונים, השרת מגיש קובץ HTML מוכן.

יש שלוש רמות, והן משלימות:

מטמון דפים (Page Cache) — שומר את ה-HTML המוגמר. ההשפעה הדרמטית ביותר. TTFB יורד מ-800ms ל-50ms.

מטמון אובייקטים (Object Cache) — שומר תוצאות שאילתות בזיכרון, בדרך כלל ב-Redis. קריטי לדפים שלא ניתן לשמור במטמון: עגלת קנייה, אזור אישי, תוצאות חיפוש.

OPcache — שומר את קוד ה-PHP המהודר. מופעל ברמת השרת, לא באתר. אם הוא כבוי אצל הספק שלכם, אתם משלמים על הידור מחדש בכל בקשה.

הסברנו את המנגנון לעומק במאמר מטמון בוורדפרס — איך זה עובד באמת.

מלכודת נפוצה: אתר WooCommerce שבו כל הדפים במטמון יציג לכל המבקרים את אותה עגלה. חובה להחריג /cart, /checkout, /my-account ולהגדיר מטמון אובייקטים.

שלב 2 — גרסת PHP ומגבלת זיכרון

המעבר מ-PHP 7.4 ל-8.3 נותן שיפור ניכר בזמן ההרצה, ללא שינוי קוד. זה השיפור הזול ביותר שקיים.

לפני שמחליפים, בדקו תאימות: תוסף שלא עודכן שלוש שנים עלול להישבר. עשו זאת בסביבת Staging, לא באתר החי.

בנוסף, ודאו שמגבלת הזיכרון סבירה. ב-wp-config.php:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '768M' );

שלב 3 — תמונות

תמונות הן בדרך כלל 60–70% ממשקל הדף, וזה החלק הקל לתקן.

המירו ל-WebP או AVIF. WebP חוסך 25–35% לעומת JPEG באותה איכות. AVIF חוסך יותר, בתמיכה טובה ב-2026.

הגישו בגודל הנכון. תמונה של 3000 פיקסלים המוצגת ברוחב 600 מבזבזת פי 25 בייטים. השתמשו ב-srcset — וורדפרס מייצר אותו אוטומטית אם התבנית תומכת.

טעינה עצלה (Lazy Loading) מובנית בוורדפרס מגרסה 5.5. אבל אל תחילו אותה על התמונה הראשית — היא ה-LCP שלכם, וטעינה עצלה עליה מאטה את המדד החשוב ביותר.

הגדירו width ו-height על כל תמונה. בלעדיהם הדפדפן לא יודע כמה מקום לשריין, והדף קופץ כשהתמונה נטענת. זה CLS, והוא נמדד.

שלב 4 — JavaScript ו-CSS חוסמים

הדפדפן מפסיק לבנות את הדף כשהוא נתקל בקובץ CSS או JavaScript בראש המסמך.

מה לעשות:

  • העבירו סקריפטים לא-קריטיים ל-defer או async.
  • הסירו CSS שאינו בשימוש. תבניות רבות טוענות את כל העיצוב בכל דף.
  • דחו טעינת גופנים חיצוניים, או ארחו אותם מקומית עם font-display: swap.
  • בדקו מה כל תוסף טוען. תוסף טפסים שטוען את הספרייה שלו בכל דף באתר, כולל דפים ללא טפסים, הוא בזבוז נטו.

שלב 5 — מסד הנתונים

טבלת wp_options היא החשודה המיידית. כל טעינת דף טוענת את כל השורות המסומנות autoload = yes. תוספים שהוסרו משאירים שם זבל.

SELECT SUM(LENGTH(option_value))/1024/1024 AS mb
FROM wp_options WHERE autoload = 'yes';

מעל 1MB — יש בעיה. מעל 3MB — הבעיה חמורה.

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

שלב 6 — CDN

CDN מגיש קבצים סטטיים משרת קרוב למבקר. הוא לא מחליף אחסון טוב — ה-HTML עדיין מגיע מהשרת שלכם — אבל הוא מוריד עשרות מילישניות מכל תמונה.

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

סדר הפעולות המומלץ

  1. מדדו TTFB. אם הוא מעל 600ms — התשתית היא הבעיה.
  2. הפעילו מטמון דפים.
  3. עברו ל-PHP 8.2+.
  4. תקנו את התמונות: פורמט, גודל, מידות.
  5. טפלו ב-JavaScript החוסם.
  6. נקו את מסד הנתונים.
  7. הוסיפו CDN.
  8. מדדו שוב — בשדה, לא רק במעבדה.

אל תדלגו לשלב 7. אתר על תשתית איטית עם CDN הוא אתר איטי שמגיש תמונות מהר.

מקרה שכיח: האתר מהיר בבדיקה ואיטי אצל הלקוחות

זה קורה הרבה, ויש לו שלוש סיבות מקובלות.

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

אתם על סיב והם על סלולר. תשתית ביתית בישראל היא מהירה מאוד; רשת סלולרית עמוסה בשעת ערב היא סיפור אחר. ב-DevTools אפשר לדמות: לשונית Network, בחירת Slow 4G.

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

מה למדוד אחרי כל שינוי

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

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

הנתונים שכדאי לתעד בכל סבב:

מהאיך
TTFBcurl -w "%{time_starttransfer}"
LCPPageSpeed Insights, חלק השדה
משקל דף כוללDevTools, לשונית Network
מספר בקשותאותו מקום
מספר שאילתותתוסף Query Monitor

עלות ההזנחה, במספרים

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

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

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

מה לא לעשות

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

אל תרדפו אחרי 100 ב-PageSpeed. הציון הוא קירוב. אתר עם 78 שנטען ב-1.1 שניות טוב מאתר עם 96 שנטען ב-2.4.

אל תדחסו תמונות עד להרס. JPEG באיכות 40 חוסך בייטים ומאבד לקוחות.

מה זה נותן בפועל

באתר תדמית טיפוסי על אחסון שיתופי, סדר הפעולות הזה מוריד את זמן הטעינה מ-3.5–4.5 שניות ל-0.8–1.2 שניות. הקפיצה הגדולה מגיעה משני השלבים הראשונים; השאר מלטש.

אם אחרי כל זה ה-TTFB עדיין גבוה — הבעיה בתשתית. חבילות אחסון הוורדפרס שלנו מגיעות עם NVMe, PHP 8.3 ומטמון ברמת השרת, ורוב האתרים שעוברים אלינו רואים שיפור עוד לפני שנגעו בתוסף אחד.


נכתב על ידי אביר, אחראי מידע ותוכן ב-CloudX. להמשך קריאה: Core Web Vitals לוורדפרס.