الاستضافة الذاتية لموارد الطرف الثالث: جيدة ، سيئة ، شريرة

في السنوات الأخيرة ، توفر المزيد والمزيد من المنصات لتحسين مشاريع الواجهة الأمامية فرصًا لاستضافة أو وكيل مستقل لموارد الطرف الثالث. يتيح لك Akamai تعيين معلمات محددة لعناوين URL ذاتية الإنشاء. لدى Cloudflare تقنية Edge Edgeers. يمكن لـ Fasterzine إعادة كتابة عناوين URL على الصفحات بحيث تشير إلى موارد الطرف الثالث الموجودة في المجال الرئيسي للموقع.



إذا كنت تعرف أن خدمات الجهات الخارجية المستخدمة في مشروعك لا تتغير كثيرًا ، وأنه يمكن تحسين عملية تقديمها للعملاء ، فربما تفكر في توفير مثل هذه الخدمات. باستخدام هذا النهج ، يمكنك "تقريب" هذه الموارد من المستخدمين والحصول على مزيد من التحكم في التخزين المؤقت على جانب العميل. هذا ، بالإضافة إلى ذلك ، يسمح لك بحماية المستخدمين من المشاكل الناجمة عن "السقوط" لخدمة طرف ثالث أو تدهور أدائها.

جيد: زيادة الإنتاجية

الاستضافة الذاتية لموارد الآخرين تعمل على تحسين الأداء بطريقة واضحة للغاية. لا يحتاج المستعرض إلى الوصول إلى DNS مرة أخرى ، ولا يحتاج إلى تأسيس اتصال TCP وتنفيذ مصافحة TLS على مجال تابع لجهة خارجية. يمكن ملاحظة مدى تأثير الاستضافة المستقلة لموارد الآخرين على الأداء من خلال مقارنة الشكلين التاليين.


يتم تنزيل موارد الطرف الثالث من مصادر خارجية (مأخوذة من هنا )


يتم تخزين موارد الجهات الخارجية في نفس المكان مثل بقية مواد الموقع (مأخوذة من هنا )

تم تحسين الموقف أيضًا من خلال حقيقة أن المتصفح سيستخدم إمكانيات تعدد إرسال وترتيب أولويات اتصال HTTP / 2 ، والذي تم إنشاؤه بالفعل مع المجال الرئيسي.

إذا لم تستضيف موارد جهة خارجية ، فلن يتم تنزيلها من مجال آخر بخلاف المجال الرئيسي ، فلا يمكن تحديد أولوياتها. سيقودهم ذلك إلى التنافس مع بعضهم البعض على النطاق الترددي للعميل. يمكن أن يؤدي هذا إلى حقيقة أن وقت تحميل المواد المهمة لتشكيل الصفحة سيكون أطول بكثير من الوقت الممكن تحقيقه في ظل مجموعة مثالية من الظروف. هنا حديث عن تحديد الأولويات HTTP / 2 الذي يفسر كل هذا بشكل جيد للغاية.

يمكن افتراض أن استخدام سمات preconnect في روابط الموارد الخارجية سيساعد في حل المشكلة. ومع ذلك ، إذا كان هناك الكثير من هذه الروابط لمجالات مختلفة ، فإن هذا ، في الواقع ، يمكن أن يثقل كاهل خط الاتصال في اللحظة الأكثر أهمية.

إذا كنت تستضيف موارد جهة خارجية بمفردك ، يمكنك التحكم في كيفية منح هذه الموارد للعميل. وهي نتحدث عن ما يلي:

• يمكنك التأكد من تطبيق خوارزمية ضغط البيانات الأنسب لكل مستعرض (Brotli / gzip).
• يمكنك زيادة وقت التخزين المؤقت للموارد ، والتي عادة ما لا تكون كبيرة جدًا حتى بالنسبة لموفري الخدمة المعروفين (على سبيل المثال ، يتم تعيين القيمة المقابلة لعلامة GA إلى 30 دقيقة).

يمكنك حتى تمديد TTL لمورد ، على سبيل المثال ، ما يصل إلى عام من خلال تضمين المواد المناسبة في استراتيجية إدارة التخزين المؤقت الخاصة بك (تجزئة URL ، الإصدار ، وما إلى ذلك). سنتحدث عن هذا أدناه.

