התערבות ב-document.write()

Paul Kinlan

האם ראית לאחרונה ב-Developer Console שלך אזהרה כמו זו הבאה ב- Chrome ותהיתי מה זה?

(index):34 A Parser-blocking, cross-origin script,
https://paul.kinlan.me/ad-inject.js, is invoked via document.write().
This may be blocked by the browser if the device has poor network connectivity.

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

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

document.write('<script src="https://example.com/ad-inject.js"></script>');

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

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

אספנו נתונים מניסוי שטח שנמשך 28 ימים ב-1% ממוצרי Chrome למשתמשים יציבים, מוגבלים למשתמשים בחיבורי 2G. ראינו ש-7.6% מכל הטעינות של הדפים ב-2G כלל לפחות סקריפט אחד חוצה-אתרים וחוסם את הניתוח, נוספו באמצעות document.write() למסמך ברמה העליונה. כתוצאה מחסימה ובעקבות זאת, ראינו את השיפורים הבאים בטעינות האלה:

  • 10% יותר טעינת דפים שמגיעים אל הצגת תוכן ראשוני (First-Party) (אישור חזותי למשתמש שהדף נטען ביעילות), 25% יותר טעינות דפים המגיעות למצב של ניתוח מלא ו-10% פחות טעינות מחדש רמיזה לירידה בתסכול של המשתמשים.
  • ירידה של 21% מהזמן הממוצע (יותר משנייה אחת מהר יותר) עד הצגת תוכן ראשוני (FCP)
  • משך הזמן הממוצע שנדרש לניתוח דף הצטמצם ב-38%, שמייצג של כמעט שש שניות, מה שמקצר באופן משמעותי את הזמן שנדרש כדי להציג את מה שחשוב למשתמש.

על סמך הנתונים האלה, Chrome, החל מגרסה 55, מתערב בשם כל המשתמשים למשתמשים כשאנחנו מזהים דפוס שלילי מוכר זה על ידי שינוי האופן שבו document.write() מטופלות ב-Chrome (עיינו בסטטוס של Chrome). באופן ספציפי, Chrome לא יפעיל את רכיבי <script> שהוחדרו דרך document.write() כאשר כל התנאים הבאים מתקיימים:

  1. המשתמש נמצא בחיבור איטי, במיוחד כשהמשתמש נמצא ב-2G. (בתוך בעתיד, ייתכן שהשינוי יורחב למשתמשים אחרים שחיבורים איטיים, כגון 3G איטי או Wi-Fi איטי).
  2. הקובץ document.write() נמצא במסמך ברמה העליונה. ההתערבות לא חלות על סקריפטים document.write בתוך iframes כי הם לא חוסמים את עיבוד של הדף הראשי.
  3. הסקריפט ב-document.write() חוסם ניתוח. סקריפטים עם 'async' או 'defer' המאפיינים עדיין יופעלו.
  4. הסקריפט לא מתארח באותו אתר. במילים אחרות, Chrome לא להתערב עבור סקריפטים עם eTLD+1 תואם (למשל, סקריפט שמתארח ב- js.example.org נוסף ל-www.example.org).
  5. הסקריפט עדיין לא נמצא במטמון ה-HTTP של הדפדפן. סקריפטים במטמון לא יגרום לעיכוב ברשת והוא ימשיך לפעול.
  6. הבקשה של הדף היא לא טעינה מחדש. Chrome לא יתערב אם המשתמש הפעיל טעינה מחדש ויבצע את הדף כרגיל.

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

איך אפשר לפתור את הבעיה הזאת?

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

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

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

אם הספק נותן לך קטע קוד שכולל את document.write(), הוא ייתכן שתוכלו להוסיף את המאפיין async לרכיב הסקריפט, או כדי להוסיף את רכיבי הסקריפט עם רכיבי DOM API כמו document.appendChild() או parentNode.insertBefore().

איך לזהות מתי האתר שלכם מושפע

יש מספר רב של קריטריונים שקובעים אם ההגבלה נאכפת, אז איך תוכלו לדעת אם יש לכך השפעה עליכם?

זיהוי מתי משתמש נמצא ב-2G

כדי להבין את ההשפעה הפוטנציאלית של השינוי הזה, עליך להבין תחילה כמה מהמשתמשים שלכם יהיו ברשת 2G. ניתן לזהות את סוג הרשת הנוכחי של המשתמש במהירות באמצעות ה-Network Information API, זמינה ב-Chrome ולאחר מכן שולחת התראה לגבי מדדי המשתמשים האנליטיים או מדדי המשתמשים האמיתיים מערכות RUM.

if(navigator.connection &&
    navigator.connection.type === 'cellular' &&
    navigator.connection.downlinkMax <= 0.115) {
    // Notify your service to indicate that you might be affected by this restriction.
}

בדיקת אזהרות בכלי הפיתוח ל-Chrome

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

אזהרה לגבי כתיבת מסמך.

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

בדיקת כותרות ה-HTTP במשאב הסקריפט

אם סקריפט שהוכנס דרך document.write נחסם, Chrome ישלח את הבאה למשאב המבוקש:

Intervention: <https://shorturl/relevant/spec>;

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

Intervention: <https://shorturl/relevant/spec>; level="warning"

כותרת ההתערבות תישלח כחלק מבקשת ה-GET עבור הסקריפט (באופן אסינכרוני במקרה של התערבות בפועל).

מה צופן העתיד?

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

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

עם הזמן, אנחנו מנסים להתערב אם למשתמש כלשהו יש חיבור איטי (כלומר, 3G או Wi-Fi איטיים). יש לעקוב אחר הרשומה הבאה בסטטוס Chrome.

צריכים מידע נוסף?

מידע נוסף זמין במקורות המידע הנוספים: