منابع شخص ثالث خود میزبانی: خوب، بد، زشت

در سال‌های اخیر، پلتفرم‌های بیشتر و بیشتری برای بهینه‌سازی پروژه‌های فرانت‌اند فرصت‌هایی را برای خود میزبانی یا پروکسی منابع شخص ثالث ارائه می‌دهند. Akamai به شما امکان تنظیم را می دهد پارامترهای خاص برای URL های خود تولید شده Cloudflare دارای فناوری Edge Workers است. فاسترزین می تواند بازنویسی نشانی‌های اینترنتی در صفحات به گونه‌ای که به منابع شخص ثالث واقع در دامنه اصلی سایت اشاره می‌کنند.

اگر می‌دانید که سرویس‌های شخص ثالث مورد استفاده در پروژه شما اغلب تغییر نمی‌کنند و روند ارائه آنها به مشتریان می‌تواند بهبود یابد، احتمالاً به فکر پروکسی کردن چنین خدماتی هستید. با این رویکرد، به خوبی می توانید این منابع را به کاربران خود نزدیک کنید و کنترل کامل تری بر حافظه پنهان آنها در سمت کلاینت به دست آورید. علاوه بر این، این به شما امکان می دهد تا از کاربران در برابر مشکلات ناشی از "خرابی" یک سرویس شخص ثالث یا کاهش عملکرد آن محافظت کنید.

خوب: بهبود عملکرد

خود میزبانی منابع شخص دیگری عملکرد را به روشی بسیار واضح بهبود می بخشد. مرورگر نیازی به دسترسی مجدد به DNS ندارد، نیازی به ایجاد یک اتصال TCP و انجام یک دست دادن TLS در یک دامنه شخص ثالث ندارد. با مقایسه دو شکل زیر می توانید ببینید که چگونه میزبانی منابع شخص دیگری بر عملکرد تأثیر می گذارد.

منابع شخص ثالث از منابع خارجی دانلود می شوند (برگرفته از از این رو)

منابع شخص ثالث در همان مکانی ذخیره می شوند که بقیه مطالب سایت (برگرفته از از این رو)

وضعیت همچنین با این واقعیت بهبود یافته است که مرورگر از قابلیت چندگانه سازی و اولویت بندی داده ها از اتصال HTTP/2 که قبلاً با دامنه اصلی ایجاد شده است استفاده می کند.

اگر منابع شخص ثالث را میزبانی نکنید، از آنجایی که آنها از دامنه ای متفاوت از دامنه اصلی بارگیری می شوند، نمی توان آنها را اولویت بندی کرد. این باعث می شود که آنها برای پهنای باند مشتری با یکدیگر رقابت کنند. این می تواند منجر به زمان بارگذاری محتوای حیاتی برای ساخت صفحه ای شود که بسیار طولانی تر از آنچه در شرایط ایده آل قابل دستیابی است. در اینجا این است صحبت در مورد اولویت بندی HTTP/2 که همه اینها را به خوبی توضیح می دهد.

می توان فرض کرد که استفاده از ویژگی ها در پیوند به منابع خارجی preconnect در حل مشکل کمک خواهد کرد. با این حال، اگر تعداد زیادی از این پیوندها به دامنه های مختلف وجود داشته باشد، در واقع می تواند خط ارتباطی را در حساس ترین لحظه بارگذاری کند.

اگر خودتان منابع شخص ثالث را میزبانی کنید، می توانید کنترل کنید که دقیقاً چگونه این منابع به مشتری داده می شود. یعنی در مورد موارد زیر صحبت می کنیم:

• می توانید اطمینان حاصل کنید که از الگوریتم فشرده سازی داده که به بهترین وجه برای هر مرورگر مناسب است استفاده می شود (Brotli/gzip).
• می‌توانید زمان کش کردن منابعی را که معمولاً زیاد طولانی نیستند، حتی با شناخته‌شده‌ترین ارائه‌دهندگان افزایش دهید (به عنوان مثال، مقدار مربوطه برای برچسب GA روی 30 دقیقه تنظیم شده است).

