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

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

מבוא

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

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

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

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

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

מהם Core Web Vitals?

‫Core Web Vitals היא קבוצה של שלושה מדדים שנועדו למדוד את חוויית המשתמש בדף, ובמיוחד את המהירות שבה המשתמשים חווים את הדף. לכל אחד מהם יש קיצור של שלוש אותיות:

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

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

איך נמדדים מדדי ה-Core Web Vitals?

‫Core Web Vitals נמדדים על ידי המשתמשים האמיתיים של האתר, ולמשתמשים שונים יהיו תוצאות שונות. הם לא מייצגים את "מה ש-Google חושבת" או את "מה ש-Googlebot חושב", אלא את מה שהמשתמשים באתר שלכם חוו בפועל.

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

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

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

איך אפשר למצוא את מדדי ה-Core Web Vitals של האתר?

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

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

PageSpeed Insights

כדי לקבל תצוגה מהירה שלא דורשת הגדרה, אתם יכולים להשתמש ב-PageSpeed Insights‏ (PSI). מקלידים את כתובת ה-URL ולוחצים על Analyze (ניתוח). אם האתר שלכם נכלל ב-CrUX, יוצג לכם במהירות הקטע "רוצה נתונים על החוויה של המשתמשים בפועל?":

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

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

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

Google Search Console

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

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

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

בעיות נפוצות ב-Core Web Vitals למפתחי אתרים

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

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

בעיות שקשורות למהירות שבה נטען רכיב התוכן הכי גדול (LCP)

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

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

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

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

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

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

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

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

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

הפניות אוטומטיות הן סיבה נפוצה נוספת ל-TTFB איטי. כשמפעילים קמפיינים פרסומיים או שולחים הודעות אימייל, כדאי לצמצם את מספר ההפניות לכתובות URL אחרות. לשם כך, אל תשתמשו בכמה מקצרי קישורים ואל תכללו כתובות 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 כשכבר לא צריך אותם.

בעיות שקשורות למדד יציבות חזותית (CLS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניקיון פסח!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום

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

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