אופטימיזציה של מדדי הליבה לבדיקת חוויית המשתמש באתר עבור מקבלי ההחלטות העסקיות

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

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

עם זאת, הרבה מסמכי תיעוד בנושא Core 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 ולוחצים על 'ניתוח'. אם האתר שלכם כלול ב-CrUX, אמורה להופיע במהירות ההודעה "לגלות את החוויה של המשתמשים האמיתיים". :

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

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

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

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

Google Search Console

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פרמטרים של כתובת 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 כשאין בהם צורך יותר.

בעיות שקשורות להתאמה מצטברת של הפריסה (CLS)

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

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

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

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

איך בודקים איך התמונות נטענות בזמן הגלילה בדף

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

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

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

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

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

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

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

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

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

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

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

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

ניקיון פסח!

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

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

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

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

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

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

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

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

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

להימנע מגודל דפים גדול מדי

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

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

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

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

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

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

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

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

פנייה למפתחי אתרים

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

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

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

סיכום

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

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

אישורים

תמונה ממוזערת מאת קרלוס מוזה בביטול הפתיחה