משאבים של צד שלישי מארח עצמי: הטוב, הרע, המכוער

בשנים האחרונות, יותר ויותר פלטפורמות לאופטימיזציה של פרויקטים חזיתיים מציעות הזדמנויות לאירוח עצמי או להעברת משאבים של צד שלישי. Akamai מאפשר לך להגדיר פרמטרים ספציפיים עבור כתובות אתרים שנוצרו בעצמם. ל-Cloudflare יש טכנולוגיית Edge Workers. Fasterzine יכול לשכתב כתובות URL בדפים כך שהן מצביעות על משאבי צד שלישי הממוקמים בדומיין הראשי של האתר.

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

טוב: ביצועים משופרים

אירוח עצמי של משאבים של מישהו אחר משפר את הביצועים בצורה מאוד ברורה. הדפדפן לא צריך לגשת שוב ל-DNS, הוא לא צריך ליצור חיבור TCP ולבצע לחיצת יד של TLS בדומיין של צד שלישי. אתה יכול לראות כיצד אירוח עצמי של משאבים של מישהו אחר משפיע על הביצועים על ידי השוואה בין שני הנתונים הבאים.

משאבים של צד שלישי מורידים ממקורות חיצוניים (נלקחו מ מכאן)

משאבי צד שלישי מאוחסנים באותו מקום כמו שאר חומרי האתר (נלקחו מ מכאן)

המצב משתפר גם מהעובדה שהדפדפן ישתמש ביכולת ריבוי ותעדוף נתונים מחיבור HTTP/2 שכבר הוקם עם הדומיין הראשי.

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

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

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

• אתה יכול להבטיח כי נעשה שימוש באלגוריתם דחיסת הנתונים המתאים ביותר לכל דפדפן (Brotli/gzip).
• אתה יכול להגדיל את זמן האחסון במטמון עבור משאבים שלרוב אינם ארוכים במיוחד, אפילו עם הספקים המוכרים ביותר (לדוגמה, הערך המתאים לתג GA מוגדר ל-30 דקות).

