הרצתם את אתר הוורדפרס שלכם ב-GTmetrix, קיבלתם ציון C, ומביטים בקיר של המלצות שלא ממש מבינים. נשמע מוכר? רוב האנשים או מתעלמים מהדוח או מתחילים ללחוץ על הגדרות אקראיות בתוסף כלשהו בתקווה שמשהו יעבוד. אף אחת מהגישות האלה לא תוביל לשיפור מהירות וורדפרס אמיתי.
GTmetrix הוא אחד הכלים החינמיים השימושיים ביותר לאבחון בעיות מהירות, אבל רק אם יודעים לקרוא אותו נכון. המדריך הזה יעבור בדיוק על איך להשתמש בו, מה המספרים באמת אומרים, ואילו תיקונים שווים את הזמן שלכם.
מה GTmetrix בעצם מודד
GTmetrix טוען את הדף שלכם בדפדפן אמיתי ממיקום שרת בדיקה מסוים, ומתעד כל מה שקורה: כל קובץ שנטען, כמה זמן לקח לכל אחד, ואיך הדף נראה ויזואלית לאורך זמן.
הוא מציג שני סטים עיקריים של נתונים:
- ציון GTmetrix וציון ביצועים - ציון כללי המבוסס על שיטות עבודה מומלצות ועל Core Web Vitals
- Web Vitals - Largest Contentful Paint (LCP), Total Blocking Time (TBT), ו-Cumulative Layout Shift (CLS)
הציון הכללי נחמד להתרברב בו, אבל ה-Web Vitals הם מה שבאמת חשוב. אלה אותם מדדים ש-Google משתמשת בהם כדי לשפוט את חוויית הדף, אז שיפור שלהם עוזר גם למשתמשים אמיתיים וגם לנראות שלכם בחיפוש.
הגדרת הבדיקה הראשונה שלכם בצורה נכונה
לפני שאתם מריצים בדיקה, כדאי לכוון שתי הגדרות שרוב האנשים מדלגים עליהן:
- מיקום הבדיקה - בחרו מיקום קרוב לאזור שבו נמצאים רוב המבקרים שלכם בפועל. בדיקה מסידני כשהקהל שלכם בשיקגו תיתן לכם נתונים מטעים.
- דפדפן וחיבור - בדקו גם במחשב וגם בחיבור סלולרי מואט. תוצאות במובייל בדרך כלל גרועות יותר ולעיתים קרובות מייצגות טוב יותר את המשתמשים האמיתיים.
הריצו את הבדיקה שלוש פעמים והסתכלו על הממוצע. בדיקה בודדת יכולה להיות מוטה בגלל רגע איטי בשרת הבדיקה או אצל הספק שלכם.
קריאת תרשים ה-Waterfall
תרשים ה-Waterfall הוא החלק השימושי ביותר בדוח, וגם החלק שרוב האנשים מדלגים עליו כי הוא נראה מפחיד. כל שורה מייצגת קובץ שהדפדפן שלכם הוריד, מסודר על ציר זמן.
חפשו את הדפוסים הבאים:
- פסים ירוקים ארוכים בתחילת התרשים - זה בדרך כלל מצביע על תגובת שרת איטית (Time to First Byte גבוה). אם הבקשה הראשונה שלכם לוקחת יותר מ-600 מילישניות, כנראה שסביבת האחסון או ביצועי ה-PHP הם צוואר הבקבוק, לא קוד ה-front-end.
- קבצים גדולים שנטענים אחד אחרי השני - CSS ו-JavaScript חוסמי רינדור שנטענים לפני שמשהו נראה על המסך. זו סיבה נפוצה ל-TBT גבוה.
- עשרות בקשות תמונה קטנות - סימן שהתמונות שלכם לא עברו אופטימיזציה או שאין להן טעינה עצלה (lazy loading).
אם אתם רוצים צלילה עמוקה יותר לקריאת דוחות מסוג waterfall בלי להסתבך בפרטים, כתבנו על זה באיך למדוד זמן טעינת דף עם כלים שבאמת אומרים לכם משהו שימושי.
תיקון האזהרות הנפוצות ביותר של GTmetrix
1. הקטנת Time to First Byte (TTFB)
אם GTmetrix מסמן TTFB איטי, שום שינוי בצד הלקוח לא יתקן את זה. המדד הזה מודד כמה מהר השרת שלכם מגיב עוד לפני שהדפדפן בכלל מתחיל להוריד את הדף. הגורמים כוללים מסד נתונים לא מתוחזק, היעדר caching בצד השרת, או תוכנית אחסון שפשוט חלשה מדי לתעבורה שלכם.
caching ברמת השרת והגדרת PHP מכוונת נכון פותרים את זה מהשורש. זהו תחום אחד שבו האחסון שלכם באמת משנה, וכדאי לקרוא את למה ה-Time to First Byte שלכם עולה לכם בהמרות ואיך לתקן את זה אם זה ממשיך לצוץ בדוחות שלכם.
2. הסרת משאבים חוסמי רינדור
GTmetrix יסמן קבצי CSS ו-JavaScript שחוסמים את רינדור הדף. הפתרון הוא לדחות JavaScript שאינו קריטי ולשלב inline את מעט ה-CSS הדרוש לחלק הנראה של הדף (מה שנקרא לרוב critical CSS).
זה מסובך לעשות ידנית וקל לטעות. כדי לעשות את זה נכון בלי לשבור את העיצוב, בדרך כלל צריך לבדוק שינויים אחד בכל פעם בעותק staging של האתר, ולא באתר החי. אם הספק שלכם מציע סביבת staging, זה המקום להשתמש בה.
3. אופטימיזציה וטעינה עצלה של תמונות
תמונות שלא עברו אופטימיזציה עדיין מהוות את הגורם המספר אחד לאיטיות ברוב אתרי הוורדפרס. GTmetrix יגיד לכם בדיוק אילו תמונות גדולות מדי ובכמה. דחסו אותן, הגישו פורמטים מודרניים כמו WebP, והפעילו טעינה עצלה לכל מה שנמצא מתחת לחלק הנראה של הדף כדי שלא יתחרה עם התוכן הגלוי על רוחב פס.
כלי אוטומטי לאופטימיזציית תמונות מטפל בזה באופן שוטף ולא כניקוי חד-פעמי, כי תמונות חדשות מועלות כל הזמן.
4. הקטנת Total Blocking Time
TBT גבוה בדרך כלל אומר שיותר מדי JavaScript רץ ב-main thread מיד אחרי טעינת הדף. דחיית סקריפטים שאינם חיוניים (כמו ווידג'טים של צ'אט, אנליטיקס, או תוספים חיצוניים) עד שהמשתמש בפועל מתקשר עם הדף, יכולה לצמצם את זה משמעותית.
שגרת בדיקה חוזרת ומעשית
אל תשנו חמישה דברים ואז תריצו בדיקה אחת. לא תדעו מה באמת עזר. במקום זאת:
- הריצו בדיקת בסיס ושמרו את הדוח
- בצעו שינוי אחד
- בדקו שוב והשוו את המדד הספציפי שכיוונתם אליו
- שמרו את השינוי אם הוא עזר, בטלו אותו אם הוא הרע את המצב או שבר את העיצוב
- חזרו על התהליך
זה איטי יותר, אבל זו הדרך היחידה לבנות תמונה ברורה של מה שבאמת משפר את הציון שלכם, במקום לנחש.
למה תיקונים ברמת השרת עדיפים על ערימת תוספים
הרבה עצות בנושא מהירות וורדפרס אומרות להתקין חמישה תוספים שונים: אחד ל-caching, אחד לתמונות, אחד לצמצום קוד, ואחד לניקוי מסד הנתונים. כל אחד מהם מוסיף עומס משלו ופאנל הגדרות משלו, ולעיתים קרובות הם מתנגשים אחד עם השני.
גישה נקייה יותר היא לטפל באופטימיזציות האלה ברמת האחסון במקום לערום תוספים אחד על השני. שילוב של page caching עם object cache מבוסס Redis, לדוגמה, מסיר חלק גדול מהעומס על מסד הנתונים עוד לפני שתוסף בודד נכנס לתמונה. כתבנו עוד על שיפורים בצד מסד הנתונים בניקוי מסד נתונים לוורדפרס אם זה תחום ש-GTmetrix ממשיך לסמן אצלכם.
לסיכום
GTmetrix שימושי רק אם קוראים מעבר לציון האותיות. התמקדו ב-TTFB, במשאבים חוסמי רינדור, במשקל התמונות, וב-JavaScript חוסם, בסדר הזה, כי בדרך כלל להם יש את ההשפעה הגדולה ביותר. שנו דבר אחד, בדקו שוב, ושמרו את מה שעובד. עשו את זה בעקביות, ותהליך שיפור מהירות וורדפרס יביא לציון טוב יותר מעצמו.
