שיפור מהירות אתרים הוא העבודה שגורמת לעמוד להופיע מהר, להגיב מיד ללחיצה ולא לקפוץ בזמן הטעינה. גוגל מודדת את שלושת הדברים האלה אצל גולשים אמיתיים, והם משפיעים גם על הדירוג וגם על כמה לקוחות נשארים באתר.
גוגל כותבת במפורש שמדדי חוויית הדף, ובראשם Core Web Vitals, משמשים את מערכות הדירוג שלה. באותו עמוד היא גם מבהירה שהיא תמיד תעדיף את התוכן הרלוונטי ביותר, גם כשחוויית הדף שלו לא מושלמת (ההסבר של גוגל על חוויית הדף). כלומר מהירות לא תעלה עמוד חלש למקום הראשון, אבל כשכמה עמודים טובים מתחרים על אותו ביטוי, אתר איטי מתחיל מאחור.
הנזק הגדול יותר הוא אצל הלקוחות. מי שמחפש בנייד ומחכה לעמוד שלא נטען חוזר לגוגל ולוחץ על התוצאה הבאה. אתם משקיעים בקידום, הגולש מגיע, ונעלם לפני שראה מה אתם מוכרים. לכן אני מתייחס לשיפור מהירות אתרים כחלק מקידום אתרים טכני, ולא כפרויקט שעושים פעם אחת ושוכחים.
ויש גם צד טכני. כשהשרת של האתר עונה לאט, הבוט של גוגל סורק פחות עמודים ביום כדי לא להעמיס עליו. באתר קטן זה כמעט לא מורגש. באתר עם מאות עמודים ומוצרים זה אומר שעמודים חדשים ועדכונים נכנסים לגוגל לאט יותר.
הכלי הראשון לבדיקת מהירות אתר הוא PageSpeed Insights של גוגל. מזינים את כתובת העמוד, בוחרים נייד, ומקבלים באותו מסך שני דברים שונים לגמרי. רוב האנשים מסתכלים רק על השני.
בחלק העליון מופיעים נתונים מגולשים אמיתיים שנכנסו לאתר בכרום בארבעת השבועות האחרונים. זה מה שגוגל מודדת, וזה מה שמשפיע על הדירוג. החלק הזה מופיע רק כשלאתר יש מספיק תנועה, ובאתרים קטנים הוא לפעמים ריק.
מתחתיו מופיע הציון המפורסם, המספר בעיגול. הוא נמדד בבדיקה אחת במעבדה, על טלפון מדומה וחיבור איטי, והוא משתנה מבדיקה לבדיקה. ציון של 90 ומעלה מסומן בירוק, 50 עד 89 בכתום, ומתחת לחמישים באדום. הציון טוב כדי למצוא בעיות, אבל אתר יכול לקבל 60 במעבדה ולעבור את כל המדדים אצל גולשים אמיתיים, וגם להפך.
הכלי השני כבר נמצא אצלכם אם האתר מחובר לסרץ' קונסול. דוח Core Web Vitals שם מראה אילו קבוצות עמודים איטיות, בנייד ובמחשב בנפרד. כאן רואים אם הבעיה היא בעמוד אחד או בכל עמודי המוצר, וזה ההבדל בין תיקון של שעה לבין שינוי בתבנית.
לבדיקת מהירות אתר לעומק, כשצריך להבין למה עמוד איטי ולא רק כמה, אלה הכלים שאני עובד איתם:
כאן אפשר לבדוק גם את מהירותם של רכיבי וורדפרס שונים כדי לנטר ביעילות רבה את הבעיה. כדאי להשתמש בסכימת Waterfall כדי לבחון תמונות, גופנים, CSS ועוד מרכיבים שצריכים אופטימיזציה.
אחד הכלים הפופולריים ביותר לבדיקת מהירות האתר, שמציג את מהירות האתר, משקל העמוד, כמות הבקשות מהשרת, זמני טעינה ועוד. הכל בתצוגה שמכילה את פילוח המידע בהתאם לסוג התוכן באתר, לפי דומיין, משקל ונתונים נוספים.
הכלי הזה מאתר דברים נוספים שמאטים את האתר כמו תוספים מסוימים, שאילתות ועוד.
כאן אפשר לבדוק את המהירות לפי אופן הבקשות מהאתר בסדר כרונולוגי ולקבל פילוח דומה לזה של פינגדום, הכולל מידע לפי משקל, סוג תוכן, דומיין, כמות בקשות ועוד.
הכלי הרשמי של גוגל שבודק את המהירות של האתר במובייל ודסקטופ. הכלי מציג בעיות קיימות שאותרו ובעיות שקיימות אצל גולשים מהסלולר.
המהירות משתנה מעמוד לעמוד לפי התמונות, הסקריפטים והתוכן שיש בו. עמוד הבית הוא רק התחלה. כדאי לבדוק גם עמוד שירות, מאמר ועמוד מוצר, כי בדרך כלל שם מסתתרת הבעיה שהלקוחות באמת פוגשים.
תוסף מטמון יכול להעלות את הציון בכמה נקודות, אבל אם השרת איטי והתמונות כבדות, האתר יישאר איטי. לפני שמתקנים משהו צריך להבין מה תופס את רוב הזמן בטעינה, ולהתחיל משם.
גוגל מסכמת את חוויית הגולש בשלושה מדדים שנקראים יחד Core Web Vitals. כדי שעמוד יעבור, לפחות 75 אחוז מהכניסות אליו צריכות לעמוד ביעד של כל אחד מהם (ההגדרות הרשמיות של גוגל).
הזמן עד שהאלמנט הגדול במסך, בדרך כלל התמונה הראשית או הכותרת, נטען ומוצג. היעד הוא 2.5 שניות לכל היותר. כשהמדד הזה נכשל, האשמים הנפוצים הם שרת שעונה לאט ותמונה ראשית כבדה.
הזמן שעובר מהרגע שהגולש לוחץ על כפתור או פותח תפריט ועד שהמסך משתנה. היעד הוא 200 אלפיות שנייה לכל היותר. גוגל הכניסה אותו במרץ 2024 במקום המדד הקודם, שבדק רק את הלחיצה הראשונה. מה שמאט אותו הוא בעיקר קוד כבד מבוני עמודים ומסקריפטים חיצוניים.
בכל פעם שטקסט זז למטה כי נטענה מעליו תמונה או באנר, זה נספר. היעד הוא 0.1 לכל היותר. זה המדד שהכי קל לתקן, בדרך כלל בהגדרת רוחב וגובה לתמונות ולמודעות.
בדוח של PageSpeed תראו גם מונחים כמו FCP, TBT וגם Speed Index. אלה מדדי מעבדה שעוזרים למצוא את מקור הבעיה, אבל הם לא מה שגוגל בודקת אצל הגולשים. מדד TTI, שעוד מופיע בהרבה מדריכים, כבר הוסר מהבדיקה של גוגל.
האחסון הוא הבסיס. אם השרת לוקח שנייה רק כדי להתחיל לענות, שום תוסף לא יציל את האתר. ברוב המקרים שאני רואה, מעבר מאחסון משותף זול לשרת מנוהל עם משאבים קבועים משפר את זמן התגובה יותר מכל פעולה אחרת ברשימה.
חשוב גם איפה השרת יושב. שרת בישראל או במרכז אירופה, למשל בגרמניה או בהולנד, עונה לגולשים בישראל מהר יותר משרת בארצות הברית. את השיקולים בבחירת ספק פירטתי במאמר על אחסון אתרים.
ברוב האתרים התמונות הן החלק הכבד ביותר בעמוד. תמונה שצולמה בטלפון שוקלת כמה מגה, ובאתר היא צריכה לשקול עשרות קילובייט. לכן מקטינים כל תמונה לגודל שבו היא באמת מוצגת, דוחסים אותה, וממירים לפורמט WebP או AVIF שקלים בהרבה מהפורמטים הישנים.
בוורדפרס עושים את זה עם תוסף כמו ShortPixel, EWWW או Optimole, שמטפל גם בתמונות שכבר באתר וגם בכל תמונה חדשה שעולה. עוד שני דברים קטנים שעושים הבדל: להגדיר לכל תמונה רוחב וגובה כדי שהעמוד לא יקפוץ, ולא לדחות את טעינת התמונה הראשית בראש העמוד, כי לפיה גוגל מודדת מתי התוכן הראשי הופיע.
מטמון שומר עותק מוכן של כל עמוד, כך שהשרת לא צריך לבנות אותו מחדש לכל גולש. זה אחד השיפורים הגדולים באתר וורדפרס, ואני עובד בעיקר עם WP Rocket. כשחברת האחסון מספקת מטמון ברמת השרת, לפעמים הוא עדיף על תוסף.
חשוב לא להתקין שני תוספי מטמון במקביל. הם מתנגשים, ולפעמים הגולש מקבל גרסה ישנה של העמוד או עמוד שבור.
כל משקל של פונט הוא קובץ נפרד שהדפדפן מוריד. אתר שטוען ארבעה משקלים של שני פונטים משרתי גוגל שולח את הגולש לשרת חיצוני עוד לפני שהטקסט מופיע.
הפתרון הוא להשאיר רק את המשקלים שבאמת בשימוש, לארח את הפונט על השרת של האתר, ולהגדיר אותו כך שהטקסט יוצג מיד בפונט זמני ולא יישאר ריק עד שהפונט נטען.
לפני שהדפדפן מציג משהו, הוא מוריד ומפענח את קבצי העיצוב והקוד של האתר. באתר וורדפרס עם תבנית כבדה ועשרים תוספים מדובר בעשרות קבצים, וחלק גדול מהם לא נחוץ בעמוד שהגולש פתח.
מכווצים את הקבצים, דוחים את הקוד שלא נחוץ מיד, ומבטלים בכל עמוד את מה שלא בשימוש בו. כלים כמו WP Rocket, Perfmatters וגם Autoptimize עושים את זה, אבל כל שינוי כאן יכול לשבור תפריט או טופס. לכן שומרים גיבוי ובודקים את האתר אחרי כל צעד.
טעינה עצלה דוחה את הטעינה של תמונות, סרטונים ומפות עד שהגולש גולל אליהם. כך העמוד מציג קודם את מה שנראה במסך הראשון, ואת השאר רק כשצריך. סרטון יוטיוב מוטמע, למשל, טוען הרבה קוד עוד לפני שמישהו לחץ עליו, ותמונה מקדימה במקומו חוסכת את כל זה.
הטעות הנפוצה היא להפעיל טעינה עצלה גם על התמונה הראשית בראש העמוד. היא נדחית, ודווקא המדד שגוגל בודקת נפגע.
קישורים לקבצים שכבר לא קיימים, תוסף שמייצר שגיאות בכל טעינה, או סקריפט שמחכה לשרת שלא עונה. כל אחד מאלה מוסיף זמן לכל כניסה. את רובם רואים בכלי המפתחים של כרום ובתוסף Query Monitor, והתיקון תלוי במקור. לפעמים מספיק לעדכן תוסף, ולפעמים צריך מתכנת.
כמעט בכל אתר וורדפרס שאני בודק יש תוספים שהותקנו לניסיון ונשכחו. תוסף פעיל טוען קוד גם כשלא משתמשים בו, ותוסף כבוי שנשאר באתר הוא פתח לבעיות אבטחה. עוברים על הרשימה ושואלים על כל תוסף אם הוא עושה משהו שהאתר צריך. אם לא, מוחקים.
תבניות עם סליידרים, אנימציות וחמישים אפשרויות עיצוב טוענות את כל הקוד שלהן גם כשאתם משתמשים בשתיים. בוני עמודים כמו אלמנטור נוחים מאוד, אבל כל שכבה שלהם מוסיפה קוד לעמוד. לא תמיד צריך להחליף תבנית. לרוב מספיק לכבות רכיבים שלא בשימוש ולפשט את העמודים הכבדים. על הצד הזה כתבתי גם בעמוד על קידום אתרי וורדפרס.
צ'אט, פיקסלים של פייסבוק וטיקטוק, מפות, רכיבי נגישות ותגיות מעקב. כל אחד מהם נטען משרת של חברה אחרת, ואתם לא שולטים במהירות שלו. ברוב האתרים כאן נמצא החלק הגדול של העיכוב בתגובה ללחיצות.
עוברים על כל סקריפט ושואלים אם מישהו עדיין משתמש בנתונים שלו. את מה שנשאר טוענים רק אחרי שהעמוד מוצג, או רק בעמודים שבהם הוא נחוץ.
רשת הפצת תוכן (CDN) שומרת עותקים של קבצי האתר בשרתים ברחבי העולם, וכל גולש מקבל אותם מהשרת הקרוב אליו. לאתר שכל הגולשים שלו בישראל והשרת שלו כבר קרוב, התועלת קטנה יותר. היא גדולה באתרים עם קהל בחו"ל, הרבה תמונות או תנועה גבוהה, ושירות כמו Cloudflare נותן גם הגנה מפני תעבורה זדונית.
לפני שהגולש רואה משהו, השרת צריך לקבל את הבקשה, להריץ את וורדפרס, לשלוף נתונים ממסד הנתונים ולשלוח את העמוד. הזמן הזה נקרא זמן תגובת השרת, ובדוח של PageSpeed הוא מופיע תחת השם TTFB. צוות כרום של גוגל ממליץ שהוא יהיה 0.8 שניות לכל היותר (ההמלצה המלאה), וכשהוא גבוה, כל שאר השיפורים מתחילים ממקום רע.
חלק מזה הוא האחסון עצמו, שעליו כתבתי למעלה. אבל גם באחסון טוב יש ארבעה דברים בצד השרת שאני בודק בכל אתר, כי הם משפיעים על כל עמוד ועל כל גולש.
וורדפרס רץ על שפת תכנות שנקראת PHP, ולכל גרסה חדשה שלה יש שיפורי ביצועים. הרבה אתרים ותיקים עדיין רצים על גרסה ישנה, פשוט כי אף אחד לא שינה את ההגדרה בחברת האחסון. העדכון עצמו לוקח דקה, אבל לפניו בודקים שהתבנית והתוספים תומכים בגרסה החדשה, אחרת האתר עלול להישבר.
השרת יכול לכווץ כל קובץ טקסט, כמו העמוד עצמו וקבצי העיצוב והקוד, לפני שהוא שולח אותו לדפדפן. הדחיסה הנפוצה נקראת Gzip, והחדשה והיעילה יותר נקראת Brotli. ברוב חברות האחסון היא כבר פעילה, אבל לא בכולן, ואם היא חסרה תופיע על כך אזהרה בדוח של PageSpeed.
מסד הנתונים של וורדפרס צובר עם השנים אלפי גרסאות שמורות של עמודים, תגובות ספאם ושאריות של תוספים שכבר נמחקו. באתר קטן זה כמעט לא מורגש. באתר עם אלפי מוצרים או שנים של תוכן, ניקוי של המסד והגבלת מספר הגרסאות השמורות מקצרים את הזמן שלוקח לשרת לבנות כל עמוד.
באתרים גדולים, ובמיוחד בחנויות, אותן שאלות למסד הנתונים חוזרות שוב ושוב בכל כניסה. מטמון אובייקטים, למשל Redis, שומר את התשובות בזיכרון של השרת כך שלא צריך לחשב אותן מחדש. בחלק מחברות האחסון המנוהלות מפעילים אותו בלחיצה, ובאתר תדמית קטן הוא בדרך כלל לא נחוץ.
הטעות הראשונה היא לרדוף אחרי 100. ההפרש בין ציון 85 לציון 100 כמעט לא מורגש לגולש ולא משנה את הדירוג, אבל כדי להגיע אליו מוותרים לפעמים על צ'אט שמביא פניות או על תמונה שמוכרת את המוצר. המטרה היא לעבור את שלושת המדדים אצל גולשים אמיתיים, לא לנצח את המעבדה.
הטעות השנייה היא לערום תוספים. שלושה תוספי מהירות שעושים אותו דבר מתנגשים זה בזה, ובסוף האתר גם איטי וגם שבור. תוסף אחד שמוגדר נכון עדיף על חמישה שמותקנים עם הגדרות ברירת מחדל.
והשלישית היא לבדוק רק במחשב. רוב הגולשים מגיעים מהנייד, על חיבור סלולרי, וגוגל מדרגת לפי גרסת הנייד של האתר. אתר שעף במחשב יכול להיות איטי מאוד בטלפון, ועל זה הרחבתי במאמר על קידום אתרים בסלולר.
אני מתחיל בבדיקה: נתוני הגולשים האמיתיים מגוגל, דוח Core Web Vitals בסרץ' קונסול, ובדיקה של כמה סוגי עמודים באתר. מהבדיקה יוצאת רשימה של מה מאט את האתר, מסודרת לפי כמה זמן כל דבר גוזל בטעינה, ומתחילים מהגדול לקטן.
העבודה נעשית על האתר שלכם עם גיבוי לפני כל שינוי, ואחרי כל צעד בודקים שהטפסים, התפריטים והקופה עובדים. בין הכלים שאני משתמש בהם: WP Rocket למטמון, Perfmatters לביטול קוד מיותר בכל עמוד, אחסון מנוהל, ורשת הפצת תוכן כשהיא מתאימה לאתר.
לקוחות שעובדים איתי על קידום אורגני לתקופה של חצי שנה לפחות מקבלים את שיפור המהירות כחלק מהעבודה. אפשר להזמין שיפור מהירות אתרים גם כשירות נפרד, בתשלום. המחיר נקבע אחרי הבדיקה, כי אתר תדמית של עשרה עמודים וחנות עם אלפי מוצרים הם שתי עבודות שונות לגמרי.
אין תוסף אחד שפותר הכל. תוסף מטמון כמו WP Rocket נותן את הקפיצה הגדולה ביותר ברוב אתרי הוורדפרס, ותוסף כמו Perfmatters עוזר לבטל קוד שלא נחוץ בכל עמוד. אבל אם השרת איטי או שהתמונות כבדות, אף תוסף לא יסגור את הפער, ולכן מתחילים בבדיקה ולא בהתקנה.
כן, אבל פחות ממה שנהוג לחשוב. גוגל משתמשת במדדי Core Web Vitals כחלק משיקולי הדירוג, ובמקביל מבהירה שתוכן רלוונטי יקבל עדיפות גם כשהחוויה שלו לא מושלמת. בפועל מהירות מכריעה בין עמודים טובים ברמה דומה, והיא משפיעה בעיקר על כמה מהגולשים נשארים ופונים אליכם.
לפי ההגדרות של גוגל, התוכן הראשי צריך להופיע תוך 2.5 שניות לכל היותר, העמוד צריך להגיב ללחיצה תוך 200 אלפיות שנייה, והתזוזה של העמוד בזמן הטעינה לא צריכה לעבור את 0.1. היעדים האלה נמדדים על 75 אחוז מהכניסות לעמוד, בנייד ובמחשב בנפרד.
הציון נמדד בבדיקה בודדת על טלפון מדומה ובחיבור מדומה, והוא מושפע מהעומס על השרת ומסקריפטים חיצוניים באותו רגע. הבדל של חמש עד עשר נקודות בין בדיקות הוא רגיל. כדי לדעת איך האתר באמת מתנהג, מסתכלים על נתוני הגולשים האמיתיים בראש הדוח או בסרץ' קונסול.
המחיר נקבע אחרי בדיקה של האתר, כי ההיקף משתנה מאוד בין אתר תדמית קטן לחנות עם אלפי מוצרים. לקוחות שמתקדמים איתי בקידום אורגני לחצי שנה לפחות מקבלים את שיפור המהירות כחלק מהעבודה. כשירות נפרד, הוא ניתן בתשלום לפי מה שהבדיקה מצאה.
שנדבר על איך אפשר להתברג בעמוד הראשון בגוגל?
השאירו פרטים ואחזור אליכם בהקדם.
מעדיפים לדבר? 052-8211117 או וואטסאפ
"אנו משתמשים בקובצי עוגיות (Cookies) כדי לשפר את חווית הגלישה שלך, להציג לך תוכן מותאם אישית ולנתח את תנועת הגולשים. אנו גם משתפים מידע עם שותפינו בתחום המדיה החברתית והפרסום. למידע נוסף ניתן לקרוא את מדיניות העוגיות שלנו.
