في السنوات الأخيرة، توفر المزيد والمزيد من المنصات لتحسين مشاريع الواجهة الأمامية فرصًا للاستضافة الذاتية أو توكيل موارد الطرف الثالث. Akamai يسمح لك بالضبط لعناوين URL التي يتم إنشاؤها ذاتيًا. لدى Cloudflare تقنية Edge Workers. يمكن فاسترزين عناوين URL الموجودة على الصفحات بحيث تشير إلى موارد الجهات الخارجية الموجودة في المجال الرئيسي للموقع.
إذا كنت تعلم أن خدمات الطرف الثالث المستخدمة في مشروعك لا تتغير كثيرًا، وأن عملية تقديمها للعملاء يمكن تحسينها، فمن المحتمل أنك تفكر في إنشاء وكيل لهذه الخدمات. باستخدام هذا الأسلوب، يمكنك تقريب هذه الموارد من المستخدمين لديك والحصول على تحكم كامل في التخزين المؤقت الخاص بهم من جانب العميل. بالإضافة إلى ذلك، يسمح لك هذا بحماية المستخدمين من المشاكل الناجمة عن "تعطل" خدمة تابعة لجهة خارجية أو تدهور أدائها.
جيد: تحسين الأداء
تعمل الاستضافة الذاتية لموارد شخص آخر على تحسين الأداء بطريقة واضحة جدًا. لا يحتاج المتصفح إلى الوصول إلى DNS مرة أخرى، ولا يحتاج إلى إنشاء اتصال TCP وإجراء مصافحة TLS على مجال جهة خارجية. يمكنك معرفة مدى تأثير الاستضافة الذاتية لموارد شخص آخر على الأداء من خلال مقارنة الشكلين التاليين.
يتم تنزيل موارد الطرف الثالث من مصادر خارجية (مأخوذة من )
يتم تخزين موارد الطرف الثالث في نفس المكان مثل بقية مواد الموقع (المأخوذة من )
تم تحسين الوضع أيضًا من خلال حقيقة أن المتصفح سيستخدم القدرة على تعدد إرسال البيانات وتحديد أولوياتها من اتصال HTTP/2 الذي تم إنشاؤه بالفعل مع المجال الرئيسي.
إذا كنت لا تستضيف موارد الطرف الثالث، فبما أنه سيتم تحميلها من مجال مختلف عن المجال الرئيسي، فلا يمكن تحديد أولوياتها. وهذا سيجعلهم يتنافسون مع بعضهم البعض على النطاق الترددي للعميل. يمكن أن يؤدي ذلك إلى أوقات تحميل للمحتوى المهم لإنشاء صفحة أطول بكثير مما يمكن تحقيقه في ظل الظروف المثالية. تحدث عن أولويات HTTP/2 التي تشرح كل هذا جيدًا.
ويمكن افتراض أن استخدام السمات في وصلات إلى الموارد الخارجية preconnect سوف يساعد في حل المشكلة. ومع ذلك، إذا كان هناك عدد كبير جدًا من هذه الروابط إلى مجالات مختلفة، فيمكن أن يؤدي ذلك في الواقع إلى زيادة التحميل على خط الاتصال في اللحظة الأكثر أهمية.
إذا قمت باستضافة موارد جهة خارجية بنفسك، فيمكنك التحكم في كيفية تقديم هذه الموارد للعميل بالضبط. أي أننا نتحدث عن ما يلي:
- يمكنك التأكد من استخدام خوارزمية ضغط البيانات التي تناسب كل متصفح (Brotli/gzip).
- يمكنك زيادة وقت التخزين المؤقت للموارد التي لا تكون عادةً طويلة بشكل خاص، حتى مع الموفرين الأكثر شهرة (على سبيل المثال، يتم تعيين القيمة المقابلة لعلامة GA على 30 دقيقة).
يمكنك أيضًا تمديد مدة البقاء (TTL) لأحد الموارد، على سبيل المثال، لمدة عام من خلال دمج المحتوى ذي الصلة في إستراتيجية إدارة التخزين المؤقت (تجزئات عنوان URL، وإصدار الإصدارات، وما إلى ذلك). سنتحدث عن هذا أدناه.
▍الحماية من الانقطاعات في تشغيل خدمات الطرف الثالث أو إيقاف تشغيلها
جانب آخر مثير للاهتمام لموارد الطرف الثالث ذاتية الاستضافة هو أنه يسمح لك بتخفيف المخاطر المرتبطة بانقطاع خدمات الطرف الثالث. لنفترض أن حل اختبار A/B التابع لجهة خارجية والذي تستخدمه قد تم تنفيذه كبرنامج نصي للحظر يتم تحميله في القسم الرئيسي بالصفحة. يتم تحميل هذا البرنامج النصي ببطء. إذا فشل تحميل البرنامج النصي المقابل، فستكون الصفحة فارغة. إذا استغرق التحميل وقتًا طويلاً جدًا، فستظهر الصفحة بتأخير طويل. أو لنفترض أن المشروع يستخدم مكتبة تم تنزيلها من مورد CDN تابع لجهة خارجية. لنتخيل أن هذا المورد تعرض للفشل أو تم حظره في بلد معين. مثل هذا الموقف سيؤدي إلى انتهاك منطق الموقع.
لمعرفة كيفية عمل موقعك عند عدم توفر بعض الخدمات الخارجية، يمكنك استخدام قسم SPOF في .
قسم SPOF على webpagetest.org
▍ماذا عن مشاكل التخزين المؤقت للمواد في المتصفحات؟ (تلميح: إنها أسطورة)
قد تعتقد أن استخدام شبكات CDN العامة سيؤدي تلقائيًا إلى أداء أفضل للموارد، نظرًا لأن هذه الخدمات تتمتع بشبكات عالية الجودة إلى حد ما ويتم توزيعها حول العالم. لكن كل شيء في الواقع أكثر تعقيدًا بعض الشيء.
لنفترض أن لدينا عدة مواقع مختلفة: website1.com، website2.com، website3.com. كل هذه المواقع تستخدم مكتبة jQuery. نقوم بتوصيله بهم باستخدام CDN، على سبيل المثال - googleapis.com. يمكنك أن تتوقع أن يقوم المتصفح بتنزيل المكتبة وتخزينها مؤقتًا مرة واحدة، ثم استخدامها عبر المواقع الثلاثة جميعها. قد يؤدي ذلك إلى تقليل الحمل على الشبكة. ربما سيسمح لك هذا بتوفير المال في مكان ما والمساعدة في تحسين أداء الموارد. من وجهة نظر عملية، كل شيء يبدو مختلفا. على سبيل المثال، يحتوي Safari على ميزة تسمى : تستخدم ذاكرة التخزين المؤقت مفاتيح مزدوجة بناءً على مصدر المستند ومصدر مورد الطرف الثالث. مقالة جيدة حول هذا الموضوع.
دراسات قديمة и ، وكذلك الأحدث يوضح بول كالفانو أن الموارد لا يتم تخزينها في ذاكرة التخزين المؤقت للمتصفح للمدة التي قد نتوقعها: "هناك فجوة خطيرة بين وقت التخزين المؤقت لموارد المشروع الخاصة وموارد الطرف الثالث. نحن نتحدث عن خطوط 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 من Chrome
نتيجة استعلام Google Fonts الذي تم تنفيذه من IE10
يوفر Polyfill.io للمتصفح عمليات التعبئة المتعددة التي يحتاجها فقط. يتم ذلك لأسباب تتعلق بالأداء.
على سبيل المثال، دعونا نلقي نظرة على ما يحدث إذا قمت بتشغيل الطلب التالي من متصفحات مختلفة:
استجابةً لمثل هذا الطلب الذي تم تنفيذه من IE10، سيتم استلام 34 كيلو بايت من البيانات. وستكون الإجابة عليه التي يتم تنفيذها من Chrome فارغة.
غاضب: بعض اعتبارات الخصوصية
هذه النقطة هي الأخيرة في الترتيب، ولكنها ليست أقل أهمية. النقطة المهمة هي أن الاستضافة الذاتية لموارد الطرف الثالث على المجال الرئيسي للمشروع أو على المجال الفرعي الخاص به يمكن أن تعرض خصوصية المستخدمين للخطر وتؤثر سلبًا على مشروع الويب الرئيسي.
إذا لم يتم تكوين نظام CDN الخاص بك بشكل صحيح، فقد ينتهي بك الأمر بإرسال ملفات تعريف الارتباط الخاصة بنطاقك إلى خدمة خارجية. إذا لم يتم تنظيم التصفية المناسبة على مستوى CDN، فستتم ملفات تعريف الارتباط الخاصة بجلستك، والتي لا يمكن استخدامها عادةً في JavaScript (مع httponly)، قد يتم إرسالها إلى مضيف أجنبي.
هذا هو بالضبط ما يمكن أن يحدث مع أجهزة التتبع مثل Eulerian أو Criteo. ربما تكون أدوات التتبع التابعة لجهات خارجية قد قامت بتعيين معرف فريد في ملف تعريف الارتباط. إذا كانت جزءًا من مواد الموقع، فيمكنهم قراءة المعرف وفقًا لتقديرهم أثناء عمل المستخدم مع موارد الويب المختلفة.
في هذه الأيام، تتضمن معظم المتصفحات الحماية ضد هذا النوع من سلوك التتبع. ونتيجة لذلك، يستخدم المتتبعون الآن التكنولوجيا ، متنكرين في هيئة نصوصهم الخاصة لمشاريع مختلفة. على وجه التحديد، تقدم أدوات التتبع لأصحاب المواقع إضافة CNAME إلى إعداداتهم لمجال معين، والذي يبدو عنوانه عادةً كمجموعة عشوائية من الأحرف.
على الرغم من أنه لا يوصى بإتاحة ملفات تعريف الارتباط لموقع الويب لجميع النطاقات الفرعية (على سبيل المثال - *.website.com)، فإن العديد من المواقع تفعل ذلك. في هذه الحالة، يتم إرسال ملفات تعريف الارتباط هذه تلقائيًا إلى جهة تعقب مقنعة تابعة لجهة خارجية. ونتيجة لذلك، لم يعد بإمكاننا الحديث عن أي خصوصية.
ويحدث نفس الشيء أيضًا مع رؤوس HTTP ، والتي يتم إرسالها فقط إلى المجال الرئيسي، حيث يمكن استخدامها للإنشاء مستخدم. تأكد من أن خدمة CDN التي تستخدمها تقوم بتصفية هذه الرؤوس بشكل صحيح.
نتائج
إذا كنت تخطط لتنفيذ الاستضافة الذاتية لموارد الطرف الثالث قريبًا، فاسمح لي أن أقدم لك بعض النصائح:
- قم باستضافة مكتبات JS والخطوط وملفات CSS الأكثر أهمية لديك. سيؤدي هذا إلى تقليل مخاطر فشل الموقع أو تدهور الأداء بسبب عدم توفر مورد حيوي للموقع بسبب خطأ من خدمة خارجية.
- قبل تخزين موارد الطرف الثالث مؤقتًا على شبكة CDN، تأكد من استخدام نوع من نظام الإصدار عند تسمية ملفاتها، أو أنه يمكنك إدارة دورة حياة هذه الموارد عن طريق إعادة تعيين ذاكرة التخزين المؤقت لـ CDN يدويًا أو تلقائيًا عند نشر إصدار جديد من النص.
- كن حذرًا جدًا بشأن إعدادات CDN والخادم الوكيل وذاكرة التخزين المؤقت. سيسمح لك هذا بمنع إرسال ملفات تعريف الارتباط لمشروعك أو رؤوسك
Client-Hintsخدمات الطرف الثالث.
القراء الأعزاء! هل تستضيف مواد خاصة بأشخاص آخرين على خوادمك والتي تعد في غاية الأهمية لتشغيل مشاريعك؟
المصدر: www.habr.com