פרויקט שמתמקד באופטימיזציה של מדדי הליבה לבדיקת חוויית המשתמש באתר ומעבר ל-Next.js הוביל לעלייה של 5% בשיעורי ההמרות ולעלייה של 87% במספר הדפים בכל סשן.
QuintoAndar היא חברת פרוטקטור בברזיל שמוצריה מציעים פתרונות דיגיטליים מקצה לקצה לנדל"ן. השנה ביצענו פרויקט שמטרתו לשפר את הביצועים של מרכז תוכן באפליקציה שלנו, והתוצאות היו מעודדות: עלייה בתנועת המשתמשים ובמדדי ההמרות.
46%
הפחתת שיעור העזיבה
87%
עלייה במספר הדפים לביקור
5%
שיפור בהמרות במהלך שלב האימות
אתגרים
באפליקציה שלנו יש מרכז תוכן של קונדומינiums עם יותר מ-40,000 דפים, שבו המשתמשים יכולים לקבל מידע על הנכסים שלהם, לבדוק תמונות של האזורים המשותפים, לקרוא על השכונה ולמצוא דפים זמינים להשכרה או למכירה. הדפים האלה חשובים מאוד ל-QuintoAndar:
- הן מקור חשוב לתנועה אורגנית, ומספר המשתמשים שמגיעים מתוצאות במנועי חיפוש הולך וגדל.
- יש להם שיעורי המרה גבוהים בטווח הבינוני והארוך בהשוואה לדפים אחרים.
עם זאת, היו בעיות שקשורות לביצועים ולחוויית המשתמש בדפים האלה:
- הביצועים שלהן, כפי שנמדדו על ידי מדדי הליבה לבדיקת חוויית המשתמש באתר, לא עברו אופטימיזציה והיו בעיות ידועות לגבי טעינה איטית של דפים, תגובה איטית לקלט של משתמשים וחוסר יציבות בפריסה.
- שיעורי היציאה שלהם היו גבוהים, גם אם ציפינו שהם יהיו גבוהים יותר מאשר בחלקים אחרים באפליקציה.
- העדכון של חוויית השימוש בדף בחיפוש Google – שעדיין לא פורסם באותו זמן – יכלול את מדדי הליבה לבדיקת חוויית המשתמש באתר באלגוריתמים לדירוג. כלומר, ביצועי הדף עשויים להשפיע על האופן שבו תוצאות החיפוש יוצגו.
במקביל, זיהינו כמה הזדמנויות לשיפור חוויית הפיתוח שיכולות להניב תועלת בפרויקטים אחרים בחברה:
- הלוגיקה של הרינדור בצד השרת – שמרינדורת את כל הדפים עם נפח התנועה הגבוה, כולל דפי קבוצות הבית – נוצרה בחברה, והפכה ליותר מדי מורכבת לצורך תחזוקה ולהדרכה של עובדים חדשים.
- גם תכונות חיוניות לשיפור ביצועי האפליקציה, כמו חלוקת קוד, דרשו הגדרה מותאמת אישית ועבודה ידנית מצד המפתחים.
- ל-QuintoAndar יש יותר מ-30 אפליקציות אינטרנט של React. זהו תהליך קשה לעדכן את האפליקציות האלה ולתחזק אותן בהתאם לשיטות המומלצות.
גישה
התחלנו בפרויקט אופטימיזציה של הביצועים של מרכז התוכן של 'דירות בבניין' כדי לשפר את חוויית המשתמש שלו. השיפורים האלה עשויים להוביל לעלייה במספר ההמרות, לשיפור ב-SEO ולשיפור בנוחות השימוש. היוזמה הזו גם הייתה הזדמנות מצוינת לשפר את חוויית המפתחים.
מעבר ל-Next.js
הגרסה החדשה של דף הדירה המשותפת הופעלה באמצעות Next.js. מרכז התוכן של הבניין היה נראה כמו מקום מתאים לניסיון של מסגרת חדשה, כי הוא עצמאי במידה רבה מחלקים אחרים באפליקציה. נוכל להבין את ההיקף של מאמצי ההעברה ולהעריך איך התכונות שלהם יכולות לעזור בלי להשפיע על אפליקציות React האחרות ב-QuintoAndar.
דרישה חמורה הייתה להבטיח שמנועי חיפוש יוכלו להמשיך לסרוק את הדפים. כדי לעמוד בדרישות האלה, Next.js תומך ברינדור מצד השרת כברירת מחדל, ומבטל את הצורך בהגדרה מותאמת אישית. בעזרת המסמכים האלה קל יותר לשתף ידע לגבי משימות כמו אחזור נתונים בשרת ולהטמיע מפתחים חדשים. רינדור בצד השרת ידוע גם כגורם לשיפור מדדי הביצועים, כמו הצגת תוכן ראשוני (FCP).
המסגרת מספקת תכונות נוספות שמשפרות את הביצועים, כמו חלוקת קוד אוטומטית ואחזור מראש. אמנם המבנה הקיים כבר סיפק תכונות כאלה, אבל העבודה הנוספת שנדרשה מהמפתחים עיכבה את השימוש בהן. לדוגמה, היה צריך לפצל את הקוד ברמת הדף או הרכיב באופן ידני.
אופטימיזציה של משאבי JavaScript
השלב הראשון היה הסרת קוד שלא בשימוש. בדקנו את הדוחות של Webpack Bundle Analyzer, שבהם מוצגים התוכן של כל חבילת JS, ובדקנו בקפידה את כל הסקריפטים של צד שלישי. כתוצאה מכך, הצלחנו לנקות כמה ספריות מעקב שלא היו בשימוש בדף הספציפי הזה.
הצוות שלנו הרחיב את הנושא והעריך את עלות הביצועים של תכונות קיימות. לדוגמה, כדי שהלחצן 'לייק' יפעל, נדרש הרבה תוכן JS. עם זאת, בדף של הבית המשותף, פחות מ-0.5% מהמשתמשים קיימו אינטראקציה עם הלחצן, שהוא זמין ומשומש בתדירות גבוהה יותר בחלקים אחרים באפליקציה שלנו. אחרי דיון שכלל גם את מהנדסי המוצר, החלטנו להסיר את התכונה הזו.
כבר הוטמעו אופטימיזציות אחרות של JS, כמו דחיסת קבצים סטטיים באמצעות Brotli, שבוצעה בזמן ה-build באמצעות BrotliWebpackPlugin
, והוחלה גם על סוגים אחרים של משאבים סטטיים. בהתחלה, הסתמכנו על הדחיסה שסופקה על ידי ה-CDN, ו-Brotli צמצם את גודל ה-JS ב-18% בהשוואה ל-gzip. אבל לאחר מכן עברנו לדחיסת Brotli בזמן ה-build, והצלחנו להשיג הפחתה של 24%.
אופטימיזציה של משאבי תמונות
בגרסה לנייד, תמונה ראשית תופסת את רוב האזור מעל למסך. הוא גם הרכיב שמוגדר כהמהירות שבה נטען רכיב התוכן הכי גדול (LCP) בדף.
בעבר, כל התמונות כבר הכילו את המאפיינים srcset
ו-sizes
כדי להציג תמונות רספונסיביות. השתמשנו גם ב-Thumbor כדי לשנות את הגודל של תמונות על פי דרישה, והגדרתנו את ה-CDN שלנו לשמירתן במטמון ביעילות.
במכשירים ניידים מודרניים יש מסכים עם צפיפות פיקסלים גבוהה מאוד, כלומר הדפדפן ירנדר גרסאות של התמונה בגודל פי 3 או פי 4, אם הן זמינות. ככל שהרזולוציה גבוהה יותר, קשה יותר לעין האנושית להבחין בהבדלים, אבל גודל הקבצים יגדל בכל מקרה. הגבלת הרזולוציה המקסימלית של התמונות שיפרה את גודל התמונות בלי לפגוע בחוויית המשתמש. הגבלנו את התצוגה של תמונת ה-Hero לגרסה כפולה לכל היותר, שהיא קטנה בכ-35% מהגרסה המשולשת וכ-50% מהגרסה המרובעת.
לסיום, השתמשנו בשיטת טעינה מראש כדי להוריד את התמונה ולהציג אותה בהקדם האפשרי. אנחנו מצפים לשפר את מדד ה-LCP.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
רכיב התמונה המובנה של Next.js כולל הרבה מהאופטימיזציות האלה, כמו שינוי גודל רספונסיבי וטעינה לפי תעדוף. במסגרת הפרויקט הזה, לא העברנו את התמונות הקיימות כדי להשתמש ברכיב הזה, אבל אנחנו מתכננים להשתמש בו בתכונות חדשות.
הפחתת שינויי הפריסה
בדף של הדירה היו כמה בעיות בתזוזת פריסה נצברת (CLS). האלמנטים שאחראים לשינויים בפריסה עבר רינדור רק בצד הלקוח – לדוגמה, הוספת תוכן לסימון בצד השרת באמצעות רכיבים שרינדר בצד הלקוח, או תמונות ללא מאפייני width
ו-height
מוגדרים.
כדי לפתור את הבעיות האלה, אנחנו מגדירים מידות מדויקות לרכיבים האלה כשהדבר אפשרי, או ערכים משוערים עם min-height
. יש אפשרויות נוספות, כמו שימוש בנכס CSS aspect-ratio
. יצרנו גם placeholders כדי למנוע מרכיבים שעבר עליהם עיבוד דינמי לגרום לשינויים בפריסה.
השקה הדרגתית של שינויים
הצוות שלנו רצה לוודא שהגרסה האופטימיזציה של דף הבית של הקונדומיניום תהיה טובה יותר לחוויית המשתמש. כדי לעשות זאת, אימצנו אסטרטגיית השקה הדרגתית:
- בשלב הראשון, הגרסה החדשה פורסמה לכמה כתובות URL שנבחרו באופן ידני, כך שרק כמה מאות משתמשים ביום יראו אותן.
- בשלב השני הוא פורסם עבור דפים רבים יותר, המגיעים לכמה אלפי משתמשים ביום;
- בשלב השלישי והאחרון, התכונה פורסמה לכל הדפים וההשקה הושלמה לכל המשתמשים.
במהלך התקופה הזו, צוות מהנדסי התוכנה מדדו באופן רציף את ביצועי הדפים בסביבת הייצור והמשכנו לשפר את הביצועים. בנוסף, הצוות השווה בין מדדים עסקיים בגרסה החדשה לבין המדדים בגרסה הקודמת. התוצאות בתקופה הזו של האימות היו מבטיחות.
תוצאות
הצוות השתמש ב-SpeedCurve כדי להריץ באופן שוטף בדיקות מעבדה בדף של הקונדומיניום. אלה התוצאות לגרסה לנייד:
מדד מעבדה | לפני | אחרי | הפרש |
---|---|---|---|
Largest Contentful Paint (LCP) | 2.41 שניות | 1.48 שניות | -39% |
הזמן עד לפעילות מלאה (TTI) | 12.16 שניות | 7.48 שניות | 39%- |
זמן החסימה הכולל (TBT) | 1,124 אלפיות שנייה | 1,056 אלפיות שנייה | 4%- |
Cumulative Layout Shift (CLS) | 0.0402 | 0.0093 | -77% |
רצינו גם לבדוק את ההשפעה על המשתמשים האמיתיים שלנו. בעזרת נתוני שדה שנאספו באמצעות מעקב אחר אתרים של Instana, בדקנו את התקופה של חודש אחד לפני ההשקה ואת התקופה של חודש אחד אחרי ההשקה. בהשוואה למאון ה-75 של משתמשים בנייד, גילינו שהמדד LCP ירד ב-26% והמדד FID ירד ב-72%.
הכלי PageSpeed Insights מספק דוח של נתוני שדות מ-28 הימים האחרונים. לבדו היו מספיק נתונים כדי להפיק דוח לגבי משתמשים בנייד בדף של הבית המשותף שנחשף אליו הכי הרבה פעמים. נכון לנובמבר 2021, כל המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) נמצאים בקטגוריה 'טוב'.
במהלך ההשקה ההדרגתית, שמנו לב בירידה בשיעורי העזיבה. עד שסיימנו את ההשקה בכל הדפים, Google Analytics הראה ירידה של 46% בשיעור העזיבה, עלייה של 87% במספר הדפים בכל סשן ועלייה של 49% במשך הסשן הממוצע. הירידה בשיעור העזיבה הייתה גדולה עוד יותר בחיפושים בתשלום, והגיעה ל-59% – סימן חיובי לגבי ההשקעות במודעות תשלום לפי קליק (PPC).
לגבי ההשפעה על מדדי העסק, ניתחנו את שיעורי ההמרה של עסקאות כמו תזמון סיור והגשת בקשה לרכישה או לדייר משנה של נכס. בזמן שהשיפורים עדיין היו בתהליך השקה, הצוות שלנו השווה בין ההמרות בגרסה הקודמת לבין ההמרות בגרסה החדשה. באותו שבוע, בקבוצת הדפים עם הגרסה החדשה נרשמה עלייה של 5% במספר ההמרות, ואילו בדפים האחרים נרשמה ירידה קלה באותו מדד.
סיכום
הפרויקט הזה הוא החלק הראשון בתהליך העברה לטווח ארוך מ-React ללא framework ל-Next.js. הצוותים שעבדו על דף היחידה המשותפת מאז העבירו משוב חיובי על חוויית המפתח המשופרת. צוותים אחרים שנאלצו להתחיל מאפס עם אפליקציות אינטרנט חדשות כבר עשו זאת באמצעות Next.js. אנחנו מאמינים ש-Next.js יפשט את מאמצי התחזוקה ויאפשר לכם למצוא נקודות משותפות בין אפליקציות שונות.
באופן כללי, מרכז התוכן של הקונדומיניומים גדל בהתמדה מבחינת מספר המשתמשים והעסקאות המוחלט. בניתוח לטווח הארוך יש גורמים רבים שתורמים לכך, כמו הרחבת הפעילות של QuintoAndar ויוזמות בנושא אופטימיזציה למנועי חיפוש (SEO), כמו הוספה משופרת של דפים לאינדקס. במהלך הפרויקט הזה, גילינו שביצועי הדף הם גם אחד מהגורמים האלה, עם פוטנציאל גדול להשפעה חיובית על ההמרות.
תודה מיוחדת לPedro Carmo, מנהל מוצר בצוות האופטימיזציה למנועי חיפוש, על כך שהעמיק בנתוני המשתמשים ועל יצירת כל ניתוח ההמרות שמוצגים בניתוח המקרה הזה.