▍ الحماية ضد الانقطاع في تشغيل خدمات الطرف الثالث أو من انقطاع الاتصال بها

يتمثل الجانب الآخر المثير للاهتمام للاستضافة المستقلة لموارد الطرف الثالث في أن هذا يتيح لك تخفيف المخاطر المرتبطة بالانقطاع في تشغيل خدمات الطرف الثالث. افترض أن حل الطرف الثالث الخاص بك لاختبار A / B قد تم تطبيقه كنص برمجي للحظر تم تحميله في قسم الرأس بالصفحة. يتم تحميل هذا البرنامج النصي ببطء. إذا فشل تحميل البرنامج النصي المقابل ، فستكون الصفحة فارغة. إذا استغرق تحميله الكثير من الوقت ، فستظهر الصفحة بتأخير طويل. أو افترض أن المشروع يستخدم مكتبة تم تحميلها من مورد CDN لجهة خارجية. تخيل أن هذا المورد تعطل أو تم حظره في بلد معين. مثل هذا الموقف سيؤدي إلى انتهاك لمنطق الموقع.

لمعرفة كيفية عمل موقعك في ظروف عدم إمكانية الوصول إلى بعض الخدمات الخارجية ، يمكنك استخدام قسم SPOF على webpagetest.org .


قسم SPOF على webpagetest.org

▍ ماذا عن مشاكل التخزين المؤقت في المتصفحات؟ (تلميح: هذه أسطورة)

قد تعتقد أن استخدام شبكات CDN المتاحة للجمهور سيؤدي تلقائيًا إلى أداء أفضل للموارد ، حيث أن هذه الخدمات لها شبكات جيدة إلى حد ما ويتم توزيعها في جميع أنحاء العالم. ولكن كل شيء ، في الواقع ، هو أكثر تعقيدا قليلا.

لنفترض أن لدينا عدة مواقع مختلفة: website1.com ، website2.com ، website3.com. تستخدم كل هذه المواقع مكتبة jQuery. نقوم بتوصيلها لهم باستخدام CDN ، على سبيل المثال googleapis.com. يمكنك أن تتوقع من المتصفح تنزيل المكتبة وتخزينها مؤقتًا مرة واحدة ، ثم استخدامها عند العمل مع المواقع الثلاثة. هذا يمكن أن تقلل من الحمل على الشبكة. ربما هذا سيوفر المال في مكان ما ويساعد على تحسين إنتاجية الموارد. من وجهة نظر عملية ، كل شيء يبدو مختلفًا. على سبيل المثال ، يقوم Safari بتنفيذ ميزة تسمى " تعقب التتبع الذكي" : تستخدم ذاكرة التخزين المؤقت مفاتيح مزدوجة بناءً على مصدر المستند ومصدر مورد تابع لجهة خارجية. هنا مقال جيد حول هذا الموضوع.

تُظهر أبحاث Yahoo و Facebook القديمة ، بالإضافة إلى الأبحاث الحديثة التي أجراها Paul Calvano ، أن الموارد لا يتم تخزينها في ذاكرة التخزين المؤقت للمتصفح طالما كنا قد توقعنا: "توجد فجوة خطيرة بين وقت التخزين المؤقت لموارد مشروعنا وطرف ثالث. إنه حول CSS وخطوط الويب. أي أن مدة التخزين المؤقت لـ 95٪ من الخطوط الخاصة بها تتجاوز أسبوعًا ، في حين أن مدة التخزين المؤقت البالغة 50٪ من الخطوط الخارجية أقل من أسبوع! هذا يعطي مطوري الويب سببًا جيدًا لاستضافة ملفات الخطوط الذاتية! "

نتيجةً لذلك ، إذا قمت باستضافة مواد لأشخاص آخرين ، فلن تلاحظ مشاكل في الأداء ناتجة عن التخزين المؤقت للمستعرض.

الآن وبعد أن درسنا نقاط القوة في موارد الطرف الثالث التي تستضيف نفسها ، دعونا نتحدث عن كيفية التمييز بين التنفيذ الجيد لهذا النهج والتطبيق السيئ.

سيئة: الشيطان في التفاصيل