حتی می‌توانید TTL را برای یک منبع با گنجاندن محتوای مرتبط در استراتژی مدیریت حافظه پنهان خود (هش URL، نسخه‌سازی و غیره) مثلاً به یک سال افزایش دهید. در ادامه در این مورد صحبت خواهیم کرد.

▍محافظت در برابر وقفه در عملکرد خدمات شخص ثالث یا خاموش شدن آنها

یکی دیگر از جنبه های جالب منابع شخص ثالث خود میزبانی این است که به شما امکان می دهد خطرات مربوط به قطع شدن خدمات شخص ثالث را کاهش دهید. بیایید فرض کنیم راه حل تست A/B شخص ثالثی که استفاده می کنید به عنوان یک اسکریپت مسدود کننده که در قسمت head صفحه بارگیری می شود، پیاده سازی شده است. این اسکریپت به کندی بارگیری می شود. اگر اسکریپت مربوطه بارگذاری نشود، صفحه خالی خواهد بود. اگر زمان زیادی برای بارگذاری طول بکشد، صفحه با تاخیر زیادی ظاهر می شود. یا، فرض کنید پروژه از یک کتابخانه دانلود شده از یک منبع CDN شخص ثالث استفاده می کند. بیایید تصور کنیم که این منبع در کشور خاصی با شکست مواجه شده یا مسدود شده است. چنین وضعیتی منجر به نقض منطق سایت خواهد شد.

برای اطلاع از نحوه عملکرد سایت شما در زمانی که برخی از سرویس های خارجی در دسترس نیستند، می توانید از بخش SPOF استفاده کنید webpagetest.org.

بخش SPOF در webpagetest.org

▍در مورد مشکلات مربوط به کش کردن مطالب در مرورگرها چطور؟ (اشاره: این یک افسانه است)

ممکن است فکر کنید که استفاده از CDN های عمومی به طور خودکار منجر به عملکرد بهتر منابع می شود، زیرا این سرویس ها دارای شبکه های نسبتاً با کیفیت هستند و در سراسر جهان توزیع می شوند. اما در واقع همه چیز کمی پیچیده تر است.

فرض کنید چندین سایت مختلف داریم: website1.com، website2.com، website3.com. همه این سایت ها از کتابخانه jQuery استفاده می کنند. ما آن را با استفاده از یک CDN به آنها متصل می کنیم، به عنوان مثال - googleapis.com. می توانید انتظار داشته باشید که مرورگر یک بار کتابخانه را دانلود و کش کند و سپس از آن در هر سه سایت استفاده کند. این می تواند بار روی شبکه را کاهش دهد. شاید این به شما امکان می دهد در جایی پول پس انداز کنید و به بهبود عملکرد منابع کمک کنید. از نقطه نظر عملی، همه چیز متفاوت به نظر می رسد. به عنوان مثال، سافاری یک ویژگی به نام دارد جلوگیری از ردیابی هوشمند: حافظه پنهان از کلیدهای دوگانه بر اساس منبع سند و منبع منبع شخص ثالث استفاده می کند. در اینجا این است مقاله خوبی در این زمینه

مطالعات قدیمی یاهو и فیس بوک، و همچنین جدیدتر مطالعه پل کالوانو، نشان می‌دهد که منابع تا زمانی که انتظار داریم در حافظه پنهان مرورگر ذخیره نمی‌شوند: «یک شکاف جدی بین زمان ذخیره‌سازی منابع خود پروژه و منابع شخص ثالث وجود دارد. ما در مورد CSS و فونت های وب صحبت می کنیم. یعنی، 95٪ از فونت های بومی بیش از یک هفته طول عمر کش دارند، در حالی که 50٪ فونت های شخص ثالث کمتر از یک هفته عمر کش دارند! این به توسعه دهندگان وب دلیل قانع کننده ای می دهد تا خودشان فایل های فونت را میزبانی کنند!»

در نتیجه، اگر محتوای دیگران را میزبانی کنید، متوجه هیچ مشکلی در عملکرد ناشی از کش مرورگر نخواهید شد.

اکنون که نقاط قوت خود میزبانی شخص ثالث را پوشش دادیم، بیایید در مورد نحوه تشخیص اجرای خوب این رویکرد از روش بد صحبت کنیم.

بد: شیطان در جزئیات است

