معرفی NoState Prefetch

Katie Hempenius

منتشر شده: ۲۰ ژوئیه ۲۰۱۸

مقدمه

NoState Prefetch یک مکانیزم جدید در کروم است که جایگزینی برای فرآیند منسوخ‌شده‌ی پیش‌رندرینگ محسوب می‌شود و برای راه‌اندازی ویژگی‌هایی مانند <link rel="prerender"> استفاده می‌شود. مانند پیش‌رندرینگ، این مکانیزم منابع را از قبل دریافت می‌کند؛ اما برخلاف پیش‌رندرینگ، جاوا اسکریپت را اجرا نمی‌کند یا هیچ بخشی از صفحه را از قبل رندر نمی‌کند. هدف NoState Prefetch استفاده از حافظه‌ی کمتر نسبت به پیش‌رندرینگ است، در حالی که همچنان زمان بارگذاری صفحه را کاهش می‌دهد.

NoState Prefetch یک API نیست، بلکه مکانیزمی است که توسط کروم برای پیاده‌سازی APIها و ویژگی‌های مختلف استفاده می‌شود. API مربوط به Resource Hints و همچنین پیش‌واکشی صفحات توسط نوار آدرس کروم، هر دو با استفاده از NoState Prefetch پیاده‌سازی شده‌اند. اگر از کروم ۶۳ یا بالاتر استفاده می‌کنید، مرورگر شما از قبل از NoState Prefetch برای ویژگی‌هایی مانند <link rel="prerender"> استفاده می‌کند.

این مقاله نحوه‌ی کار NoStatePrefetch، انگیزه‌های معرفی آن و دستورالعمل‌های استفاده از هیستوگرام‌های کروم برای مشاهده‌ی آمار مربوط به استفاده از آن را توضیح می‌دهد.

انگیزه

دو انگیزه اصلی برای معرفی NoState Prefetch وجود داشت:

کاهش استفاده از حافظه

NoState Prefetch فقط حدود ۴۵ مگابایت از حافظه را استفاده می‌کند. نگهداری اسکنر preload، هزینه اصلی حافظه برای NoState Prefetch است و این هزینه در موارد استفاده مختلف نسبتاً ثابت می‌ماند. افزایش اندازه یا حجم واکشی‌ها تأثیر قابل توجهی بر میزان حافظه مصرف شده توسط NoState Prefetch ندارد.

در مقابل، پیش‌رندرینگ معمولاً ۱۰۰ مگابایت حافظه مصرف می‌کند و مصرف حافظه به ۱۵۰ مگابایت محدود شده است. این مصرف بالای حافظه، آن را برای دستگاه‌های ضعیف (یعنی کمتر از ۵۱۲ مگابایت رم) نامناسب می‌کند. در نتیجه، کروم پیش‌رندرینگ را روی دستگاه‌های ضعیف انجام نمی‌دهد و در عوض از قبل به اینترنت متصل می‌شود.

تسهیل پشتیبانی از ویژگی‌های جدید پلتفرم وب

با پیش‌رندرینگ، هیچ اقدام کاربر-محور (مثلاً پخش موسیقی یا ویدیو) یا وضعیت-محور (مثلاً تغییر جلسه یا ذخیره‌سازی محلی) نباید رخ دهد. با این حال، جلوگیری از وقوع این اقدامات هنگام رندر کردن یک صفحه می‌تواند دشوار و پیچیده باشد. NoState Prefetch فقط منابع را از قبل دریافت می‌کند: کدی را اجرا نمی‌کند یا صفحه را رندر نمی‌کند. این امر جلوگیری از وقوع اقدامات کاربر-محور و وضعیت-محور را ساده‌تر می‌کند.

پیاده‌سازی

مراحل زیر نحوه‌ی عملکرد NoState Prefetch را توضیح می‌دهد.

1. NoStatePrefetch فعال شده است.

   یک اشاره‌گر منبع پیش رندر (مثلاً <link rel="prerender"> ) و برخی از ویژگی‌های کروم، در صورتی که دو شرط زیر برقرار باشند، NoState Prefetch را فعال می‌کنند: الف) کاربر از دستگاه ضعیفی استفاده نکند، و ب) کاربر به شبکه تلفن همراه متصل نباشد.

2. یک رندرکننده‌ی جدید و اختصاصی برای NoState Prefetch ایجاد می‌شود.

   در کروم، « رندرکننده » فرآیندی است که مسئول دریافت یک سند HTML، تجزیه آن، ساخت درخت رندر آن و نمایش نتیجه روی صفحه است. هر تب در کروم، و همچنین هر فرآیند NoState Prefetch، رندرکننده مخصوص به خود را دارد تا ایزوله‌سازی را فراهم کند. این امر به حداقل رساندن اثرات بروز مشکل (مثلاً از کار افتادن یک تب) و همچنین جلوگیری از دسترسی کدهای مخرب به سایر تب‌ها یا سایر قسمت‌های سیستم کمک می‌کند.

3. منبعی که با NoState Prefetch بارگذاری می‌شود، واکشی می‌شود. سپس HTMLPreloadScanner این منبع را اسکن می‌کند تا زیرمنابعی را که نیاز به واکشی دارند، پیدا کند. اگر منبع اصلی یا هر یک از زیرمنابع آن دارای یک سرویس ورکر ثبت‌شده باشند، این درخواست‌ها از طریق سرویس ورکر مربوطه ارسال می‌شوند.

   NoState Prefetch فقط از روش GET HTTP پشتیبانی می‌کند؛ هیچ زیرمنبعی را که نیاز به استفاده از سایر روش‌های HTTP داشته باشد، دریافت نمی‌کند. علاوه بر این، هیچ منبعی را که نیاز به اقدامات کاربر (مانند پنجره‌های بازشو احراز هویت، گواهی کلاینت SSL یا لغو دستی) داشته باشد، دریافت نمی‌کند.