لا يمكن إجراء نقل موارد الجهة الخارجية إلى نطاقك تلقائيًا دون الاهتمام بالتخزين المؤقت الصحيح لهذه الموارد.

واحدة من القضايا الرئيسية هنا هو التخزين المؤقت الوقت. على سبيل المثال ، يتم تضمين معلومات الإصدار في أسماء البرامج النصية لجهات خارجية مثل: jquery-3.4.1.js . لن يتغير هذا الملف في المستقبل ، ونتيجة لذلك ، لن يتسبب ذلك في أي مشكلة في التخزين المؤقت.

ولكن إذا لم يتم تطبيق نظام تعيين إصدارات معين عند العمل مع الملفات ، فإن البرامج النصية المخزنة مؤقتًا ، والتي تتغير محتوياتها عندما يتغير اسم الملف ، قد تصبح قديمة. يمكن أن يصبح هذا مشكلة خطيرة ، لأنه ، على سبيل المثال ، لا يسمح بإدخال إصلاحات الأمان تلقائيًا في البرامج النصية التي يجب أن يتلقاها العملاء في أقرب وقت ممكن. سيتعين على المطور بذل جهد لتحديث هذه البرامج النصية في ذاكرة التخزين المؤقت. بالإضافة إلى ذلك ، يمكن أن يسبب هذا تعطل التطبيق بسبب حقيقة أن التعليمات البرمجية المستخدمة على العميل من ذاكرة التخزين المؤقت تختلف عن أحدث إصدار من التعليمات البرمجية التي تم تصميم جزء خادم المشروع.

صحيح ، إذا تحدثنا عن المواد التي يتم تحديثها بشكل متكرر (مديرو العلامات ، حلول لاختبار A / B) ، فإن تخزينها مؤقتًا باستخدام CDN هي مهمة يمكن حلها ، لكنها بالفعل أكثر تعقيدًا. خدمات مثل Commanders Act ، حلول إدارة العلامات ، استخدم روابط الويب لنشر إصدارات جديدة. هذا يجعل من الممكن تنظيم مسح ذاكرة التخزين المؤقت على CDN ، أو حتى أفضل من القدرة على استدعاء تحديث التجزئة أو إصدار URL.

▍ التسليم التكيفي للمواد للعملاء

بالإضافة إلى ذلك ، عندما نتحدث عن التخزين المؤقت ، يجب أن نأخذ في الاعتبار أيضًا حقيقة أن إعدادات التخزين المؤقت المستخدمة على CDN قد لا تكون مناسبة لبعض موارد الطرف الثالث. على سبيل المثال ، يمكن أن تستخدم هذه الموارد تقنية استنشاق وكيل المستخدم ، وهي خدمة تكيفية ، لتزويد متصفحات محددة بإصدارات من المواد المحسنة خصيصًا لهذه المتصفحات. تعتمد هذه التقنيات ، للتعرف على إمكانيات المستعرض ، على التعبيرات العادية أو على قاعدة بيانات تجمع المعلومات حول رأس HTTP User-Agent . عند التعرف على المتصفح الذي يتعاملون معه ، يقدمون له مواد مصممة له.

هنا يمكنك تذكر خدمتين. الأول هو googlefonts.com. والثاني هو polyfill.io. توفر خدمة Google Fonts ، لبعض الموارد ، العديد من كود CSS اعتمادًا على إمكانيات المتصفح (إعطاء روابط إلى موارد woff2 باستخدام unicode-range ).

في ما يلي نتائج لاستعلامات Google Fonts المصممة من متصفحات مختلفة.


نتيجة استعلام الخطوط الكروم


نتيجة استعلام الخطوط من Google مصنوعة من IE10

يعطي Polyfill.io المتصفح فقط تلك polyfills التي يحتاجها. يتم ذلك لأسباب تتعلق بالأداء.

على سبيل المثال ، ألق نظرة على ما يحدث إذا قمت بتشغيل الطلب التالي من متصفحات مختلفة: https://polyfill.io/v3/polyfill.js؟features=default

استجابة لمثل هذا الطلب المقدم من IE10 ، ستأتي 34 كيلو بايت من البيانات. وستكون الإجابة عليه ، المصنوعة من Chrome ، فارغة.