انتقال منابع شخص ثالث به دامنه خودتان بدون اطمینان از اینکه چنین منابعی به درستی در حافظه پنهان هستند، به صورت خودکار انجام نمی شود.

یکی از مشکلات اصلی در اینجا زمان کش است. به عنوان مثال، اطلاعات نسخه در نام های اسکریپت شخص ثالث مانند این گنجانده شده است: jquery-3.4.1.js. چنین فایلی در آینده تغییر نخواهد کرد و در نتیجه هیچ مشکلی در کش آن ایجاد نخواهد کرد.

اما اگر در هنگام کار با فایل‌ها از برخی از طرح‌های نسخه‌سازی استفاده نشود، ممکن است اسکریپت‌های حافظه پنهان، که محتوای آن‌ها تغییر می‌کند در حالی که نام فایل بدون تغییر باقی می‌ماند، قدیمی شوند. این می تواند یک مشکل جدی باشد، زیرا، برای مثال، اجازه نمی دهد وصله های امنیتی خودکار به اسکریپت هایی که کلاینت ها باید در سریع ترین زمان ممکن دریافت کنند، اضافه شوند. توسعه دهنده باید تلاش کند تا چنین اسکریپت هایی را در حافظه پنهان به روز کند. علاوه بر این، این می تواند باعث خرابی برنامه شود، زیرا کد استفاده شده روی مشتری از حافظه نهان با آخرین نسخه کدی که بخش سرور پروژه برای آن طراحی شده است، متفاوت است.

درست است، اگر ما در مورد موادی صحبت کنیم که به طور مکرر به روز می شوند (مدیران برچسب، راه حل هایی برای تست A/B)، ذخیره آنها با استفاده از ابزارهای CDN یک کار قابل حل است، اما بسیار پیچیده تر است. سرویس هایی مانند Commanders Act، یک راه حل مدیریت برچسب، هنگام انتشار نسخه های جدید از وب هوک ها استفاده می کنند. این به شما این امکان را می‌دهد که به اجبار یک حافظه پنهان روی CDN را تخلیه کنید، یا بهتر از آن، توانایی به‌روزرسانی هش یا URL را اجباری کنید.

▍تحویل تطبیقی ​​مواد به مشتریان

علاوه بر این، زمانی که در مورد کش صحبت می کنیم، باید این واقعیت را در نظر بگیریم که تنظیمات کش مورد استفاده در CDN ممکن است برای برخی از منابع شخص ثالث مناسب نباشد. به عنوان مثال، چنین منابعی ممکن است از فناوری sniffing عامل کاربر (سرویس تطبیقی) برای سرویس دادن به مرورگرهای خاص با نسخه هایی از محتوای بهینه شده به طور خاص برای آن مرورگرها استفاده کنند. این فناوری‌ها به عبارات منظم یا پایگاه داده‌ای از اطلاعات هدر HTTP برای کشف قابلیت‌های مرورگر متکی هستند. User-Agent. هنگامی که آنها می دانند با کدام مرورگر سروکار دارند، مواد طراحی شده برای آن را به آن می دهند.

در اینجا می توانید دو سرویس را به خاطر بسپارید. اولین مورد googlefonts.com است. مورد دوم polyfill.io است. سرویس فونت گوگل، بسته به قابلیت های مرورگر، برای یک منبع خاص، کدهای مختلف CSS را ارائه می دهد (به منابع woff2 پیوند می دهد با استفاده از unicode-range).

در اینجا نتایج چند جستار Google Fonts از مرورگرهای مختلف ارائه شده است.

نتیجه پرس و جو فونت های گوگل از کروم

نتیجه جستجوی فونت های گوگل از IE10 اجرا شد

Polyfill.io فقط polyfill های مورد نیاز مرورگر را می دهد. این کار به دلایل عملکردی انجام می شود.

برای مثال، بیایید نگاهی بیندازیم که اگر درخواست زیر را از مرورگرهای مختلف اجرا کنید چه اتفاقی می‌افتد: https://polyfill.io/v3/polyfill.js?features=default

در پاسخ به چنین درخواستی که از IE10 اجرا شده است، 34 کیلوبایت داده دریافت خواهد شد. و پاسخ آن که از کروم اجرا شده است خالی خواهد بود.

