אופטימיזציה של דוח ה-Web Vitals הבסיסיים למקבלי החלטות עסקיות

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

מבוא

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

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

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

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

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

מהם מדדי הליבה לבדיקת חוויית המשתמש באתר?

מדדי הליבה לבדיקת חוויית המשתמש באתר הם קבוצה של שלושה מדדים, שנועדו למדוד את חוויית המשתמש בדף – ובמיוחד את מהירות הדף מבחינת המשתמשים. לכל אחת יש שלוש אותיות באנגלית:

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

איך נמדדים מדדי הליבה לבדיקת חוויית המשתמש באתר?

מדדי הליבה לבדיקת חוויית המשתמש באתר נמדדים לפי המשתמשים האמיתיים באתר. למשתמשים שונים יהיו תוצאות שונות. הם לא 'מה Google חושבת' או 'מה googlebot חושב', אלא מה חוו המשתמשים באתר שלכם בפועל.

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

Google מציגה את הנתונים ממשתמשי Chrome שהביעו הסכמה עבורם בדוח חוויית המשתמש ב-Chrome (CrUX), שמטמיע כלים רבים של Google, כמו PageSpeed Insights ו-Google Search Console.

CrUX זמין במיליוני אתרים פופולריים, אבל לא כל האתרים נכללים ב-CrUX. גם כלים אחרים של Real User Monitoring (RUM) יכולים לאסוף את המדדים האלה עבור האתר שלכם.

איך אפשר למצוא את מדדי הליבה לבדיקת חוויית המשתמש באתר?

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

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

PageSpeed Insights

כדי לקבל תצוגה מהירה שלא מחייבת הגדרה, ניתן להשתמש ב-PageSpeed Insights (PSI). מקלידים את כתובת ה-URL ולוחצים על 'ניתוח'. אם האתר שלכם נכלל ב-CUX, אמור להופיע במהירות הקטע 'מה המשתמשים האמיתיים שלך חווים':

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

הדוח מראה איך משתמשי Chrome אמיתיים חוו את האתר שלך ב-28 הימים האחרונים. שלושת המדדים הבסיסיים של חוויית המשתמש יוצגו בחלק העליון של הדף, ומתחתיו מדדים תומכים נוספים (כולל המדד 'INP בהמתנה'). רק הנתונים במדדי הליבה לבדיקת חוויית המשתמש באתר נספרים בהערכה הכוללת של עברו/נכשלים בחלק העליון של הדף. עם זאת, שאר המדדים יכולים לעזור בפתרון בעיות שקשורות למדדי ליבה לבדיקת חוויית המשתמש באתר, כפי שמתואר בקטע הבא.

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

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

Google Search Console

שירות Google Search Console (GSC) מיועד לבעלי אתרים בלבד, לכן השימוש בו מחייב רישום ואימות של הבעלות על האתר. פרטים על האופן שבו האתר שלכם מוצג בחיפוש Google.

שלא כמו PageSpeed Insights, ב-GSC מפורטים כל הדפים באתר שלכם שאתם מכירים את חיפוש Google, והוא מספק פרטים לגבי מדדי הליבה לבדיקת חוויית המשתמש באתר:

צילום מסך של דוח מדדי ליבה לבדיקת חוויית המשתמש באתר ב-Search Console. הדוח מחולק לקטגוריות למחשבים ולניידים, עם תרשימי קו שמפרטים את ההתפלגות של דפים עם מדדי ליבה לבדיקת חוויית המשתמש באתר בקטגוריות 'טוב', 'טעון שיפור' ו 'איטיים' לאורך זמן.
דוח מדדי הליבה לבדיקת חוויית המשתמש באתר של Google Search Console.

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

בעיות נפוצות במדדי הליבה לבדיקת חוויית המשתמש באתר של כלים לבניית אתרים

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

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

הבעיות מסוג Largest Contentful Paint (LCP)

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

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

כדי שחוויית השימוש בדף תהיה טובה, צריך שתוכן דף האינטרנט יוצג בתוך 2.5 שניות מרגע הלחיצה על הקישור. אם הטעינה נמשכת יותר מ-4 שניות, החוויה נחשבת גרועה.

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

עיכובים בהתחלת טעינת הדף

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

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

מנסים להבין מה רמת הידע של הקהל

בבעיות שקשורות ל-TTDFB, חשוב להבין את הקהל שלך. אם האתר שלכם מתארח במדינה אחת, אבל מוצג לקהל בינלאומי, הקרבה הגיאוגרפית בין המשתמשים באתר לבין שרת האינטרנט שלכם הופכת לגורם ב-TTFB של הדף. רשת להעברת תוכן (CDN) מאפשרת לשמור עותקים של האתר שלכם במטמון ברחבי העולם, ולכן קרוב יותר למשתמשים. ספקי אירוח רבים כוללים CDN כחלק מהשירותים שלהם, והם יטפלו בזה באופן אוטומטי. בודקים אם זה המצב במקום שבו האתר מתארח. פלטפורמות מסוימות מציעות רמות שירות שונות עם יותר מיקומי CDN לרמות גבוהות יותר בתשלום. במקרים כאלה, עסקים גלובליים צריכים לשקול רמות גבוהות יותר.

