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

מתחילים ממה שהגולשים האמיתיים חווים

רוב המדריכים למהירות נפתחים ברשימת טיפים. אני פותח בשאלה: מה איטי, ואצל מי? הריצו Google PageSpeed Insights (https://pagespeed.web.dev/) על העמוד הכי חשוב לכם, לא רק על עמוד הבית, וקראו קודם את החלק העליון של הדוח. אלה נתוני שטח: מה שגולשים אמיתיים בכרום חוו ב-28 הימים האחרונים, לפי האחוזון ה-75, כלומר הם מתארים את הביקורים האיטיים יותר ולא את אלה שהיה להם מזל. אם לעמוד אין מספיק ביקורים, PageSpeed Insights מציג נתונים של האתר כולו, ובאתר קטן ייתכן שלא יהיו נתוני שטח בכלל. Google לא מפרסמת מה סף הביקורים.

המקום השני הוא דוח Core Web Vitals ב-Search Console. הוא בנוי מאותם נתונים של גולשים אמיתיים, מפריד בין מובייל למחשב, ומקבץ עמודים שמתנהגים דומה, כך שתבנית איטית מופיעה כקבוצה של כתובות. מופיעים בו רק עמודים שנמצאים באינדקס. הציון בחלק התחתון של PageSpeed Insights הוא נתוני מעבדה: ביקור מדומה אחד, שימושי למציאת הסיבות אבל לא יציב. צוות Lighthouse עצמו כותב שהציון משתנה בין הרצות גם כשהקוד לא השתנה, לכן הריצו כמה פעמים והשוו את התוצאה האמצעית, לא את הטובה ביותר.

הספים ש-Google מגדירה כ"טובים", לפי האחוזון ה-75: LCP (כמה זמן עד שהתוכן הראשי מופיע) עד 2.5 שניות, INP (כמה מהר העמוד מגיב ללחיצה או לנגיעה) עד 200 מילישניות, CLS (כמה העמוד קופץ בזמן הטעינה) עד 0.1. לפרופורציה: לפי ה-Web Almanac של HTTP Archive לשנת 2025, עמוד הבית החציוני שקל במובייל 2.56 MB. אתר וורדפרס עם תריסר תוספים וגלריית תמונות שלא עברו דחיסה נמצא לא פעם הרבה מעל זה.

איזה מהשלבים בהמשך רלוונטי לאתר שלכם

חמשת השלבים בהמשך לא חשובים באותה מידה בכל אתר, ולבצע אותם בסדר אקראי זה לבזבז כסף. המדד שנכשל אומר לכם מאיפה להתחיל. LCP הוא הכישלון הנפוץ ביותר, ואפשר לפרק אותו לחלקים: הזמן עד שהשרת עונה (TTFB), העיכוב עד שהדפדפן מתחיל לטעון את התמונה הראשית, הזמן שלוקח להוריד אותה, והעיכוב עד שהיא מצוירת על המסך. לפי web.dev, זמן ההורדה עצמו בדרך כלל אינו צוואר הבקבוק העיקרי ברוב האתרים. בפועל זה אומר שדחיסת תמונות עוזרת פחות ממה שנדמה, כשהבעיה האמיתית היא שרת איטי או תמונה ראשית שהדפדפן מגלה מאוחר.

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

• השרת עונה לאט (web.dev מציע TTFB של עד 0.8 שניות כקו מנחה): מתחילים בשלב 2, מטמון, ואז בשלב 1, תוספים. משדרגים אחסון רק אם זה עדיין איטי אחרי שני אלה.
• השרת מהיר אבל ה-LCP גרוע: בודקים קודם את התמונה הראשית (שלב 3: האם היא בטעינה עצלה, האם היא ענקית), ואחר כך CSS ו-JavaScript שחוסמים את הרינדור (שלב 4).
• ה-INP גרוע: הסיבה כמעט תמיד היא JavaScript, בדרך כלל של תוספים ותגי מעקב. עברו לשלב 4, וקראו את המדריך שלי ל-INP בוורדפרס.
• ה-CLS גרוע: web.dev מונה כסיבות הנפוצות תמונות, פרסומות, הטמעות ו-iframe בלי מידות, תוכן שמוזרק מאוחר, וגופני רשת. הגדירו רוחב וגובה לתמונות ושמרו מקום מראש לבאנרים ולהטמעות.
• האתר בנוי באלמנטור והכול איטי: לזה יש סיבות ייחודיות, והן מפורטות במדריך הביצועים לאלמנטור שלי.

שלב 1: בדיקה וגיזום של תוספים

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

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

שלב 2: הפעלת מטמון ודחיסה

מטמון הוא השיפור הגדול ביותר בצד השרת, ויש לו שתי שכבות. מטמון עמודים שומר את ה-HTML המוכן, כך שרוב הביקורים לא מגיעים בכלל ל-PHP ולמסד הנתונים — השתמשו במטמון המובנה של חברת האחסון או בתוסף כמו WP Rocket או W3 Total Cache (התוסף מוסיף בעצמו את define( 'WP_CACHE', true ); ל-wp-config.php). מטמון אובייקטים שומר בזיכרון את תוצאות השאילתות למסד הנתונים: בקשו מחברת האחסון Redis, התקינו את התוסף Redis Object Cache והפעילו אותו. בחנויות ווקומרס ובאתרי מנויים, שבהם אי אפשר לשמור במטמון עמודים של משתמשים מחוברים ושל העגלה, מטמון האובייקטים הוא מה שמאיץ את העמודים החשובים.

ודאו שדחיסת טקסט פעילה — gzip, או עדיף Brotli. אצל חברות אחסון מודרניות ומאחורי Cloudflare זה בדרך כלל אוטומטי. לבדיקה: פתחו DevTools > Network, טענו את העמוד מחדש, לחצו על מסמך ה-HTML וחפשו כותרת תגובה content-encoding עם הערך gzip או br. אם היא חסרה, בקשו מחברת האחסון להפעיל את הדחיסה.

שלב 3: אופטימיזציה אגרסיבית של תמונות

התקינו ShortPixel או Smush והריצו אותו על כל התמונות, כולל אלה שכבר הועלו. הגדירו: (א) המרה ל-WebP (או AVIF), (ב) הקטנה של כל תמונה שרחבה יותר ממה שהיא אי פעם מוצגת — בערך 2400px מספיקים גם לתמונת hero ברוחב מלא, (ג) דחיסה לאיכות של בערך 70–80%. בספריית מדיה של תמונות שהועלו ישר מהמצלמה או מהטלפון, החיסכון בדרך כלל דרמטי, וכל עמוד שמציג את התמונות האלה נעשה קל יותר.

טעינה עצלה (lazy loading) כבר מובנית: מאז וורדפרס 5.5 הליבה מוסיפה אוטומטית loading="lazy" לתמונות התוכן, מאז גרסה 5.9 היא מדלגת על תמונת התוכן הראשונה כדי לא לעכב את תמונת ה-LCP, ומאז 6.3 היא גם מסמנת אותה ב-fetchpriority="high". הטעות הנפוצה היא ההפך — ערכת עיצוב או תוסף lazy load שמשהים גם את תמונת ה-hero, וזה דוחה את ה-LCP בסבב רשת שלם. בדקו את תמונת ה-hero ב-DevTools וודאו שהיא לא מוגדרת כ-lazy.

שלב 4: דחייה או ביטול של JavaScript חוסם רינדור

אתרי וורדפרס איטיים טוענים בדרך כלל הרבה יותר JavaScript ממה שהעמוד באמת משתמש בו — PageSpeed Insights מציג את זה תחת "Reduce unused JavaScript". השתמשו בתוסף החינמי Query Monitor כדי לראות איזה תוסף טוען איזה סקריפט. באתרי אלמנטור, בדקו קודם את חבילות ההרחבה של צד שלישי: רבות מהן טוענות את הקבצים שלהן בכל עמוד, בעוד שהווידג'טים של אלמנטור עצמו נטענים רק איפה שמשתמשים בהם. טענו סקריפטים לא קריטיים עם async או defer, או השהו אותם עד לאינטראקציה הראשונה, עם תוסף כמו Autoptimize, WP-Optimize או WP Rocket.

סקריפטים של מעקב הם הדוגמה הקלאסית. קטעי הקוד הרשמיים של Google Analytics, של Hotjar ושל Meta Pixel כבר נטענים באופן אסינכרוני, אבל ערכות עיצוב ותוספים מזריקים לפעמים עותק סינכרוני משלהם, או טוענים את אותו תג פעמיים. טענו כל תג פעם אחת בלבד — עדיף דרך קונטיינר אחד של Google Tag Manager — ושקלו להשהות את אלה שאינם חיוניים. סקריפט חוסם אחד ב-<head> מעכב את כל מה שבא אחריו.

שלב 5: בדקו שוב ותעדו

אחרי כל תיקון, הריצו שוב את PageSpeed Insights והשוו את אותם מדדים. למשל, אם ה-LCP יורד מ-4.2 ל-2.8 שניות, זה שיפור של 33%, והעמוד עובר מ"גרוע" ל"דורש שיפור" ("טוב" הוא 2.5 שניות או פחות). ההצדקה העסקית אמיתית: במחקר של Deloitte עבור Google, שיפור של 0.1 שנייה במהירות האתר במובייל העלה את ההמרות בקמעונאות ב-8.4% — רק אל תצפו שהמספר הזה יתורגם אחד לאחד לאתר שלכם.

מספרי המעבדה זזים באותו יום; נתוני השטח לא. PageSpeed Insights ו-Search Console מציגים את 28 הימים האחרונים, ולכן תיקון מופיע שם בהדרגה במשך כארבעה שבועות. רשמו את התאריך של כל שינוי. באותם נתוני שטח משתמשים גם לניטור שוטף (INP החליף את First Input Delay כמדד Core Web Vitals ב-12 במרץ 2024, כך שדוחות ישנים שמדברים על FID כבר לא עדכניים). Google Analytics 4 לא אוסף Web Vitals בעצמו; אם לאתר שלכם אין נתוני שטח ב-PageSpeed Insights, אפשר למדוד גולשים אמיתיים בעצמכם עם ספריית web-vitals של Google, שהיא בקוד פתוח, ולשלוח את הערכים למערכת האנליטיקס. ואל תחברו אחוזים: השיפורים חופפים זה לזה, אז מדדו את התוצאה המשולבת במקום לסכם את התרומה של כל תיקון. צ'קליסט הביצועים שלי מכסה את אותם נושאים ב-20 סעיפים שאפשר לסמן.