שיווק דיגיטלי

האתר נטען לאט וקשה ליצור קשר: איך מאתרים בעיות באתר של עסק קטן

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

פורסם 6 דקות קריאה

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

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

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

קודם בודקים מה הלקוח מנסה לעשות

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

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

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

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

תמונות גדולות יכולות להכביד על אתר קטן

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

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

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

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

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

תוספים, חלונות קופצים ואחסון צריכים אבחון

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

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

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

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

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

הסרטון ייטען מ-YouTube רק אחרי לחיצה

בטלפון נייד בודקים גם קריאה ולחיצה

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

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

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

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

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

ציון מהירות הוא תחילת הבירור

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

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

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

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

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

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

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

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

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

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

לכל הכתבות בשיווק דיגיטלי