צמצם הפניות מחדש

הפניות אוטומטיות הן סיבה נפוצה נוספת לקובצי TTFB איטיים. כשמריצים קמפיינים פרסומיים או שולחים הודעות אימייל, כדאי לצמצם את מספר ההפניות לכתובות אחרות על ידי הימנעות משימוש בכמה מקצרי קישורים, או בהכללה של כתובות URL שצריכות להפנות משתמשים לכתובת אחרת. לדוגמה, שימוש ב-example.com/blog בקמפיין שצריך להפנות אליו מחדש אל www.example.com/blog, שמפנה אל https://www.example.com/blog יוסיף זמן ל-TTFB של הדף. ודאו שבקמפיינים השיווקיים שלכם נעשה שימוש במספר המינימלי האפשרי של הפניות לכתובות URL אחרות.

לוודא שהקמפיינים פונים לקהל הנכון

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

פרמטרים של כתובות אתרים יכולים להשפיע על הביצועים באינטרנט

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

מדיה יכולה להיות יקרה בגלל ביצועים

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

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

הימנעות מקרוסלות

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

שימוש בתמונות שמותאמות לאינטרנט

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

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

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

בדיקות A/B

עסקים רבים עורכים בדיקות A/B כדי להתנסות בשינויים באתר שלהם. לאופן היישום שלהם יכולה להיות השפעה משמעותית על LCP.

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

בדיקות A/B יכולות לספק משוב מועיל לפני השקת שינויים חדשים, אבל יש לשקלל את העלות של ביצועי הדף מול היתרונות הפוטנציאליים של השינויים.

ללא קשר לתשתית שלכם, כל מי שמפעיל בדיקות A/B תמיד צריך לזכור את השיטות המומלצות הבאות:

  • הגבילו את הכלים לבדיקת A/B רק לדפים שנכללים בבדיקה, במקום לעכב את כל הדפים, במקרים שבהם ייתכן שברוב הדפים לא תופעל בדיקת A/B בזמן מסוים.
  • כדאי להגביל את השימוש בבדיקות A/B רק לקבוצה מצומצמת של משתמשים, כדי שהשינוי הזה לא ישפיע על רוב המשתמשים.
  • כדאי להגביל את השימוש בבדיקות A/B לפרק הזמן המינימלי הדרוש כדי לקבל תוצאות חד-משמעיות. ככל שבדיקות A/B יהיו ארוכות יותר, כך הביצועים של הדפים יהיו נמוכים יותר אצל משתמשים ארוכים יותר.
  • והכי חשוב: אל תשכחו להסיר את הניסויים בבדיקות A/B כשאין בהם יותר צורך.

בעיות ב-Cumulative Layout Shift (CLS)

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

הקלטת מסך שממחישה איך חוסר יציבות בפריסה עלול להשפיע לרעה על משתמשים.

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

בקטעים הבאים מתוארות חלק מהבעיות הנפוצות שמשפיעות על ה-CLS, שמקבלי ההחלטות העסקיות עשויות להשפיע עליהן.

כשגוללים למטה בדף, אפשר לבדוק את מהירות הטעינה של התמונות

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

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

כדאי להיזהר כשמציבים מודעות באמצע התוכן

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

להימנע מהוספת תוכן דינמי לחלק העליון של הדפים.

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

בעיות מאינטראקציה ועד הצגת התגובה (INP)

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

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

INP מודד את הפעילות בשלמותה של כל אינטראקציה כשירה במהלך חיי הדף, ומדווח על האינטראקציה הגרועה ביותר. ל-INP יש סף טוב של 200 אלפיות השנייה, וסף חלש של 500 אלפיות השנייה. מדד INP הוא שיפור ל-FID, ומודד טוב יותר את הרספונסיביות, לכן הוא החליף את FID כמדד ליבה לבדיקת חוויית המשתמש באתר למדידת תגובה.

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

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

מאחלים לך ניקיון פסח!

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

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

להימנע מווידג'טים ומיישומי פלאגין יקרים

ווידג'טים ויישומי פלאגין יקרים מבחינה חישובית עשויים להיראות טוב, אבל האם הם משפרים את חוויית המשתמש או הופכים אותה לגרועה יותר? הדוח 'אבחון בעיות בביצועים/מגדלור' ב-PageSpeed Insights יכול לעזור בזיהוי של JavaScript עם השפעה משמעותית על ביצועי האתר.

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

כדאי להביא בחשבון את מספר המודעות – במיוחד בניידים

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

האיזון בין מונטיזציה לביצועים.

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

מומלץ להימנע מגודל דף גדול מדי

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

איך אפשר לקבל עזרה נוספת?

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

מידע ספציפי לפלטפורמה

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

בנוסף, חברת Lighthouse מציגה מידע ספציפי לפלטפורמה באמצעות הפונקציונליות של Stack Pack, שיכולה להנחות את המשתמשים בפלטפורמות נתמכות לייעוץ מתאים.

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

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

מעורבות של מפתח אתרים

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

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

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

סיכום

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

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

אישורים

תמונה ממוזערת מאת קרלוס מוזה ב-UnFlood