4. زیرمنابعی که واکشی می‌شوند با اولویت خالص «IDLE» واکشی خواهند شد.

   اولویت شبکه «IDLE» پایین‌ترین اولویت شبکه ممکن در کروم است.

5. تمام منابع بازیابی شده توسط NoState Prefetch مطابق با هدرهای کش خود ذخیره می‌شوند.

   NoState Prefetch تمام منابع را به جز آن‌هایی که هدر Cache-Control no-store دارند، ذخیره می‌کند. اگر هدر پاسخ Vary ، هدر Cache-Control no-cache وجود داشته باشد، یا اگر منبع بیش از ۵ دقیقه قدمت داشته باشد، منبع قبل از استفاده مجدداً اعتبارسنجی می‌شود.

6. رندرکننده پس از بارگذاری تمام زیرمنابع از بین می‌رود.

   اگر زمان انقضای زیرمنابع تمام شود، رندرکننده پس از 30 ثانیه از بین می‌رود.

7. مرورگر به جز به‌روزرسانی محل ذخیره‌سازی کوکی‌ها و حافظه پنهان DNS محلی، هیچ تغییر وضعیتی ایجاد نمی‌کند. مهم است که این مورد را بررسی کنید زیرا این همان «NoState» در «NoState Prefetch» ​​است.

   در این مرحله از فرآیند بارگذاری «عادی» صفحه، مرورگر احتمالاً کارهایی انجام می‌دهد که وضعیت مرورگر را تغییر می‌دهد: برای مثال، اجرای جاوا اسکریپت، تغییر sessionStorage یا localStorage ، پخش موسیقی یا ویدیو، استفاده از History API یا درخواست از کاربر. تنها تغییراتی که در NoState Prefetch رخ می‌دهد، به‌روزرسانی حافظه پنهان DNS هنگام رسیدن پاسخ‌ها و به‌روزرسانی محل ذخیره‌سازی کوکی در صورتی است که پاسخی حاوی سرآیند Set-Cookie باشد.

8. وقتی منبع مورد نیاز باشد، در پنجره مرورگر بارگذاری می‌شود.

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

   اگر صفحه دارای سرویس ورکر باشد، این بارگذاری صفحه دوباره از طریق سرویس ورکر انجام می‌شود.

   اگر NoState Prefetch تا زمان نیاز به صفحه، دریافت زیرمنابع را تمام نکرده باشد، مرورگر فرآیند بارگذاری صفحه را از جایی که NoState Prefetch متوقف شده بود، ادامه خواهد داد. مرورگر همچنان نیاز به دریافت منابع دارد، اما نه به اندازه‌ای که اگر NoState Prefetch آغاز نشده بود، لازم بود.

تأثیر بر تجزیه و تحلیل وب

صفحاتی که با استفاده از NoState Prefetch بارگذاری می‌شوند، بسته به اینکه ابزار داده‌ها را در سمت کلاینت یا سرور جمع‌آوری می‌کند، در زمان‌های کمی متفاوت توسط ابزارهای تحلیل وب ثبت می‌شوند.

اسکریپت‌های تحلیلی سمت کلاینت، زمانی که صفحه به کاربر نشان داده می‌شود، یک بازدید از صفحه را ثبت می‌کنند. این اسکریپت‌ها به اجرای جاوا اسکریپت متکی هستند و NoState Prefetch هیچ جاوا اسکریپتی را اجرا نمی‌کند.

ابزارهای تحلیلی سمت سرور، هنگام پردازش یک درخواست، معیارهایی را ثبت می‌کنند. برای منابعی که از طریق NoState Prefetch بارگذاری می‌شوند، ممکن است فاصله زمانی قابل توجهی بین زمان پردازش یک درخواست و زمان استفاده واقعی پاسخ توسط کلاینت (اگر اصلاً استفاده شود) وجود داشته باشد. از کروم ۶۹ به بعد، NoState Prefetch هدر Purpose: Prefetch را به همه درخواست‌ها اضافه می‌کند تا آنها را از مرور عادی متمایز کند.

بررسیش کن.

NoStatePrefetch در دسامبر ۲۰۱۷ در کروم ۶۳ عرضه شد. در حال حاضر برای موارد زیر استفاده می‌شود:

• پیاده‌سازی راهنمای منابع prerender
• اولین نتیجه را در نتایج جستجوی گوگل دریافت کنید
• صفحاتی را که نوار آدرس کروم پیش‌بینی می‌کند احتمالاً در مرحله بعد بازدید خواهند شد، دریافت کنید

می‌توانید از Chrome Internals برای مشاهده‌ی نحوه‌ی استفاده از NoStatePrefetch استفاده کنید.

برای مشاهده لیست سایت‌هایی که با NoState Prefetch بارگذاری شده‌اند، به chrome://net-internals/#prerender بروید.

برای مشاهده آمار استفاده از NoState Prefetch، به chrome://histograms بروید و عبارت "NoStatePrefetch" را جستجو کنید. سه هیستوگرام مختلف NoState Prefetch وجود دارد - یکی برای هر مورد استفاده از NoState Prefetch:

• «NoStatePrefetch» ​​(آمار مربوط به استفاده توسط پیش‌رندر، نکات مربوط به منابع)
• «gws_NoStatePrefetch» ​​(آمار مربوط به میزان استفاده توسط صفحه نتایج جستجوی گوگل)
• «omnibox_NoStatePrefetch» ​​(آمار مربوط به میزان استفاده توسط نوار آدرس کروم)