שירות PageSpeed Insights מנתח דף כדי לראות אם הוא פועל לפי ההמלצות שלנו לביצוע עיבוד של דף תוך פחות משנייה ברשת סלולרית. מחקרים הראו שכל עיכוב הנמשך יותר משנייה יגרום למשתמשים להפריע לזרימת המחשבה שלהם וייצור חוויה לא טובה. המטרה שלנו היא לשמור על מעורבות המשתמש בדף ולספק חוויה אופטימלית, ללא קשר למכשיר או לסוג הרשת.
לא פשוט למצות את התקציב בפעם השנייה. למרבה המזל, לא צריך לעבד את כל הדף במסגרת התקציב הזה, אלא עלינו לספק ולעבד את התוכן בחלק העליון והקבוע בפחות משנייה, כדי לאפשר למשתמש להתחיל באינטראקציה עם הדף בהקדם האפשרי. לאחר מכן, בזמן שהמשתמש מפרש את הדף הראשון של התוכן, התוכן של שאר הדף מועבר בהדרגה ברקע.
הסתגלות לרשתות סלולריות עם זמן אחזור ארוך
עמידה בקריטריונים של החלק העליון העליון והקבוע במכשירים ניידים מציבה אתגרים ייחודיים שלא קיימים ברשתות אחרות. ייתכן שמשתמשים ניגשים לאתר שלך דרך מגוון רשתות 2G, 3G ו-4G שונות. זמני האחזור של הרשת גבוהים באופן משמעותי בהשוואה לחיבור קווי, והם צורכים חלק משמעותי מהתקציב של 1,000 אלפיות השנייה שלנו להצגת התוכן בחלק העליון והקבוע.
4G הוא סוג הרשת הדומיננטי בכל העולם, ואפשר לצפות שרוב המשתמשים ייגשו לדף שלך ברשת 4G. מסיבה זו, עלינו להניח שכל בקשת רשת תארך בממוצע 100 אלפיות השנייה.
לאור זאת, עכשיו נעבור לאחור. אם נבחן רצף אופייני של תקשורת בין הדפדפן לשרת, כבר נעשה שימוש ב-300 אלפיות השנייה של אותו תקורה ברשת: חיפוש DNS לפתרון שם המארח (למשל, google.com) לכתובת IP, חיבור לרשת הלוך ושוב לביצוע לחיצת יד של TCP, וחיבור TLS אופציונלי. זה משאיר לנו 700 אלפיות שנייה.
הצגת חוויית הרינדור של פחות משנייה
לאחר הפחתת זמן האחזור של הרשת, נותרו לנו רק 700 אלפיות השנייה בתקציב, ועדיין נדרשת עבודה רבה: השרת צריך לעבד את התגובה, קוד האפליקציה בצד הלקוח חייב לפעול והדפדפן צריך לפרוס ולעבד את התוכן. עם זאת, הקריטריונים הבאים אמורים לעזור לנו להישאר במסגרת התקציב:
- (1) השרת חייב לעבד את התגובה (פחות מ-200 אלפיות השנייה)
- זמן התגובה של השרת הוא הזמן שלוקח לשרת להחזיר את קוד ה-HTML הראשוני, תוך שקלול זמן התעבורה ברשת. מאחר שאין לנו כל כך הרבה זמן, יש להקצות את הזמן הזה לכל הפחות - 200 אלפיות שנייה ורצוי אפילו פחות.
- (2) יש לצמצם את מספר ההפניות לכתובות אחרות
- הפניות HTTP נוספות יכולות להוסיף עוד נתיב אחד או שניים הלוך ושוב ברשת (שתיים אם יש צורך בחיפוש DNS נוסף), וכך להאריך את זמן האחזור ברשתות 4G למשך מאות אלפיות השנייה. מהסיבה הזו, אנחנו ממליצים מאוד למנהלי אתרים לצמצם את המספר, ורצוי לבטל הפניות מחדש באופן מלא - זה חשוב במיוחד למסמך ה-HTML (הימנע מהפניות מחדש מסוג "m נקודה" כאשר הדבר אפשרי).
- (3) יש לצמצם את מספר הבקשות הלוך ושוב אל העיבוד הראשון
-
בשל האופן שבו TCP מעריך את הקיבולת של חיבור (כלומר התחלה איטית ב-TCP), חיבור TCP חדש לא יכול להשתמש באופן מיידי ברוחב הפס הזמין המלא בין הלקוח לשרת. לכן השרת יכול לשלוח עד 10 חבילות TCP בחיבור חדש (כ-14KB) במסלול הלוך ושוב הראשון, ולאחר מכן עליו להמתין עד שהלקוח יאשר את הנתונים לפני שיוכל להגדיל את חלון העומסים שלו ולהמשיך לספק נתונים נוספים.
חשוב גם לציין שהמגבלה של 10 חבילות (IW10) היא עדכון שבוצע לאחרונה לתקן TCP: כדי לנצל את השינוי הזה, עליכם לוודא שהשרת משודרג לגרסה האחרונה. אחרת, סביר להניח שהמגבלה תהיה 3-4 חבילות.
בגלל ההתנהגות הזו של TCP, חשוב לבצע אופטימיזציה של התוכן כדי לצמצם את מספר הבקשות הלוך ושוב הדרושות כדי לספק את הנתונים הדרושים לביצוע העיבוד הראשון של הדף. באופן אידיאלי, התוכן בחלק העליון והקבוע צריך להכיל פחות מ-98KB - כך הדפדפן יכול לצבוע את הדף לאחר שלוש פעולות הלוך ושוב בלבד, וכך להקצות מספיק זמן לזמני האחזור של תגובת השרת ולעיבוד הלקוח.
- (4) להימנע מחסימה חיצונית של JavaScript ו-CSS בתוכן שבחלק העליון והקבוע
-
כדי שדפדפן יוכל לעבד דף למשתמש, הוא צריך לנתח את הדף. אם הוא נתקל בסקריפט חיצוני שאינו אסינכרוני או חוסם אותו במהלך הניתוח, הוא צריך לעצור ולהוריד את המשאב הזה. בכל פעם שהפעולה מתבצעת, מתבצעת הוספה של הלוך ושוב ברשת, שיעכב את זמן העיבוד הראשון של הדף.
כתוצאה מכך, רכיבי ה-JavaScript וה-CSS הדרושים לעיבוד החלק העליון והקבוע צריכים להופיע בתוך קו תחתון, ורכיבי JavaScript או CSS הנדרשים להוספת פונקציונליות לדף צריכים להיטען לאחר העברת התוכן בחלק העליון והקבוע.
- (5) שריון זמן לפריסה ולעיבוד של הדפדפן (200 אלפיות שנייה)
- תהליך הניתוח של HTML, CSS וביצוע JavaScript דורש זמן ומשאבי לקוחות! התהליך הזה יכול להימשך מאות אלפיות שנייה, בהתאם למהירות המכשיר הנייד ולמורכבות הדף. ההמלצה שלנו היא לשריין 200 אלפיות השנייה לתקורה של דפדפנים.
- (6) אופטימיזציה של זמן הביצוע והרינדור של JavaScript
- ביצוע של סקריפטים מורכבים וקוד לא יעיל עשוי להימשך עשרות ומאות אלפיות שנייה – כדאי להשתמש בכלים המובנים למפתחים בדפדפן כדי ליצור פרופיל ולבצע אופטימיזציה של הקוד. למבוא מצוין, כדאי להציץ בקורס האינטראקטיבי שלנו בנושא הכלים למפתחים ב-Chrome.
שאלות נפוצות
- יש לי עצות לגבי השימוש שלי בספריית JavaScript, כמו JQuery?
- ספריות JavaScript רבות, כמו Jquery, משמשות לשיפור הדף ולהוספת אינטראקטיביות, אנימציות ואפקטים אחרים. עם זאת, אפשר להוסיף הרבה מההתנהגויות האלה באופן בטוח אחרי עיבוד התוכן בחלק העליון והקבוע. יש לבדוק את העברת הביצוע והטעינה של JavaScript כזה עד לאחר טעינת הדף.
- יש לי עצה להשתמש במסגרת JavaScript כדי לבנות את הדף?
- אם התוכן של הדף בנוי באמצעות JavaScript בצד הלקוח, עליך לבדוק את הטמעת המודולים הרלוונטיים של JavaScript כדי להימנע ממעברים נוספים ברשת. באופן דומה, שימוש בעיבוד בצד השרת יכול לשפר משמעותית את ביצועי הטעינה של הדף הראשון: עיבוד תבניות JS בשרת, הטבעת התוצאות ב-HTML, ולאחר מכן שימוש בתבניות בצד הלקוח לאחר טעינת האפליקציה.
- איך אפשר לזהות CSS קריטי בדף שלי?
- בכלים למפתחים ב-Chrome, פותחים את חלונית הביקורות ומריצים דוח ביצועים של דפי אינטרנט. בדוח שנוצר, מחפשים את האפשרות 'הסרת כללי CSS שאינם בשימוש'. לחלופין, ניתן להשתמש בכל כלי או בסקריפט של צד שלישי כדי לזהות אילו סלקטורים ב-CSS יחולו על כל דף.
- האם אפשר להפוך את השיטות המומלצות האלה לאוטומטיות?
- בהחלט. יש מוצרים רבים לאופטימיזציית ביצועים באינטרנט (WPO) מסחריים וקוד פתוח שיכולים לעזור לכם לעמוד בחלק מהקריטריונים שלמעלה, או בכולם. לפתרונות קוד פתוח, כדאי לעיין בכלי האופטימיזציה של PageSpeed.
- איך אפשר לכוונן את השרת כך שיעמוד בקריטריונים האלה?
-
קודם כל צריך לוודא שבשרת פועלת גרסה עדכנית של מערכת ההפעלה. כדי להפיק תועלת מגודל חלון העומס הראשוני המוגדל ב-TCP (IW10), אתם זקוקים לליבה של Linux מגרסה 2.6.39 ואילך. במערכות הפעלה אחרות, עיינו במסמכי התיעוד.
כדי לבצע אופטימיזציה של זמן התגובה של השרת, לתקן את הקוד או להשתמש בפתרון למעקב אחר אפליקציות כדי לזהות את צוואר הבקבוק – לדוגמה, זמן ריצה של סקריפטים, קריאות למסד נתונים, בקשות RPC, עיבוד וכו'. המטרה היא לעבד את תגובת ה-HTML בתוך 200 אלפיות השנייה. - מה לגבי Content Security Policy?
- אם בחרת להשתמש ב-CSP, ייתכן שעליך לעדכן את מדיניות ברירת המחדל שלך.
ראשית, מאפייני CSS מוטבעים ברכיבי HTML(למשל, יש להימנע ככל האפשר מ-< p style=...>), כי במקרים רבים הם יובילו לשכפול קוד באופן מיותר, והחסומים כברירת מחדל באמצעות CSP (מושבתים דרך 'לא בטוח מוטבע' ב-'style-src'). אם CSP מופעל, כל תגי הסקריפט המוטבע חסומים כברירת מחדל. אם יש לכם JavaScript מוטבע, תצטרכו לעדכן את המדיניות של CSP כך שתשתמש בגיבובים של סקריפט או חד-פעמיים (nonces) או להשתמש ב-"unsafe-inline" כדי להפעיל את כל הסקריפטים המוטבעים. אם יש לכם סגנונות בתוך השורה, תצטרכו לעדכן את המדיניות של CSP כך שתשתמש בגיבובים או בצפנים חד-פעמיים של סגנון או להשתמש באפשרות "unsafe-inline" כדי לאפשר עיבוד של כל בלוקי הסגנון המוטבעים.
יש לכם עוד שאלות? אל תהססו לשאול ולספק משוב בקבוצת הדיון שלנו ב-pagespeed-insights-discuss.
משוב
האם הדף הזה הועיל לך?