عصبانی: برخی ملاحظات حفظ حریم خصوصی

این نکته در مرتبه آخر است، اما مهم نیست. نکته این است که خود میزبانی منابع شخص ثالث در دامنه اصلی پروژه یا در زیر دامنه آن می تواند حریم خصوصی کاربران را به خطر بیندازد و بر پروژه اصلی وب تأثیر منفی بگذارد.

اگر سیستم CDN شما به درستی پیکربندی نشده باشد، ممکن است در نهایت کوکی های دامنه خود را به یک سرویس شخص ثالث ارسال کنید. اگر فیلترینگ مناسب در سطح CDN سازماندهی نشده باشد، کوکی های جلسه شما، که معمولاً نمی توانند در جاوا اسکریپت استفاده شوند (با httponly)، ممکن است برای یک میزبان خارجی ارسال شود.

این دقیقاً همان چیزی است که می تواند با ردیاب هایی مانند Eulerian یا Criteo اتفاق بیفتد. ردیاب های شخص ثالث ممکن است یک شناسه منحصر به فرد در کوکی تنظیم کرده باشند. اگر آنها بخشی از مطالب سایت بودند، می توانستند شناسه را به صلاحدید خود بخوانند در حالی که کاربر با منابع مختلف وب کار می کرد.

این روزها، اکثر مرورگرها از محافظت در برابر این نوع رفتار ردیاب استفاده می کنند. در نتیجه، ردیاب ها اکنون از فناوری استفاده می کنند CNAME Cloaking، به عنوان فیلمنامه های خود برای پروژه های مختلف ظاهر می شوند. یعنی، ردیاب‌ها به صاحبان سایت پیشنهاد می‌کنند که یک CNAME را برای یک دامنه خاص به تنظیمات خود اضافه کنند، که آدرس آن معمولاً شبیه مجموعه‌ای تصادفی از کاراکترها است.

اگرچه توصیه نمی شود کوکی های وب سایت را برای همه زیر دامنه ها (به عنوان مثال - *.website.com) در دسترس قرار دهید، بسیاری از سایت ها این کار را انجام می دهند. در این صورت، چنین کوکی هایی به طور خودکار به یک ردیاب شخص ثالث مبدل فرستاده می شوند. در نتیجه، دیگر نمی توانیم در مورد حریم خصوصی صحبت کنیم.

همچنین، همین اتفاق در مورد هدرهای HTTP نیز می افتد مشتری - نکات، که فقط به دامنه اصلی ارسال می شوند، زیرا می توان از آنها برای ایجاد استفاده کرد اثر انگشت دیجیتال کاربر. مطمئن شوید که سرویس CDN مورد استفاده شما این هدرها را به درستی فیلتر می کند.

نمایش نتایج: از

اگر قصد دارید به زودی میزبانی منابع شخص ثالث را پیاده سازی کنید، اجازه دهید نکاتی را به شما ارائه دهم:

• مهم‌ترین کتابخانه‌های JS، فونت‌ها و فایل‌های CSS خود را میزبانی کنید. این امر خطر خرابی سایت یا کاهش عملکرد را به دلیل در دسترس نبودن یک منبع حیاتی برای سایت به دلیل خطای یک سرویس شخص ثالث کاهش می دهد.
• قبل از اینکه منابع شخص ثالث را در CDN ذخیره کنید، مطمئن شوید که از نوعی سیستم نسخه‌سازی هنگام نام‌گذاری فایل‌های آن‌ها استفاده می‌شود، یا اینکه می‌توانید چرخه عمر این منابع را با تنظیم مجدد دستی یا خودکار حافظه پنهان CDN هنگام انتشار نسخه جدید مدیریت کنید. فیلمنامه
• در مورد CDN، سرور پروکسی و تنظیمات کش بسیار مراقب باشید. این به شما امکان می دهد از ارسال کوکی های پروژه یا هدر خود جلوگیری کنید Client-Hints خدمات شخص ثالث

خوانندگان عزیز! آیا مطالب دیگران را روی سرورهای خود میزبانی می کنید که برای عملکرد پروژه های شما بسیار مهم هستند؟

منبع: www.habr.com