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

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

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

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

הדרכה

זמינות, אמינות, עמידות ויציבות

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

  • במאמר תיקון שרת עמוס מוסבר איך לזהות, לצמצם ולמנוע בעיות שקשורות לעלייה חדה בנפח התנועה.
  • הסירו תמונות, סרטונים, סקריפטים וגופנים מיותרים. חשוב לוודא שכל דף מתמקד רק בפונקציונליות שהמשתמשים באתר באמת צריכים.
  • אופטימיזציה של התמונות יכולה להפחית באופן משמעותי את השימוש ברוחב הפס של השרת, כי תמונות הן הגורם העיקרי לעומס באינטרנט.
  • העבירו כמה שיותר מהתוכן הסטטי שלכם לרשתות CDN. פרטים נוספים מספקים נפוצים: AWS, Azure, Cloudflare, Google Cloud, Firebase.
  • בדקו אם יש ב-CDN אופטימיזציות שקל להפעיל, כמו דחיסת תמונות דינמית, דחיסת טקסט או הקטנה אוטומטית של משאבי JS ו-CSS.
  • אופטימיזציה של שמירת נתונים במטמון של HTTP יכולה להפחית באופן משמעותי את העומס על השרתים, עם שינוי מינימלי בקוד. במאמר The HTTP cache: your first line of defense יש סקירה כללית, ובמאמרים HTTP caching ו-Caching best practices יש המלצות ספציפיות. הבדיקה Serve static assets with an efficient cache policy ב-Lighthouse יכולה לעזור לכם לזהות במהירות משאבים שלא נשמרים במטמון. חשוב לזכור שלסוגים שונים של משאבים יהיו דרישות שונות לגבי עדכניות, ולכן הם ידרשו אסטרטגיות שונות של שמירה במטמון.
  • Service workers הם דרך נוספת להפחית באופן משמעותי את העומס על השרתים, אבל יכול להיות שהם ידרשו השקעה טכנית משמעותית. הם גם מאפשרים לאתר לפעול במצב אופליין, כך שאתם יכולים להציג שעות פתיחה, מספרי טלפון ומידע אחר למשתמשים חוזרים בלי חיבור לאינטרנט. Workbox היא הגישה המומלצת להוספת קובצי Service Worker לאתרים, כי היא הופכת הרבה קוד סטנדרטי לאוטומטי, מקלה על יישום השיטות המומלצות ומונעת באגים קטנים שקורים בדרך כלל כשמשתמשים ישירות ב-API ברמה נמוכה של ServiceWorker.
  • אם השימוש באתר שלכם גדל באופן משמעותי, בדקו אם יש לכם הגנה מספקת מפני התקפות DDoS, כי יכול להיות שהאתר שלכם הפך ליעד אטרקטיבי יותר. פרטים נוספים מספקים נפוצים: AWS, Azure, Cloudflare, Google Cloud.

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

נגישות

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

זהות, אבטחה ופרטיות

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

הנחיות נוספות זמינות במאמר בטיחות ואבטחה.

נוחות השימוש, ממשק המשתמש וחוויית המשתמש

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

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

SEO

אנשים מחפשים מידע קריטי שקשור לבריאות ולעבודה. חשוב לוודא שכל מנועי החיפוש יכולים למצוא את האתרים שלכם. בדיקות ה-SEO של Lighthouse יכולות לעזור לכם לזהות בעיות בסיסיות. כדאי לעקוב אחרי הבלוגים הרשמיים של מנועי החיפוש כדי לקבל את ההנחיות והעדכונים האחרונים: Google, Bing, Baidu, DuckDuckGo, Yandex. פוסטים אחרונים שקשורים לנגיף הקורונה:

הנחיות נוספות בנושא גילוי

ביצועים

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

  • תמונות הן הגורם מספר אחת לעומס באינטרנט. יכול להיות שתוכלו להפחית באופן משמעותי את השימוש ברוחב הפס של האתר באמצעות אופטימיזציה של התמונות. ‫Squoosh הוא כלי פשוט בקוד פתוח לדחיסת תמונות, שיכול לעזור לכם לדחוס את התמונות במהירות.
  • מריצים את WebPageTest או את Lighthouse כדי לגלות את ההזדמנויות הכי טובות לשיפור הביצועים.
  • הפעילו דחיסת טקסט כדי להקטין את הגודל של משאבי הטקסט ברשת. בדרך כלל, זהו שיפור קל בביצועים שדורש השקעה טכנית מינימלית.
  • במאמר Fixing website speed cross-functionally מוסבר איך לשתף פעולה עם מחלקות אחרות ולקבל את הסכמתן.
  • השתמשו בטעינה מדורגת סטנדרטית של תמונות כדי לצמצם את הבקשות לתמונות שאנשים לא בהכרח יראו. התאימות לדפדפנים היא לא 100%, אבל אפשר להתייחס לתכונה כשיפור הדרגתי (progressive enhancement). במילים אחרות, אם דפדפן מסוים לא תומך בטעינה מדורגת סטנדרטית, התמונה צריכה להיטען כרגיל.
  • בדקו אם באתר יש סקריפטים של בדיקות A/B או של התאמה אישית שאפשר לטעון באופן אסינכרוני יותר, או אם יש בסקריפטים פונקציונליות לא קריטית שאפשר להשבית. בדרך כלל אי אפשר לטעון סקריפטים של בדיקות A/B והתאמה אישית באופן אסינכרוני מלא, כי הם צריכים לפעול לפני שתוכן הדף נטען. עם זאת, יכול להיות שאפשר לטעון חלקים מהסקריפטים באופן אסינכרוני יותר. במאמר Critical Rendering Path (נתיב עיבוד קריטי) מוסבר על הפשרה הבסיסית בין סקריפטים סינכרוניים (שנקראים גם סקריפטים שחוסמים עיבוד) באופן כללי לבין זמן הטעינה של הדף. אחרי שתקראו את המאמר, תוכלו להחליט אם לתת עדיפות לסקריפטים שחוסמים עיבוד על פני זמן הטעינה של הדף, או להיפך.
  • ברוב האתרים, קוד של צד שלישי מהווה כחצי מכל הבקשות. כדאי לבצע אופטימיזציה או להסיר או להשבית באופן זמני קוד של צד שלישי שלא חיוני להפעלת האתר.
  • אם השקות של תכונות חדשות לא נמצאות בראש סדר העדיפויות, זה הזמן המושלם לניקוי. הסירו תגים מ-Tag Manager, נקו קובצי CSS ו-JS מנופחים והסירו תכונות או קוד שיצאו משימוש. הכרטיסייה Coverage בכלי הפיתוח ל-Chrome והמחלקה Coverage ב-Puppeteer יכולות לעזור לכם לזהות קוד שלא בשימוש.

הנחיות נוספות זמינות במאמר זמני טעינה מהירים.