غاضب: بعض اعتبارات الخصوصية

هذا العنصر هو الأخير بالترتيب ، ولكن ليس في الأهمية. نحن نتحدث عن حقيقة أن الاستضافة المستقلة لموارد الطرف الثالث على المجال الرئيسي للمشروع أو في نطاقه الفرعي يمكن أن يضر بخصوصية المستخدمين ويؤثر سلبًا على مشروع الويب الرئيسي.

إذا لم يتم تكوين نظام CDN بشكل صحيح ، فقد ينتهي الأمر بإرسال ملفات تعريف الارتباط من المجال الخاص بك إلى خدمة تابعة لجهة خارجية. إذا لم يتم تنظيم التصفية المناسبة على مستوى CDN ، فإن ملفات تعريف الارتباط الخاصة بالجلسة ، والتي لا يمكن استخدامها في الظروف العادية في JavaScript (مع سمة httponly ) ، يمكن إرسالها إلى مضيف خارجي.

هذا هو بالضبط ما يمكن أن يحدث مع بتتبع مثل Eulerian أو Criteo. يمكن أن تتعقب برامج تتبع الجهات الخارجية معرفًا فريدًا في ملفات تعريف الارتباط. إذا كانت جزءًا من مواد المواقع ، فيمكنهم قراءة المعرف وفقًا لتقديرهم أثناء عمل المستخدم مع موارد الويب المختلفة.

في الوقت الحاضر ، تشمل معظم المتصفحات حماية ضد مثل هذا السلوك من تعقب. نتيجة لذلك ، يستخدم المتتبعون الآن تقنية CNAME Cloaking ، متنكرين في زي البرامج النصية الخاصة بهم لمشاريع مختلفة. أي أن المتتبعين يعرضون على مالكي المواقع إضافة CNAME إلى إعدادات المجال الخاصة بهم لنطاق معين ، والذي يبدو عنوانه عادةً كمجموعة عشوائية من الأحرف.

على الرغم من أنه لا يوصى بأن تكون ملفات تعريف الارتباط الخاصة بالموقع متاحة لجميع النطاقات الفرعية (على سبيل المثال ، * .website.com) ، فإن العديد من المواقع تقوم بذلك. في هذه الحالة ، يتم إرسال ملفات تعريف الارتباط هذه تلقائيًا إلى متعقب الطرف الثالث المقنع. نتيجة لذلك ، لم يعد بإمكانك التحدث عن أي خصوصية.

بالإضافة إلى ذلك ، يحدث نفس الشيء مع رؤوس HTTP Client-Hints ، والتي يتم إرسالها فقط إلى المجال الرئيسي ، حيث يمكن استخدامها لإنشاء بصمة رقمية للمستخدم. يرجى التأكد من أن خدمة CDN التي تستخدمها تقوم بتصفية هذه الرؤوس بشكل صحيح.

النتائج

إذا كنت ستقدم قريبًا استضافة مستقلة لموارد الطرف الثالث - دعني أقدم لك بعض النصائح:

• استضافة أهم مكتبات JS والخطوط وملفات CSS. سيؤدي ذلك إلى تقليل مخاطر حدوث فشل في الموقع أو انخفاض في أدائه نتيجة لحقيقة أن المورد الحيوي لموقع العمل لم يكن متاحًا بسبب خدمة طرف ثالث.
• قبل التخزين المؤقت لموارد الطرف الثالث على CDN ، تأكد من استخدام نظام الإصدار عند تسمية ملفاتهم ، أو أنه يمكنك التحكم في دورة حياة هذه الموارد عن طريق مسح ذاكرة التخزين المؤقت CDN يدويًا أو تلقائيًا عند نشر نسخة جديدة من البرنامج النصي.
• كن حذرًا جدًا بشأن إعدادات CDN والخادم الوكيل وذاكرة التخزين المؤقت. سيتيح لك ذلك منع إرسال ملفات تعريف الارتباط الخاصة بمشروعك أو رؤوس Client-Hints إلى خدمات الجهات الخارجية.

أعزائي القراء! هل تنشر مواد لأشخاص آخرين على خوادمك التي تعتبر مهمة للغاية لمشاريعك؟