יצירת פרופיל לאפליקציות HTML5 לנייד באמצעות כלי הפיתוח ל-Chrome

John McCutchan
John McCutchan

מבוא

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

מדוע חשוב כל כך לבצע אופטימיזציה עבור האינטרנט לנייד?

ביצועים

ככל שנעבור מ-2G ומ-3G ל-4G, מכשירים ניידים מקבלים מעבדים מהירים יותר, יותר זיכרון RAM, מעבדי GPU מהירים יותר וגישה מהירה יותר לרשת. למרות צלילי ההתקדמות של המכשירים הניידים הם חלשים בהשוואה למחשבים שלנו. במילים פשוטות יותר, הטעינה של משאבי הרשת נמשכת זמן רב יותר, פענוח התמונות נמשך זמן רב יותר, ציור הדף נמשך זמן רב יותר והפעלת הסקריפטים לוקחת יותר זמן. אפשר להניח שהדף פועל לאט יותר פי 5 עד 10 פעמים במכשירים ניידים.

סוללה

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

מעורבות

המדד 'ביצועים' נועד להגדיל את המדד שהכי חשוב לכם. ב-Facebook חשובה לנו הגלילה. בבדיקת A/B, האטנו את הגלילה מ-60fps ל-30fps. המעורבות כווצה. אמרנו בסדר, לכן הגלילה חשובה.

Facebook at Edge Conference

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

ניהול הביצועים

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

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

שימוש מרחוק בכלי הפיתוח ל-Chrome

כשמכשיר Android מחובר למחשב שלכם. ב-Chrome במחשב, נכנסים אל http://localhost:9222 ופותחים את האתר במכשיר Android. תועברו לרשימת הכרטיסיות הפתוחות במכשיר Android. בוחרים את הדף מהרשימה 'דפים הניתנים לבדיקה'.

דפים הניתנים לבדיקה

ותועברו אל כלי הפיתוח ל-Chrome של הדף הזה.

כלי פיתוח מרחוק

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

לדוגמה, נכנסתי לכתובת www.sfgate.com/movies בטלפון שלי. באמצעות כלי הפיתוח ל-Chrome בשולחן העבודה, העברתי את העכבר מעל div בכלי הרכיבים, ובדיוק כמו שהוא מופיע בשולחן העבודה, הפרמטר div מודגש באופן חזותי במכשיר ה-Android שלי.

קטע קוד מקור.
Div מודגש.

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

נשלף אור בגישה לרשת

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

כלי הרשת.

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

אופטימיזציה של זמני צבע

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

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

קודם כול, מפעילים את המצב של צביעה מחדש של דף רציף:

אחרי ההפעלה יוצג תרשים בפינה השמאלית העליונה של מכשיר ה-Android. ציר ה-X של התרשים הוא זמן, מחולק למסגרות. ציר ה-y של התרשים מודד את זמן הצגת הצבע באלפיות השנייה. אפשר לראות שבמכשיר שלי לוקח 14 אלפיות שנייה לצייר. זמני הצבע המינימליים והמקסימליים מוצגים גם הם לצד זיכרון ה-GPU שנעשה בו שימוש.

לפני

לצורך ניסוי, הגדרתי את הסגנון display: none ברכיב שנבחר. בואו נראה כמה יקר ציור הדף.

אחרי.

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

תכונות מתקדמות

אודות:מעקב

רבות מהתכונות המתקדמות יותר למפתחים שזמינות ב-Chrome במחשב, זמינות גם ב-Android Chrome. לדוגמה, about:gpu-internals, about:appcache-internals ו-about:net-internals זמינים. כשבודקים בעיה מורכבת במיוחד, לפעמים יש צורך בנתונים נוספים כדי לזהות את הגורם לבעיה. במחשב, ייתכן שאתם משתמשים ב-about:ttracking. אם אתם עדיין לא מכירים את about:tracing, כדאי לכם לצפות בסרטון שלי שמסביר איך להשתמש בכלי about:teach ליצירת פרופילים. אפשר לתעד את אותם נתונים מ-Android Chrome, באופן הבא כדי להתחיל:

  1. הורד את adb_trace.py
  2. הפעל את adb_trace.py משורת הפקודה
  3. שימוש ב-Chrome ב-Android
  4. הקשה על Enter בשורת הפקודה משביתה את הסקריפט adb_trace.py.

בסיום התהליך של adb_trace.py, יהיה לכם קובץ JSON שאפשר לטעון ב-about:tracing של Chrome למחשב.

מדריך למתחילים

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

1. התקנת Android SDK

יכול להיות שאתם תוהים למה צריך להתקין את Android SDK כשאתם מפתחים את האתר. ב-SDK כלולה האפשרות adb (Android Debug Bridge). Chrome לשולחן העבודה צריך להיות מסוגל לתקשר עם מכשיר ה-Android שלך. Chrome לא מתקשר ישירות עם מכשיר Android, אלא מנתב את התקשורת באמצעות adb.

גשר ADB.

2. הפעלה של ניפוי באגים ב-USB במכשיר

הפעלת ניפוי באגים ב-USB

האפשרות להפעלה של ניפוי באגים ב-USB נמצאת בהגדרות של Android. הפעלה.

3. התחברות למכשיר

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

מותר לנפות באגים ב-USB

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

4. צריך לוודא שהמכשיר מחובר בצורה תקינה

הפעל מכשירי adb משורת הפקודה. המכשיר שלך אמור להופיע ברשימה.

5. הפעלה של ניפוי באגים ב-USB ב-Chrome

פותחים את Settings (הגדרות) > Advanced > DevTools (הגדרות > כלי פיתוח) ומסמנים את האפשרות הפעלה של ניפוי באגים באינטרנט באמצעות USB, כפי שמוצג כאן:

מותר לנפות באגים ב-USB

6. יצירת חיבור של כלי פיתוח למכשיר Android

מריצים את הפקודה הבאה:

adb forward tcp:9222 localabstract:chrome_devtools_remote

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

7. מוודאים שהכול מוכן

ודא שהמכשיר מחובר כראוי על ידי פתיחת Chrome במחשב השולחני וניווט אל http://localhost:9222. אם קיבלתם שגיאה 404 או שגיאה אחרת, או אם אתם לא רואים משהו כזה:

דפים ניתנים לבדיקה.

כאן אפשר למצוא הוראות מפורטות להגדרה.

סיכום

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