אתה יכול אפילו להרחיב את ה-TTL עבור משאב לשנה, למשל, על ידי שילוב תוכן רלוונטי באסטרטגיית ניהול ה-Caching שלך (hashes של כתובות אתרים, ניהול גרסאות וכו'). נדבר על זה להלן.

▍הגנה מפני הפרעות בהפעלת שירותי צד שלישי או השבתתם

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

כדי לגלות כיצד האתר שלך פועל כאשר שירות חיצוני כלשהו אינו זמין, תוכל להשתמש בסעיף SPOF בנושא webpagetest.org.

מדור SPOF באתר webpagetest.org

▍מה לגבי בעיות בשמירה במטמון של חומרים בדפדפנים? (רמז: זה מיתוס)

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

נניח שיש לנו כמה אתרים שונים: website1.com, website2.com, website3.com. כל האתרים הללו משתמשים בספריית jQuery. אנחנו מחברים את זה אליהם באמצעות CDN, למשל - googleapis.com. אתה יכול לצפות מהדפדפן להוריד ולשמור את הספרייה פעם אחת, ולאחר מכן להשתמש בה בכל שלושת האתרים. זה יכול להפחית את העומס על הרשת. אולי זה יאפשר לך לחסוך כסף איפשהו ולעזור לשפר את ביצועי המשאבים. מנקודת מבט מעשית, הכל נראה אחרת. לדוגמה, לספארי יש תכונה שנקראת מניעת מעקב חכם: המטמון משתמש במפתחות כפולים המבוססים על מקור המסמך והמקור של המשאב של צד שלישי. כאן מאמר טוב בנושא זה.

לימודים ישנים יאהו и פייסבוק, כמו גם אחרונים יותר מחקר Paul Calvano, הראה כי משאבים אינם מאוחסנים במטמונים של דפדפן כל עוד אנו עשויים לצפות: "יש פער רציני בין זמן האחסון במטמון של משאבי פרויקט משלו ומשאבים של צד שלישי. אנחנו מדברים על CSS וגופני אינטרנט. כלומר, ל-95% מהגופנים המקוריים יש חיי מטמון של יותר משבוע, בעוד של-50% מהגופנים של צד שלישי יש חיי מטמון של פחות משבוע! זה נותן למפתחי אינטרנט סיבה משכנעת לארח בעצמם קובצי גופן!"

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

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

הרע: השטן נמצא בפרטים הקטנים

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

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

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

נכון, אם מדברים על חומרים שמתעדכנים בתדירות גבוהה (מנהלי תגים, פתרונות לבדיקות A/B), אז שמירה במטמון באמצעות כלי CDN היא משימה שניתן לפתור, אבל היא הרבה יותר מורכבת. שירותים כמו Commanders Act, פתרון לניהול תגים, משתמשים ב-webhooks בעת פרסום גרסאות חדשות. זה נותן לך את היכולת לאלץ שטיפת מטמון ב-CDN, או, טוב יותר, את היכולת לאלץ עדכון hash או כתובת URL.

▍ אספקה ​​מותאמת של חומרים ללקוחות

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

כאן תוכלו לזכור שני שירותים. הראשון הוא googlefonts.com. השני הוא polyfill.io. שירות Google Fonts מספק, עבור משאב מסוים, קוד CSS שונים, בהתאם ליכולות הדפדפן (מתן קישורים למשאבי woff2 באמצעות unicode-range).

להלן התוצאות של כמה שאילתות של גוגל גופנים שנעשו מדפדפנים שונים.

תוצאת שאילתת גוגל גופנים מ-Chrome

תוצאה של שאילתת Google Fonts שבוצעה מ-IE10

Polyfill.io נותן לדפדפן רק את הפוליפילים שהוא צריך. זה נעשה מטעמי ביצועים.

לדוגמה, בואו נסתכל מה קורה אם תפעיל את הבקשה הבאה מדפדפנים שונים: https://polyfill.io/v3/polyfill.js?features=default

בתגובה לבקשה כזו שתבוצע מ-IE10, יתקבלו 34 KB של נתונים. והתשובה עליה, שתבוצע מכרום, תהיה ריקה.

כועס: כמה שיקולי פרטיות

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

אם מערכת ה-CDN שלך לא מוגדרת כהלכה, אתה עלול לשלוח את קובצי ה-cookie של הדומיין שלך לשירות של צד שלישי. אם סינון נכון אינו מאורגן ברמת ה-CDN, אז קובצי ה-cookie של ההפעלה, שבדרך כלל לא ניתן להשתמש בהם ב-JavaScript (עם httponly), עשוי להישלח למארח זר.

זה בדיוק מה שיכול לקרות עם עוקבים כמו Eulerian או Criteo. ייתכן שעוקבים של צד שלישי הגדירו מזהה ייחודי בקובץ ה-cookie. אם הם היו חלק מחומרי האתר, הם יכלו לקרוא את המזהה לפי שיקול דעתם בזמן שהמשתמש עובד עם משאבי אינטרנט שונים.

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

למרות שלא מומלץ להפוך קובצי Cookie לאתר לזמינים לכל תת-הדומיינים (לדוגמה - *.website.com), אתרים רבים עושים זאת. במקרה זה, עוגיות כאלה נשלחות אוטומטית לגשש צד שלישי מוסווה. כתוצאה מכך, איננו יכולים עוד לדבר על פרטיות כלשהי.

כמו כן, אותו דבר קורה עם כותרות HTTP לקוח-רמזים, שנשלחים רק לדומיין הראשי, מכיוון שניתן להשתמש בהם ליצירת טביעת אצבע דיגיטלית מִשׁתַמֵשׁ. ודא ששירות ה-CDN שבו אתה משתמש מסנן את הכותרות הללו בצורה נכונה.

תוצאות של

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

• ארח את ספריות ה-JS, הגופנים וקבצי ה-CSS החשובים ביותר שלך. זה יקטין את הסיכון לכשל באתר או לפגיעה בביצועים עקב חוסר זמין של משאב חיוני לאתר עקב תקלה של שירות של צד שלישי.
• לפני שאתה שומר משאבי צד שלישי במטמון ב-CDN, ודא שמשתמשים במערכת ניהול גרסאות כלשהי בעת מתן שמות לקבצים שלהם, או שאתה יכול לנהל את מחזור החיים של משאבים אלה על ידי איפוס ידני או אוטומטי של מטמון ה-CDN בעת פרסום גרסה חדשה של התסריט.
• היזהר מאוד לגבי הגדרות ה-CDN, שרת ה-proxy והמטמון שלך. זה יאפשר לך למנוע מהפרויקט או הכותרות שלך לשלוח קובצי Cookie Client-Hints שירותי צד שלישי.

קוראים יקרים! האם אתה מארח חומרים של אנשים אחרים בשרתים שלך שהם חשובים ביותר לתפעול הפרויקטים שלך?

מקור: www.habr.com