מחקר מקרה על כמה שינויים משמעותיים שהושקו ב-Wix כדי לשפר את ביצועי הטעינה של מיליוני אתרים, וכך לאפשר להם לקבל ציונים טובים ב-PageSpeed Insights ובמדדים הבסיסיים של חוויית המשתמש (Core Web Vitals).
בעזרת ניצול תקני התעשייה, ספקי ענן ויכולות של CDN, בשילוב עם כתיבה מחדש של זמן הריצה של האתרים שלנו, אחוז האתרים של Wix שהגיעו לציונים טובים ב-75% העליונים בכל המדדים של Core Web Vitals הוכפל פי 3 משנה לשנה, לפי נתונים מ-CrUX ומ-HTTPArchive.
ב-Wix אימצו תרבות שמתמקדת בביצועים, ונמשיך להשיק למשתמשים שיפורים נוספים. אנחנו מתמקדים במדדי ה-KPI של הביצועים, ולכן אנחנו מצפים לראות עלייה במספר האתרים שעומדים בערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר.
סקירה כללית
עולם הביצועים הוא מורכב בצורה יפה, עם הרבה משתנים ותובנות מורכבות. מחקרים מראים שלמהירות האתר יש השפעה ישירה על שיעורי ההמרות וההכנסות של עסקים. בשנים האחרונות, התעשייה שמה דגש רב יותר על החשיפה של הביצועים ועל האצת האינטרנט. החל ממאי 2021, אותות של חוויית השימוש בדף ייכללו בדירוג בחיפוש Google.
האתגר הייחודי ב-Wix הוא תמיכה במיליוני אתרים, חלקם נוצרו לפני שנים רבות ולא עודכנו מאז. יש לנו כלים ומאמרים שונים שיעזרו למשתמשים לנתח ולשפר את הביצועים של האתרים שלהם.
Wix היא סביבה מנוהלת, ולא כל מה שקורה בה בידי המשתמש. שיתוף התשתיות המשותפות מציב אתגרים רבים לכל האתרים האלה, אבל גם מאפשר הזדמנויות לשיפורים משמעותיים בכל התחומים, כלומר ניצול של יתרונות לגודל.
שיחה בשפה משותפת
אחת מהקשיים המרכזיים בנושא ביצועים היא למצוא מונחים משותפים לדיון בהיבטים שונים של חוויית המשתמש, תוך התחשבות בביצועים הטכניים ובביצועים שחווים המשתמשים. השימוש בשפה משותפת ומדויקת בארגון אפשר לנו לדון בקלות בחלקים הטכניים השונים ובפשרונות האלטרנטיביים, לסווג אותם בקלות, להבהיר את דוחות הביצועים ולעזור לנו להבין אילו היבטים כדאי להתמקד בשיפורם קודם.
שינינו את כל התהליכים שלנו למעקב ולדיונים פנימיים כך שיכללו מדדים סטנדרטיים בתחום, כמו מדדי Web Vitals, שכוללים:
דירוגים של מורכבות האתר וביצועי האתר
קל ליצור אתר שנטען באופן מיידי, כל עוד הוא פשוט מאוד ומשתמשים רק ב-HTML ומגישים אותו דרך CDN.
עם זאת, המציאות היא שהאתרים נעשים יותר ויותר מורכבים ומתוחכמים, ופועלים יותר כמו אפליקציות ולא כמו מסמכים, ותומכים בפונקציות כמו בלוגים, פתרונות למסחר אלקטרוני, קוד בהתאמה אישית ועוד.
ב-Wix יש מגוון רחב מאוד של תבניות, שמאפשרות למשתמשים ליצור בקלות אתר עם יכולות עסקיות רבות. לרוב, התכונות הנוספות האלה כרוכות בחלק מעלות הביצועים.
התהליך
בהתחלה היה HTML
בכל פעם שדף אינטרנט נטען, תמיד מתחילה בקשה ראשונית לכתובת URL כדי לאחזר את מסמך ה-HTML. תגובת ה-HTML הזו מפעילה את כל הבקשות הנוספות מהלקוח ואת הלוגיקה של הדפדפן כדי להריץ את האתר ולייצר את הגרפיקה שלו. זהו החלק החשוב ביותר בטעינת הדף, כי לא קורה כלום עד שמגיעה תחילת התגובה (המכונה TTFB – זמן לתחילת הבייט הראשון).
העבר: רינדור בצד הלקוח (CSR)
כשמפעילים מערכות בקנה מידה גדול, תמיד יש פשרות שצריך להביא בחשבון, כמו ביצועים, אמינות ועלויות. עד לפני כמה שנים, Wix השתמשה ברינדור מצד הלקוח (CSR), שבו תוכן ה-HTML בפועל נוצר באמצעות JavaScript בצד הלקוח (כלומר בדפדפן). כך יכולנו לתמוך במספר גדול של אתרים בלי עלויות תפעוליות גבוהות בקצה העורפי.
בעזרת CSR הצלחנו להשתמש במסמך HTML רגיל, שהיה ריק למעשה. כל מה שהוא עשה היה להפעיל את ההורדה של הקוד והנתונים הנדרשים, ששימשו לאחר מכן ליצירת ה-HTML המלא במכשיר הלקוח.
היום: רינדור בצד השרת (SSR)
לפני כמה שנים עברנו לעיבוד בצד השרת (SSR), כי זה היה מועיל גם ל-SEO וגם לביצועים. העברנו את הקוד הזה כדי לשפר את זמני החשיפה הראשונית של הדפים, וכדי להבטיח הוספה טובה יותר לאינדקס במנועי חיפוש שאין להם תמיכה מלאה בהרצת JavaScript.
הגישה הזו שיפרה את חוויית החשיפה, במיוחד במכשירים או בחיבורים איטיים יותר, ופתחה את הדלת לביצוע אופטימיזציות נוספות של הביצועים. עם זאת, המשמעות היא שעבור כל בקשה לדף אינטרנט, נוצרה תגובה ייחודית של HTML בזמן אמת, וזו לא אופטימלית, במיוחד לאתרים עם כמות גדולה של צפיות.
אנחנו משיקים אחסון במטמון בכמה מיקומים
קוד ה-HTML של כל אתר היה סטטי בעיקר, אבל היו לו כמה תנאים:
- הוא משתנה לעיתים קרובות. בכל פעם שמשתמש עורך את האתר שלו או מבצע שינויים בנתוני האתר, למשל במלאי המוצרים בחנות הווירטואלית באתר.
- הוא הכיל נתונים וקובצי cookie מסוימים שהיו ספציפיים למבקרים, כלומר שני אנשים שביקרו באותו אתר היו רואים קוד HTML שונה במקצת. לדוגמה, כדי לתמוך בתכונות של מוצרים כמו זכירה של הפריטים שהמבקרים הוסיפו לעגלת הקניות, או הצ'אט שהמבקרים התחילו עם העסק מוקדם יותר, ועוד.
- לא כל הדפים ניתנים לשמירה במטמון. לדוגמה, דף עם קוד מותאם אישית של משתמש, שמציג את השעה הנוכחית כחלק מהמסמך, לא מתאים לשמירה במטמון.
בהתחלה, נקטנו בגישה בטוחה יחסית של שמירת ה-HTML במטמון ללא נתוני המבקרים, ולאחר מכן שינינו רק חלקים ספציפיים בתגובה של ה-HTML בזמן אמת לכל מבקר, לכל היטים במטמון.
פתרון CDN פנימי
כדי לעשות זאת, פרסנו פתרון פנימי: שימוש ב-Varnish HTTP Cache לשרת proxy ולמטמון, ב-Kafka להודעות ביטול תוקף ובשירות מבוסס-Scala/Netty שמשתמש בשרת proxy לתגובות ה-HTML האלה, אבל מבצע טרנספורמציה ל-HTML ומוסיף ל-cookie ולנתונים הספציפיים למבקרים לתגובה שנשמרה במטמון.
הפתרון הזה אפשר לנו לפרוס את הרכיבים הדקים האלה במיקומים גיאוגרפיים רבים יותר ובמספר אזורים של ספקי ענן, שמפוזרים ברחבי העולם. בשנת 2019 הוספנו יותר מ-15 אזורים חדשים, והפעלנו בהדרגה אחסון במטמון ב-90% מהצפיות בדפים שעומדים בדרישות לאחסון במטמון. הצגת אתרים ממיקומים נוספים צמצמה את זמן האחזור ברשת בין הלקוחות לבין השרתים שמציגים את תגובת ה-HTML, על ידי קידום התוכן קרוב יותר למבקרים באתר.
התחלנו גם לשמור בתגובה ל-API מסוימת לקריאה בלבד באמצעות אותו פתרון, ולבטל את התגובה ששמורה במטמון בכל שינוי בתוכן האתר. לדוגמה, רשימת הפוסטים בבלוג באתר נשמרת במטמון ומבוטלת כשפוסט פורסם או השתנה.
הפחתת המורכבות
הטמעת האחסון במטמון שיפרה את הביצועים באופן משמעותי, בעיקר בשלבים TTFB ו-FCP, ושיפור האמינות שלנו על ידי הצגת התוכן ממיקום קרוב יותר למשתמש הקצה.
עם זאת, הצורך לשנות את ה-HTML לכל תשובה יצר מורכבות מיותרת, והסרת הצורך הזה אפשרה לנו לשפר את הביצועים עוד יותר.
שמירה במטמון הדפדפן (והכנות ל-CDN)
~ 13%
בקשות HTML שמוצגות ישירות מהמטמון של הדפדפן, וכך חוסכות ברוחב פס רב ומקצרות את זמני הטעינה של צפיות חוזרות
השלב הבא היה להסיר את הנתונים הספציפיים למבקרים מה-HTML לחלוטין, ולאחזר אותם מנקודת קצה נפרדת שהלקוח קורא אליה למטרה הזו אחרי שה-HTML מגיע.
העברנו בזהירות את הנתונים ואת קובצי ה-cookie האלה לנקודת קצה חדשה, שנקראת בכל טעינת דף, אבל מחזירה קובץ JSON מצומצם שנחוץ רק לתהליך ההידרציה, כדי להגיע לאינטראקטיביות מלאה בדף.
כך הצלחנו להפעיל אחסון ב-cache בדפדפנים של ה-HTML. כלומר, הדפדפנים שומרים עכשיו את התגובה של ה-HTML לביקור חוזר, ומפעילים את השרת רק כדי לאמת שהתוכן לא השתנה. כדי לעשות זאת, משתמשים ב-HTTP ETag, שהוא למעשה מזהה שהוקצה לגרסה ספציפית של משאב HTML. אם התוכן עדיין זהה, השרתים שלנו שולחים ללקוח תשובה מסוג 304 Not Modified, ללא גוף.
בנוסף, בעקבות השינוי הזה, ה-HTML שלנו כבר לא ספציפי למבקרים ולא מכיל קובצי cookie. במילים אחרות, אפשר לשמור את הקובץ במטמון בכל מקום, וכך להשתמש בספקי CDN עם נוכחות גיאוגרפית טובה יותר במאות מיקומים ברחבי העולם.
DNS, SSL ו-HTTP/2
כשהאחסון במטמון מופעל, זמני ההמתנה קצרים יותר וחלקים חשובים אחרים של החיבור הראשוני משמעותיים יותר. שיפור התשתית והמעקב של הרשתות שלנו אפשר לנו לשפר את זמני ה-DNS, החיבור וה-SSL.
הפעלנו את HTTP/2 בכל דומיינים של משתמשים, כדי לצמצם את מספר החיבורים הנדרשים ואת התקורה שמתלווה לכל חיבור חדש. היה קל יחסית לפרוס את השינוי הזה, תוך ניצול היתרונות של ביצועים ועמידות שמגיעים עם HTTP/2.
דחיסת Brotli (לעומת gzip)
21 עד 25%
הפחתה של גודל העברת הקובץ החציוני
בעבר, כל הקבצים שלנו היו דחוסים באמצעות דחיסת gzip, שהיא אפשרות הדחיסה הנפוצה ביותר של HTML באינטרנט. פרוטוקול הדחיסה הזה יושם לראשונה לפני כמעט 30 שנה!
דחיסת Brotli החדשה כוללת שיפורים בדחיסת הנתונים כמעט ללא פשרות, והיא צוברת פופולריות בהדרגה, כפי שמתואר בפרק הדחיסה במהדורה השנתית של Web Almanac. הוא נתמך בכל הדפדפנים העיקריים כבר זמן מה.
הפעלנו תמיכה ב-Brotli בשרתי ה-proxy של nginx בקצה, לכל הלקוחות שתומכים בו.
המעבר לדחיסת Brotli צמצם את גודל ההעברה הממוצע של הקבצים ב-21% עד 25%, וכתוצאה מכך ירד השימוש ברוחב הפס וזמן הטעינה השתפר.
רשתות להעברת תוכן (CDN)
בחירת CDN דינמית
ב-Wix תמיד השתמשנו ב-CDN כדי להציג את כל קוד ה-JavaScript והתמונות באתרים של המשתמשים.
לאחרונה שילבנו פתרון של ספק ה-DNS שלנו כדי לבחור באופן אוטומטי את רשת ה-CDN שמניבה את הביצועים הטובים ביותר בהתאם לרשת ולמקור של הלקוח. כך אנחנו יכולים להציג את הקבצים הסטטיים מהמיקום הטוב ביותר לכל מבקר, ולהימנע מבעיות זמינות ב-CDN מסוים.
בקרוב… דומיינים של משתמשים שמתקבלים דרך רשתות CDN
החלק האחרון בפאזל הוא הצגת החלק האחרון והקריטי ביותר באמצעות CDN: ה-HTML מהדומיין של המשתמש.
כפי שתואר למעלה, יצרנו פתרון פנימי משלי לשמירת תוצאות ה-HTML וה-API הספציפיות לאתר במטמון ולהצגתן. גם לתחזוקת הפתרון הזה באזורים חדשים רבים יש עלויות תפעוליות, והוספת מיקומים חדשים הופכת לתהליך שאנחנו צריכים לנהל ולבצע בו אופטימיזציה באופן שוטף.
אנחנו משלבים כרגע עם ספקי CDN שונים כדי לתמוך בהצגת כל האתר של Wix ישירות ממיקומי CDN, כדי לשפר את הפצת השרתים שלנו ברחבי העולם וכך לשפר עוד יותר את זמני התגובה. זוהי בעיה עקב כמות הדומיינים הגדולה שאנחנו מספקים, שדורשים סיום SSL בקצה.
השילוב עם רשתות CDN מביא את אתרי Wix קרוב יותר מתמיד ללקוחות, ומאפשר לבצע שיפורים נוספים בחוויית הטעינה, כולל טכנולוגיות חדשות כמו HTTP/3, בלי מאמץ נוסף מצידנו.
כמה מילים על מעקב ביצועים
אם אתם מנהלים אתר ב-Wix, סביר להניח שאתם תוהים איך זה משפיע על תוצאות הביצועים של האתר ב-Wix, ואיך אנחנו משתווים לפלטפורמות אחרות של אתרים.
רוב העבודה שביצענו הופעלה בשנה האחרונה, וחלק מהיא עדיין בהשקה.
לאחרונה פורסם מהדורת 2020 של Web Almanac על ידי HTTPArchive, שכולל פרק מעולה בנושא חוויית המשתמש במערכת ניהול תוכן. חשוב לזכור שרבים מהמספרים שמפורטים במאמר הזה הם מאמצע שנת 2020.
אנחנו מצפים לראות את הדוח המעודכן ב-2021, ואנחנו עוקבים באופן פעיל אחרי דוחות CrUX של האתרים שלנו וגם אחרי מדדי הביצועים הפנימיים שלנו.
אנחנו מחויבים לשפר את זמני הטעינה באופן קבוע ולספק למשתמשים שלנו פלטפורמה שבה הם יכולים ליצור אתרים כפי שהם מדמיינים, בלי להתפשר על הביצועים.
לאחרונה, חברת DebugBear פרסמה בדיקה מעניינת מאוד של ביצועי כלי ליצירת אתרים, שבה היא מתייחסת לחלק מהתחומים שציינתי למעלה ובודקת את הביצועים של אתרים פשוטים מאוד שנוצרו בכל פלטפורמה. האתר הזה נוצר לפני כמעט שנתיים ולא בוצעו בו שינויים מאז, אבל הפלטפורמה הולכת ומשתפרת, וכך גם ביצועי האתר. אפשר לראות זאת בנתונים שלו משנה וחצי האחרונות.
סיכום
אנחנו מקווים שהניסיון שלנו יעזור לכם לאמץ תרבות שממוקדת בביצועים בארגון, ושהפרטים שלמעלה יהיו שימושיים וישימים לפלטפורמה או לאתר שלכם.
לסיכום:
- בוחרים קבוצת מדדים שאפשר לעקוב אחריה בעקביות באמצעות כלים מומלצים בתחום. אנחנו ממליצים על מדדי הליבה לבדיקת חוויית המשתמש באתר.
- נצלו את שמירת הנתונים במטמון הדפדפן ואת רשתות ה-CDN.
- עוברים ל-HTTP/2 (או ל-HTTP/3 אם אפשר).
- להשתמש בדחיסת Brotli.
תודה שקראת את הסיפור שלנו. אנחנו מזמינים אותך לשאול שאלות ולשתף רעיונות ב-Twitter וב-GitHub, ולהצטרף לשיחה בנושא ביצועי האתר בערוצים המועדפים עליך.