پیش‌پرداخت صفحه‌ها در Chrome برای پیمایش فوری صفحه

Barry Pollard

تاریخ انتشار: ۲ دسامبر ۲۰۲۲، آخرین به‌روزرسانی: ۲۹ اکتبر ۲۰۲۶

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

تیم Chrome پیش‌پرداخت کامل صفحه‌های آینده را که احتمالاً کاربر به آن‌ها پیمایش می‌کند، بازگردانده است.

تاریخچه مختصری از پیش‌پرداز

در گذشته، Chrome از راهنمای منبع <link rel="prerender" href="/next-page"> پشتیبانی می‌کرد، اما این راهنما به‌طور گسترده فراتر از Chrome پشتیبانی نمی‌شد و API چندان گویایی نبود.

این پیش‌پردازش قدیمی بااستفاده از اشاره پیوند rel=prerender به‌نفع واکشی اولیه NoState منسوخ شد که به‌جای آن منابع موردنیاز صفحه آینده را واکشی می‌کرد اما صفحه را به‌طور کامل پیش‌پردازش نمی‌کرد و جاوا اسکریپت را اجرا نمی‌کرد. «پیش‌واکشی NoState» با بهبود بارگیری منابع به بهبود عملکرد صفحه کمک می‌کند، اما بارگیری صفحه را به‌صورت فوری (مانند پیش‌پرداز کامل) ارائه نمی‌دهد.

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

صفحه چگونه پیش‌پردازش می‌شود؟

صفحه را می‌توان به یکی از چهار روش پیش‌پرداخت کرد که هدف همه آن‌ها سریع‌تر کردن پیمایش است:

  1. وقتی نشانی وبی را در نوار نشانی Chrome (که به آن «omnibox» هم می‌گویند) تایپ می‌کنید، اگر Chrome براساس سابقه مرور قبلی‌تان اطمینان زیادی داشته باشد که از آن صفحه بازدید خواهید کرد، ممکن است به‌طور خودکار آن صفحه را برای شما پیش‌پرداخت کند.
  2. وقتی از نوار نشانک‌ها استفاده می‌کنید، Chrome ممکن است وقتی نشانگر را روی یکی از دکمه‌های نشانک نگه می‌دارید، صفحه را به‌طور خودکار برای شما پیش‌پرداز کند.
  3. وقتی عبارت جستجویی را در نوار نشانی Chrome تایپ می‌کنید، Chrome ممکن است به‌طور خودکار صفحه نتایج جستجو را پیش‌پرداخت کند، البته اگر موتور جستجو چنین دستوری داده باشد.
  4. سایت‌ها می‌توانند از Speculation Rules API استفاده کنند تا به‌صورت برنامه‌نویسی‌شده به Chrome بگویند کدام صفحه‌ها را پیش‌پرداخت کند. این ویژگی جایگزین کاری می‌شود که <link rel="prerender"...> قبلاً انجام می‌داد و به سایت‌ها اجازه می‌دهد تا براساس قوانین فرضیه موجود در صفحه، پیش‌پرداززنی صفحه را به‌طور پیش‌کنشی انجام دهند. این موارد می‌توانند به‌صورت ایستا در صفحه‌ها وجود داشته باشند یا به‌صورت پویا توسط جاوا اسکریپت به‌نحوی که مالک صفحه مناسب می‌داند تزریق شوند.

در هریک از این موارد، پیش‌پردازنده طوری رفتار می‌کند که گویی صفحه در برگه پس‌زمینه نامرئی باز شده است و سپس با جایگزین کردن برگه پیش‌زمینه با آن صفحه پیش‌پردازشده «فعال» می‌شود. اگر صفحه‌ای قبل‌از اینکه کاملاً پیش‌پردازش شود فعال شود، وضعیت فعلی آن «پیش‌زمینه» است و به بار شدن ادامه می‌دهد، یعنی همچنان می‌توانید شروع خوبی داشته باشید.

ازآنجایی‌که صفحه پیش‌پردازش‌شده در حالت پنهان باز می‌شود، تعدادی از میاناهای برنامه‌سازی کاربردی که باعث رفتارهای مزاحم می‌شوند (برای مثال، پیام‌واره‌ها) در این حالت فعال نمی‌شوند و درعوض تا زمانی که صفحه فعال شود به‌تأخیر می‌افتند. در موارد معدودی که این کار هنوز امکان‌پذیر نیست، پیش‌پرداز لغو می‌شود. تیم Chrome درحال کار روی ارائه دلایل لغو پیش‌پرداز به‌عنوان یک API و همچنین بهبود قابلیت‌های DevTools است تا شناسایی چنین موارد حاشیه‌ای آسان‌تر شود.

تأثیر پیش‌پرداز کردن

پیش‌پرداز امکان بار کردن تقریباً فوری صفحه را فراهم می‌کند، همان‌طور که در ویدیو زیر نشان داده شده است:

نمونه تأثیر پیش‌پرداز

سایت نمونه ازقبل سایتی سریع است، اما حتی با این وجود می‌توانید ببینید که پیش‌پرداز زدن چگونه تجربه کاربری را بهبود می‌بخشد. بنابراین، این امر می‌تواند تأثیر مستقیمی بر هسته‌های حیاتی وب سایت داشته باشد، به‌طوری‌که «بزرگ‌ترین رنگ محتوایی» (LCP) نزدیک به صفر می‌شود، «تغییر چیدمان تجمعی» (CLS) کاهش می‌یابد (زیرا هرگونه CLS بارگیری قبل‌از نمای اولیه اتفاق می‌افتد)، و «تعامل با رنگ بعدی» (INP) بهبود می‌یابد (زیرا بارگیری باید قبل‌از تعامل کاربر تکمیل شود).

حتی وقتی صفحه‌ای قبل‌از بار شدن کامل فعال می‌شود، داشتن شروعی زودهنگام برای بار شدن صفحه باید تجربه بار کردن را بهبود بخشد. وقتی پیوندی درحین پیش‌پردازش فعال شود، صفحه پیش‌پردازش به قاب اصلی منتقل می‌شود و بار کردن را ادامه می‌دهد.

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

برای اطلاعات بیشتر درباره نحوه اندازه‌گیری تأثیر عملکرد واقعی در تجزیه‌وتحلیل، به بخش اندازه‌گیری عملکرد مراجعه کنید.

مشاهده پیش‌بینی‌های نوار نشانی Chrome

برای مورد استفاده اول، می‌توانید پیش‌بینی‌های Chrome را برای نشانی‌های وب در صفحه chrome://predictors مشاهده کنید:

صفحه «پیش‌بینی‌کننده‌های Chrome» فیلتر شده است تا پیش‌بینی‌های کم (خاکستری)، متوسط (کهربایی)، و زیاد (سبز) را براساس نوشتار واردشده نشان دهد.
صفحه پیش‌بینی‌کننده‌های Chrome.

خطوط سبز نشان‌دهنده اطمینان کافی برای راه‌اندازی پیش‌پرداز است. در این مثال، تایپ کردن «s» اطمینان معقولی (کهربایی) می‌دهد، اما وقتی «sh» را تایپ می‌کنید، Chrome اطمینان کافی دارد که تقریباً همیشه به https://sheets.google.com پیمایش می‌کنید.

این نماگرفت در نصب نسبتاً جدید Chrome گرفته شده است و پیش‌بینی‌های با اطمینان صفر را فیلتر می‌کند، اما اگر پیش‌بینی‌کننده‌های خودتان را مشاهده کنید، احتمالاً ورودی‌های بسیار بیشتری خواهید دید و احتمالاً نویسه‌های بیشتری برای رسیدن به سطح اطمینان کافی لازم است.

این پیش‌بینی‌کننده‌ها همچنین گزینه‌های پیشنهادی نوار نشانی را که ممکن است متوجه شده باشید هدایت می‌کنند:

ویژگی «تکمیل خودکار» نوار نشانی Chrome
ویژگی «تایپ پیش‌نگر» نوار نشانی.

Chrome به‌طور مداوم پیش‌بینی‌کننده‌هایش را براساس تایپ و انتخاب‌های شما به‌روز می‌کند.

  • برای سطح اطمینان بیشتر از ۳۰٪ (به رنگ کهربایی نشان داده می‌شود)، Chrome به‌طور پیش‌کنشی به دامنه پیش‌متصل می‌شود، اما صفحه را پیش‌پرداخت نمی‌کند.
  • برای سطح اطمینان بیشتر از ۵۰٪ (به رنگ سبز نشان داده می‌شود)، Chrome نشانی وب را پیش‌پرداز می‌کند.

Speculation Rules API

برای گزینه پیش‌پرداز Speculation Rules API، توسعه‌دهندگان وب می‌توانند دستورالعمل‌های JSON را در صفحه‌هایشان درج کنند تا به مرورگر اطلاع دهند کدام نشانی‌های وب را پیش‌پرداز کند.

فهرست‌های نشانی وب

قوانین گمانه‌زنی می‌تواند براساس فهرست نشانی‌های وب باشد:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

قوانین سند

قوانین گمانه‌زنی همچنین می‌توانند «قوانین سند» باشند که از نحو where استفاده می‌کنند. این گزینه پیوندهای یافت‌شده در سند را براساس گزینشگرهای href (براساس URL Pattern API) یا گزینشگرهای CSS حدس می‌زند:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

اشتیاق

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

از تنظیم eagerness برای نشان دادن زمان فعال شدن گمانه‌زنی‌ها استفاده می‌شود که به‌ویژه برای قوانین سند مفید است:

  • ‫conservative: این مورد روی اشاره‌گر یا لمس کردن حدس می‌زند.
  • moderate: در رایانه، اگر اشاره‌گر را به‌مدت ۲۰۰ میلی‌ثانیه روی پیوندی نگه دارید، این گزینه گمانه‌زنی‌ها را اجرا می‌کند (یا در رویداد pointerdown اگر زودتر باشد، و در تلفن همراه که رویداد hover وجود ندارد). در تلفن همراه، از اوت ۲۰۲۵ این مورد را براساس اکتشافات پیچیده نمای هدف تغییر دادیم. اکتشافی‌های پیچیده نمای هدف ۵۰۰ میلی‌ثانیه پس‌از توقف پیمایش کاربر، برای لنگرهایی که در فاصله عمودی ۳۰٪ از اشاره‌گر قبلی قرار دارند، فعال می‌شوند، جایی که لنگرها حداقل ۰٫۵ برابر بزرگ‌تر از بزرگ‌ترین لنگر در نمای هدف هستند. همان‌طور که در این سند شرح داده شده است.
  • eager: این اشتیاق قبلاً رفتاری مشابه immediate داشت اما از Chrome 143 تغییر کرد. در رایانه، اگر اشاره‌گر را به‌مدت ۱۰ میلی‌ثانیه روی پیوندی نگه دارید، این گزینه گمانه‌زنی‌ها را اجرا می‌کند. در تلفن همراه، از ژانویه ۲۰۲۶ این مورد را براساس اکتشافات ساده نمای هدف تغییر دادیم. اکتشافی‌های ساده ناحیه نمایش ۵۰ میلی‌ثانیه پس‌از ورود لنگر به ناحیه نمایش فعال می‌شوند.
  • immediate: این برای گمانه‌زنی در اسرع وقت استفاده می‌شود، یعنی به‌محض مشاهده قوانین گمانه‌زنی.

eagerness پیش‌فرض برای قوانین list، immediate است. از گزینه‌های eager، moderate، و conservative می‌توان برای محدود کردن قوانین list به نشانی‌های وبی که کاربر با آن‌ها تعامل دارد به فهرستی خاص استفاده کرد. اگرچه در بسیاری‌از موارد، document قانون با شرط where مناسب ممکن است مناسب‌تر باشد.

eagerness پیش‌فرض برای قوانین document، conservative است. با توجه به اینکه یک سند می‌تواند از نشانی‌های وب زیادی تشکیل شده باشد، استفاده از immediate برای قوانین document باید با احتیاط انجام شود (همچنین بخش محدودیت‌های Chrome را در ادامه ببینید).

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

گزینه moderate حد وسط است و بسیاری از سایت‌ها می‌توانند از قانون گمانه‌زنی زیر بهره‌مند شوند که پیوندی را پیش‌پرداخت می‌کند وقتی اشاره‌گر را به‌مدت ۲۰۰ میلی‌ثانیه روی پیوند نگه می‌دارید یا در رویداد pointerdown به‌عنوان یک پیاده‌سازی پایه—اما قدرتمند—از قوانین گمانه‌زنی:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

واکشی اولیه

از قوانین فرضیه می‌توان فقط برای واکشی اولیه صفحه‌ها بدون پیش‌پرداززنی کامل نیز استفاده کرد. این کار اغلب می‌تواند اولین گام خوب در مسیر پیش‌پرداز کردن باشد:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

تیم Chrome همچنین درحال کار روی افزودن prerender_until_script به Speculation Rules API است (به اشکال پیاده‌سازی مراجعه کنید). این مرحله‌ای بین واکشی اولیه و پیش‌پرداز خواهد بود و به روشی مشابه استفاده می‌شود:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

مشابه NoState prefetch، این کار هم سند HTML و هم منابع فرعی موجود در آن HTML را پیش‌واکشی می‌کند. اما این ویژگی فراتر از این می‌رود و پیش‌پردازش صفحه را نیز شروع می‌کند و وقتی به اولین اسکریپت می‌رسد متوقف می‌شود.

این یعنی برای صفحه‌هایی که جاوا اسکریپت ندارند، یا فقط در پاصفحه جاوا اسکریپت دارند، صفحه می‌تواند تقریباً به‌طور کامل ازقبل پیش‌پردازش شود. صفحه‌هایی که در <head> اسکریپت دارند نمی‌توانند پیش‌پرداز شوند اما همچنان از واکشی زیرمنبع بهره‌مند می‌شوند.

این کار از خطرات عوارض جانبی ناخواسته ناشی از اجرای جاوا اسکریپت جلوگیری می‌کند، اما امکان افزایش عملکرد بسیار بیشتری را نسبت‌به prefetch فراهم می‌کند.

محدودیت‌های Chrome

‫Chrome محدودیت‌هایی برای جلوگیری از استفاده بیش‌ازحد از Speculation Rules API دارد:

اشتیاق واکشی اولیه پیش‌پرداززنی
immediate 50 10
‫eager / moderate در تلفن همراه 6 (FIFO) ‫۲ (خروج به‌ترتیب ورود)
‫eager / moderate در رایانه ‫۲ (خروج به‌ترتیب ورود) ‫۲ (خروج به‌ترتیب ورود)
conservative ‫۲ (خروج به‌ترتیب ورود) ‫۲ (خروج به‌ترتیب ورود)
محدودیت‌های گمانه‌زنی در Chrome.

تنظیمات eager، moderate، و conservative (که به تعامل کاربر بستگی دارند) به‌صورت خروج به‌ترتیب ورود (FIFO) کار می‌کنند: پس‌از رسیدن به حد، گمانه‌زنی جدید باعث می‌شود قدیمی‌ترین گمانه‌زنی لغو شود و گمانه‌زنی جدیدتر جایگزین آن شود تا حافظه حفظ شود.

پیش‌بینی لغوشده را می‌توان دوباره راه‌اندازی کرد—برای مثال با نگه داشتن مجدد نشانگر روی آن پیوند—که منجر به پیش‌بینی مجدد آن نشانی وب می‌شود و قدیمی‌ترین پیش‌بینی را از فهرست خارج می‌کند. در این حالت، فرضیه قبلی هر منبع قابل ذخیره در حافظه نهان را در «حافظه نهان HTTP» برای آن نشانی وب ذخیره کرده است، بنابراین فرضیه‌سازی مجدد باید هزینه کمتری داشته باشد. به همین دلیل است که این محدودیت به‌طور پیش‌فرض روی آستانه متوسط ۲ تنظیم شده است. ما از آستانه بالاتر ۶ برای پیش‌واکشی در تلفن همراه استفاده می‌کنیم زیرا «نگه داشتن نشانگر» وجود ندارد، اکتشافات جایگزین نمای تلفن همراه دقت کمتری دارند، و پیش‌واکشی هزینه کمتری نسبت‌به پیش‌پرداز دارد (ما حد ۲ را برای پیش‌پرداز در تلفن همراه حفظ می‌کنیم).

قوانین فهرست ایستا با کنش کاربر فعال نمی‌شوند و بنابراین حد بالاتری دارند زیرا برای مرورگر ممکن نیست بداند کدام‌یک موردنیاز است و چه زمانی موردنیاز است.

Chrome همچنین درنظر دارد این محدودیت را در تلفن همراه برای eager و moderate حداقل برای پیش‌واکشی به ۵ افزایش دهد، زیرا این روش اکتشافی دقت کمتری دارد. توسعه‌دهندگانی که از eager استفاده می‌کنند ممکن است بخواهند از قوانین conservative نیز استفاده کنند تا وقتی چند پیوند در نمای هدف دردسترس است، حتی اگر به‌عنوان یکی از دو پیوند اول انتخاب نشده باشند، همچنان گمانه‌زنی کنند.

حد immediate نیز پویا است، بنابراین برداشتن عنصر اسکریپت نشانی وب list با لغو آن گمانه‌زنی‌های برداشته‌شده، ظرفیت ایجاد می‌کند.

همچنین Chrome در شرایط خاصی از استفاده از گمانه‌زنی‌ها جلوگیری می‌کند، ازجمله:

  • Save-Data.
  • بهینه‌سازی انرژی وقتی فعال باشد و شارژ باتری کم باشد.
  • محدودیت‌های حافظه.
  • وقتی تنظیم «پیش‌بار کردن صفحه‌ها» خاموش باشد (که افزونه‌های Chrome مانند uBlock Origin نیز آن را به‌طور صریح خاموش می‌کنند).
  • صفحه‌ها در برگه‌های پس‌زمینه باز شد.

‫Chrome همچنین iframeهای میان‌مبدئی را در صفحه‌های پیش‌پردازش‌شده تا زمان فعال‌سازی پردازش نمی‌کند.

هدف همه این شرایط کاهش تأثیر گمانه‌زنی بیش‌ازحد در زمانی است که برای کاربران مضر باشد.

نحوه گنجاندن قوانین گمانه‌زنی در صفحه

قوانین گمانه‌زنی را می‌توان به‌صورت ایستا در HTML صفحه گنجاند یا به‌صورت پویا توسط جاوا اسکریپت در صفحه درج کرد:

  • قوانین گمانه‌زنی گنجانده‌شده به‌صورت ایستا: برای مثال، یک سایت رسانه خبری یا یک وبلاگ ممکن است جدیدترین مقاله را پیش‌پرداخت کند، اگر این مقاله اغلب ناوبری بعدی برای بخش بزرگی از کاربران باشد. همچنین، قوانین سند با moderate یا conservative می‌توانند برای گمانه‌زنی هنگام تعامل کاربران با پیوندها استفاده شوند.
  • قوانین گمانه‌زنی درج‌شده به‌صورت پویا: این می‌تواند براساس منطق برنامه، شخصی‌سازی‌شده برای کاربر، یا براساس سایر روش‌های اکتشافی باشد.

به کسانی که درج پویا را براساس کنش‌هایی مثل نگه داشتن نشانگر روی پیوند یا کلیک کردن روی آن ترجیح می‌دهند (همان‌طور که بسیاری‌از کتابخانه‌ها در گذشته با <link rel=prefetch> انجام داده‌اند) توصیه می‌شود به قوانین سند نگاهی بیندازند، زیرا این قوانین به مرورگر اجازه می‌دهند بسیاری‌از موارد استفاده شما را مدیریت کند.

قوانین گمانه‌زنی را می‌توان در <head> یا <body> در قاب اصلی اضافه کرد. قوانین فرضیه در زیرقاب‌ها اجرا نمی‌شوند و قوانین فرضیه در صفحه‌های پیش‌پردازش‌شده فقط زمانی اجرا می‌شوند که آن صفحه فعال شود.

سرایند HTTP Speculation-Rules

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

قوانین گمانه‌زنی را می‌توان بااستفاده از سرایند HTTP Speculation-Rules نیز ارائه کرد، به‌جای اینکه آن‌ها را مستقیماً در HTML سند گنجاند. این کار باعث می‌شود استقرار توسط CDNها آسان‌تر شود و نیازی به تغییر محتوای سند نباشد.

سرایند HTTP Speculation-Rules با سند برگردانده می‌شود و به مکان فایل JSON حاوی قوانین گمانه‌زنی اشاره می‌کند:

Speculation-Rules: "/speculationrules.json"

این منبع باید از نوع MIME صحیح استفاده کند و اگر منبع میان‌مبدئی است، باید بررسی CORS را بگذراند.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

اگر می‌خواهید از نشانی‌های وب نسبی استفاده کنید، شاید بخواهید کلید "relative_to": "document" را در قوانین گمانه‌زنی‌تان اضافه کنید. درغیراین‌صورت، نشانی‌های وب نسبی نسبت به نشانی وب فایل JSON قوانین گمانه‌زنی نسبی خواهند بود. این ویژگی به‌ویژه زمانی مفید است که لازم باشد برخی یا همه پیوندهای هم‌مبدأ را انتخاب کنید.

فیلد برچسب قوانین گمانه‌زنی

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

همچنین می‌توان «برچسب‌ها» را در نحو JSON قوانین گمانه‌زنی در سطح کلی برای همه قوانین گمانه‌زنی در یک مجموعه قانون اضافه کرد:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

یا در سطح قانون فردی:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

سپس این برچسب در سرایند HTTP Sec-Speculation-Tags منعکس می‌شود که می‌توان از آن برای فیلتر کردن قوانین گمانه‌زنی در سرور استفاده کرد. اگر گمانه‌زنی تحت پوشش چند قانون باشد، سرایند HTTP‏ Sec-Speculation-Tags می‌تواند شامل چند برچسب باشد، همان‌طور که در مثال زیر نشان داده شده است:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

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

برچسب‌های مجموعه قوانین نیز در Chrome DevTools نمایش داده می‌شوند.

فیلد قوانین گمانه‌زنی target_hint

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

قوانین گمانه‌زنی همچنین می‌توانند شامل فیلد target_hint باشند که حاوی نام یا کلیدواژه معتبر بافت مرور است که نشان می‌دهد صفحه انتظار دارد محتوای پیش‌پرداخت‌شده در کجا فعال شود:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

این راهنمایی اجازه می‌دهد گمانه‌زنی‌های پیش‌پرداز برای پیوندهای target="_blank" مدیریت شود:

<a target="_blank" href="next.html">Open this link in a new tab</a>

در‌حال‌حاضر فقط "target_hint": "_blank" و "target_hint": "_self" (پیش‌فرض درصورت مشخص نشدن) در Chrome پشتیبانی می‌شوند و فقط برای پیش‌پرداز—پیش‌واکشی پشتیبانی نمی‌شود.

target_hint فقط برای قوانین گمانه‌زنی urls لازم است، زیرا برای قوانین سند، target از خود پیوند مشخص است.

قوانین گمانه‌زنی و برنامه‌های تک‌صفحه‌ای

قوانین گمانه‌زنی فقط برای پیمایش‌های تمام‌صفحه که توسط مرورگر مدیریت می‌شوند پشتیبانی می‌شود و برای «برنامه‌های تک‌صفحه‌ای» (SPA) یا صفحه‌های پوسته برنامه پشتیبانی نمی‌شود. این معماری‌ها از واکشی سند استفاده نمی‌کنند، بلکه واکشی‌های جزئی یا میانای برنامه‌سازی کاربردی از داده‌ها یا صفحه‌ها انجام می‌دهند که سپس در صفحه فعلی پردازش و ارائه می‌شوند. داده‌های موردنیاز برای این به‌اصطلاح «پیمایش‌های نرم» را می‌توان توسط برنامه خارج از قوانین گمانه‌زنی پیش‌واکشی کرد، اما نمی‌توان آن‌ها را پیش‌پرداخت کرد.

از «قوانین گمانه‌زنی» می‌توان برای پیش‌پرداززنی خود برنامه از صفحه قبلی استفاده کرد. این کار می‌تواند به جبران برخی‌از هزینه‌های بار اولیه اضافی که برخی‌از برنامه‌های تک‌صفحه‌ای دارند کمک کند. اما تغییرات مسیر در برنامه را نمی‌توان پیش‌پرداخت کرد.

اشکال‌زدایی قوانین گمانه‌زنی

برای آشنایی با ویژگی‌های جدید Chrome DevTools که به مشاهده و اشکال‌زدایی این API جدید کمک می‌کنند، پست اختصاصی درباره اشکال‌زدایی قوانین گمانه‌زنی را ببینید.

قوانین گمانه‌زنی چندگانه

همچنین می‌توان چند قانون گمانه‌زنی را به یک صفحه اضافه کرد و آن‌ها به قوانین موجود اضافه می‌شوند. بنابراین، روش‌های مختلف زیر همگی منجر به پیش‌پرداخت one.html و two.html می‌شوند:

فهرست نشانی‌های وب:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

چندین متن speculationrules:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

چند فهرست در یک مجموعه از speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

هنگام واکشی پیشاپیش یا پیش‌پرداز کردن صفحه، ممکن است برخی پارامترهای نشانی وب (که ازنظر فنی به‌عنوان پارامترهای جستجو شناخته می‌شوند) برای صفحه‌ای که واقعاً توسط سرور ارائه می‌شود بی‌اهمیت باشند و فقط توسط جاوا اسکریپت سمت کارخواه استفاده شوند.

برای مثال، Google Analytics از پارامترهای UTM برای سنجش پویش استفاده می‌کند، اما معمولاً این پارامترها باعث نمی‌شوند صفحه‌های متفاوتی از سرور ارائه شود. این یعنی page1.html?utm_content=123 و page1.html?utm_content=456 صفحه یکسانی را از سرور ارائه خواهند داد، بنابراین می‌توان از همان صفحه در حافظه پنهان مجدداً استفاده کرد.

به‌طور مشابه، برنامه‌ها ممکن است از پارامترهای نشانی وب دیگری استفاده کنند که فقط در سمت کارخواه مدیریت می‌شوند.

پیشنهاد No-Vary-Search به سرور اجازه می‌دهد پارامترهایی را مشخص کند که منجر به تفاوت در منبع ارائه‌شده نمی‌شوند، و بنابراین به مرورگر اجازه می‌دهد از نسخه‌های قبلی ذخیره‌شده در حافظه نهان سند که فقط در این پارامترها متفاوت هستند، دوباره استفاده کند. این ویژگی در Chrome (و مرورگرهای مبتنی بر Chromium) برای گمانه‌زنی‌های پیمایش برای پیش‌واکشی و پیش‌پرداز پشتیبانی می‌شود.

قوانین گمانه‌زنی از استفاده از expects_no_vary_search برای نشان دادن جایی که انتظار می‌رود سرایند HTTP No-Vary-Search برگردانده شود پشتیبانی می‌کند. این کار می‌تواند به جلوگیری بیشتر از بارگیری‌های غیرضروری قبل‌از دیدن پاسخ‌ها کمک کند.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

در این مثال، HTML صفحه اولیه /products برای هر دو شناسه محصول 123 و 124 یکسان است. بااین‌حال، محتوای صفحه درنهایت براساس ارائه سمت کارخواه بااستفاده از جاوا اسکریپت برای واکشی داده‌های محصول بااستفاده از پارامتر جستجوی id متفاوت است. بنابراین آن نشانی وب را با اشتیاق پیش‌واکشی می‌کنیم و باید سرایند HTTP No-Vary-Search را برگرداند که نشان می‌دهد صفحه می‌تواند برای هر پارامتر جستجوی id استفاده شود.

بااین‌حال، اگر کاربر قبل‌از تکمیل واکشی اولیه روی هرکدام از پیوندها کلیک کند، ممکن است مرورگر صفحه /products را دریافت نکرده باشد. در این مورد، مرورگر نمی‌داند که آیا حاوی سرایند HTTP No-Vary-Search خواهد بود یا نه. سپس مرورگر می‌تواند انتخاب کند که پیوند را دوباره واکشی کند یا منتظر بماند تا پیش‌واکشی تکمیل شود تا ببیند آیا حاوی سرایند HTTP No-Vary-Search است یا نه. تنظیم expects_no_vary_search به مرورگر اجازه می‌دهد بداند که انتظار می‌رود پاسخ صفحه حاوی سرایند HTTP No-Vary-Search باشد و منتظر بماند تا واکشی اولیه تکمیل شود.

همچنین می‌توانید چند پارامتر را با فاصله جداکننده به expects_no_vary_search اضافه کنید (چون No-Vary-Search یک سرصفحه ساختاریافته HTTP است):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

محدودیت‌های قوانین گمانه‌زنی و بهبودهای آینده

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

به‌طور پیش‌فرض، پیش‌پردازها به صفحه‌های با مبدأ یکسان محدود می‌شوند. پیش‌پرداززنی صفحه‌های بین‌مبدأیی همان سایت (برای مثال، https://a.example.com می‌تواند صفحه‌ای را در https://b.example.com پیش‌پرداز کند) قابل‌فعال‌سازی است. برای استفاده از این، صفحه حدس‌زده‌شده (https://b.example.com در این مثال) باید با گنجاندن سرایند HTTP Supports-Loading-Mode: credentialed-prerender موافقت کند، درغیراین‌صورت Chrome حدس را لغو خواهد کرد.

نسخه‌های آینده ممکن است پیش‌پرداز را برای صفحه‌های بین‌مبدأیی غیرهم‌سایت نیز مجاز کنند، به‌شرطی که کوکی‌ها برای صفحه پیش‌پردازشده وجود نداشته باشند و صفحه پیش‌پردازشده با سرایند HTTP مشابه Supports-Loading-Mode: uncredentialed-prerender موافقت کند.

قوانین فرضیه درحال‌حاضر از واکشی‌های اولیه میان‌مبدئی پشتیبانی می‌کنند. برای واکشی‌های اولیه میان‌مبدئی همان سایت، هیچ محدودیتی وجود ندارد. پیش‌واکشی‌های میان‌مبدئی از سایت‌های متفاوت فقط زمانی پشتیبانی می‌شوند که کوکی‌های دامنه میان‌مبدئی وجود نداشته باشند. اگر کوکی‌های مربوط به بازدید قبلی کاربر از آن سایت وجود داشته باشد، از گمانه‌زنی استفاده نخواهد شد و در DevTools خطا نشان داده می‌شود.

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

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }],
    "prefetch": [{
      "where": { "not": { "href_matches": "/*" } },
      "eagerness": "moderate"
    }]
  }
</script>

محدودیت برای جلوگیری از گمانه‌زنی‌های میان‌مبدئی برای پیوندهای میان‌مبدئی به‌طور پیش‌فرض برای امنیت ضروری است. این ویژگی نسبت‌به <link rel="prefetch"> برای مقصدهای میان‌مبدئی بهبود یافته است، زیرا کوکی‌ها را ارسال نمی‌کند اما همچنان پیش‌واکشی را امتحان می‌کند—که یا منجر به پیش‌واکشی هدررفته‌ای می‌شود که باید دوباره ارسال شود یا، بدتر از آن، بارگیری صفحه نادرست.

شناسایی پشتیبانی Speculation Rules API

می‌توانید با بررسی‌های HTML استاندارد، پشتیبانی Speculation Rules API را شناسایی کنید:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

افزودن پویای قوانین گمانه‌زنی ازطریق جاوا اسکریپت

این نمونه‌ای از افزودن قانون گمانه‌زنی prerender با جاوا اسکریپت است:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

می‌توانید پیش‌پرداززنی Speculation Rules API را بااستفاده از درج جاوا اسکریپت در این صفحه نمایشی پیش‌پرداززنی مشاهده کنید.

درج عنصر <script type = "speculationrules"> مستقیماً در DOM بااستفاده از innerHTML، قوانین گمانه‌زنی را به‌دلایل امنیتی ثبت نمی‌کند و این باید همان‌طور که قبلاً نشان داده شده است اضافه شود. بااین‌حال، محتوایی که به‌طور پویا بااستفاده از innerHTML درج شده است و حاوی پیوندهای جدید است، توسط قوانین موجود در صفحه انتخاب خواهد شد.

به‌طور مشابه، ویرایش مستقیم پانل عناصر در Chrome DevTools برای افزودن عنصر <script type = "speculationrules">، قوانین گمانه‌زنی را ثبت نمی‌کند و درعوض، برای درج قوانین، باید اسکریپت افزودن پویا به DOM از «کنسول» اجرا شود.

افزودن قوانین فرضیه ازطریق مدیر برچسب

برای افزودن قوانین گمانه‌زنی بااستفاده از مدیر برچسبی مانند «مدیر برچسب Google» (GTM)، این قوانین باید ازطریق JavaScript درج شوند، نه اینکه عنصر <script type = "speculationrules"> مستقیماً ازطریق GTM اضافه شود، به همان دلایلی که قبلاً ذکر شد:

پیکربندی تگ HTML سفارشی در Google Tag Manager
افزودن «قوانین گمانه‌زنی» ازطریق Google Tag Manager.

توجه داشته باشید که این مثال از var استفاده می‌کند زیرا GTM از const پشتیبانی نمی‌کند.

لغو کردن قوانین گمانه‌زنی

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

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

همچنین می‌توان گمانه‌زنی‌ها را بااستفاده از سرایند HTTP Clear-Site-Data با دستورالعمل‌های prefetchCache و prerenderCache لغو کرد.

این کار زمانی مفید است که وضعیت در سرور تغییر کرده باشد. برای مثال، هنگام فراخوانی میانای برنامه‌سازی کاربردی «افزودن به سبد خرید» یا میانای برنامه‌سازی کاربردی ورود به سیستم یا خروج از سیستم.

در حالت ایده‌آل، این به‌روزرسانی‌های وضعیت باید بااستفاده از میاناهای برنامه‌سازی کاربردی مانند میانای برنامه‌سازی کاربردی Broadcast Channel به صفحه‌های پیش‌پردازش‌شده منتقل شوند، اما در مواردی که این کار امکان‌پذیر نیست یا تا زمانی که چنین منطقی پیاده‌سازی شود، لغو گمانه‌زنی می‌تواند آسان‌تر باشد.

قوانین گمانه‌زنی و خط‌مشی امنیتی محتوا

ازآنجایی‌که قوانین گمانه‌زنی از عنصر <script> استفاده می‌کنند، حتی اگر فقط حاوی JSON باشند، اگر سایت از script-src Content-Security-Policy استفاده کند، باید در آن گنجانده شوند—چه بااستفاده از درهم‌ساز یا عدد یک‌بارمصرف.

inline-speculation-rules جدیدی می‌تواند به script-src اضافه شود تا عناصر <script type="speculationrules"> تزریق‌شده از اسکریپت‌های درهم‌سازی‌شده یا دارای عدد یک‌بارمصرف پشتیبانی شوند. این ویژگی از قوانینی که در HTML اولیه گنجانده شده است پشتیبانی نمی‌کند، بنابراین قوانین باید توسط JavaScript برای سایت‌هایی که از CSP سخت‌گیرانه استفاده می‌کنند تزریق شوند.

شناسایی و غیرفعال کردن پیش‌پرداز

پیش‌پرداز معمولاً تجربه مثبتی برای کاربران است زیرا امکان پرداز سریع صفحه را فراهم می‌کند (اغلب به‌صورت فوری). این کار هم برای کاربر و هم برای مالک سایت مفید است، زیرا صفحه‌های پیش‌پردازش‌شده تجربه کاربری بهتری را ارائه می‌دهند که ممکن است دستیابی به آن از راه‌های دیگر دشوار باشد.

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

فعال و غیرفعال کردن پیش‌پرداز در Chrome

پیش‌پرداز فقط برای آن دسته از کاربران Chrome فعال است که تنظیم «پیش‌بارگذاری صفحه‌ها» را در chrome://settings/performance/ دارند. علاوه‌براین، پیش‌پرداخت در دستگاه‌های با حافظه کم یا اگر سیستم‌عامل در حالت «صرفه‌جویی داده» یا «بهینه‌سازی انرژی» باشد نیز غیرفعال می‌شود. بخش محدودیت‌های Chrome را ببینید.

شناسایی و غیرفعال کردن پیش‌پرداز در سمت سرور

صفحه‌های پیش‌پردازش‌شده با سرایند HTTP Sec-Purpose ارسال خواهند شد:

Sec-Purpose: prefetch;prerender

صفحه‌های واکشی اولیه بااستفاده از Speculation Rules API این سرصفحه را فقط روی prefetch تنظیم خواهند کرد:

Sec-Purpose: prefetch

سرورها می‌توانند براساس این سرصفحه پاسخ دهند تا درخواست‌های گمانه‌زنی را ثبت کنند، محتوای متفاوتی را برگردانند، یا از پیش‌پرداز شدن جلوگیری کنند. اگر کد پاسخ نهایی غیرموفقیت‌آمیز برگردانده شود (یعنی بعداز هدایت‌های مجدد در محدوده ۲۰۰-۲۹۹ نباشد)، صفحه پیش‌پردازش نخواهد شد و هر صفحه پیش‌واکشی‌شده‌ای دور انداخته خواهد شد. همچنین توجه داشته باشید که پاسخ‌های ۲۰۴ و ۲۰۵ برای پیش‌پرداخت معتبر نیستند، اما برای واکشی اولیه معتبر هستند.

اگر نمی‌خواهید صفحه خاصی پیش‌پرداز شود، برگرداندن کد پاسخ غیر 2XX (مثل 503) بهترین راه برای اطمینان از عدم وقوع آن است. بااین‌حال، برای ارائه بهترین تجربه، توصیه می‌شود به‌جای آن پیش‌پرداز را مجاز کنید، اما هر کنشی را که فقط باید هنگام مشاهده واقعی صفحه اتفاق بیفتد بااستفاده از جاوا اسکریپت به‌تأخیر بیندازید.

تشخیص پیش‌پرداخت در جاوا اسکریپت

وقتی صفحه درحال پیش‌پردازش است، میانای برنامه‌سازی کاربردی document.prerendering مقدار true را برمی‌گرداند. صفحه‌ها می‌توانند از این ویژگی برای جلوگیری از فعالیت‌های خاص درطول پیش‌پرداز یا به‌تأخیر انداختن آن‌ها تا زمان فعال شدن واقعی صفحه استفاده کنند.

پس‌از فعال شدن سند پیش‌پردازش‌شده، activationStart مربوط به PerformanceNavigationTiming نیز روی زمان غیرصفر تنظیم می‌شود که نشان‌دهنده زمان بین شروع پیش‌پردازش و فعال شدن واقعی سند است.

می‌توانید تابعی برای بررسی صفحه‌های پیش‌پردازش و پیش‌پردازش‌شده داشته باشید، مانند:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

ساده‌ترین راه برای اینکه ببینید صفحه‌ای پیش‌پرداز شده است (به‌طور کامل یا جزئی) این است که DevTools را پس‌از فعال شدن صفحه باز کنید و performance.getEntriesByType('navigation')[0].activationStart را در کنسول تایپ کنید. اگر مقدار غیرصفر برگردانده شود، متوجه می‌شوید که صفحه پیش‌پردازش شده است:

کنسول در Chrome DevTools که activationStart مثبت را نشان می‌دهد و نشان‌دهنده پیش‌پرداخت شدن صفحه است
درحال آزمایش پیش‌پرداز در کنسول.

وقتی صفحه توسط کاربری که صفحه را مشاهده می‌کند فعال می‌شود، رویداد prerenderingchange در document ارسال می‌شود که سپس می‌توان از آن برای فعال کردن فعالیت‌هایی استفاده کرد که قبلاً به‌طور پیش‌فرض در بارگیری صفحه شروع می‌شدند اما می‌خواهید تا زمانی که صفحه واقعاً توسط کاربر مشاهده شود به‌تأخیر بیفتند.

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

تأثیر بر Analytics

از Analytics برای سنجش استفاده از وب‌سایت استفاده می‌شود، برای مثال از Google Analytics برای سنجش بازدیدهای صفحه و رویدادها استفاده می‌شود. یا با اندازه‌گیری سنجه‌های عملکرد صفحه‌ها بااستفاده از پایش کاربر واقعی (RUM).

صفحات فقط زمانی باید پیش‌پرداخت شوند که احتمال بالایی وجود داشته باشد که صفحه توسط کاربر بارگذاری شود. به‌همین دلیل است که گزینه‌های پیش‌پرداخت نوار نشانی Chrome فقط زمانی اتفاق می‌افتد که احتمال بسیار بالایی وجود داشته باشد (بیشتر از ۸۰٪ مواقع).

بااین‌حال، به‌ویژه هنگام استفاده از Speculation Rules API، صفحه‌های پیش‌پرداخت‌شده ممکن است بر تجزیه‌وتحلیل تأثیر بگذارند و مالکان سایت ممکن است نیاز داشته باشند کد اضافی اضافه کنند تا تجزیه‌وتحلیل را فقط برای صفحه‌های پیش‌پرداخت‌شده در زمان فعال‌سازی فعال کنند، زیرا ممکن است همه ارائه‌دهندگان تجزیه‌وتحلیل این کار را به‌طور پیش‌فرض انجام ندهند.

این کار را می‌توان بااستفاده از Promise انجام داد که اگر سندی درحال پیش‌پرداخت باشد، منتظر رویداد prerenderingchange می‌ماند، یا اگر اکنون باشد، فوراً حل می‌شود:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

رویکرد جایگزین این است که فعالیت‌های تحلیلی را تا زمانی که صفحه برای اولین‌بار نمایان شود به‌تأخیر بیندازید، که هم مورد پیش‌پرداز را پوشش می‌دهد و هم زمانی که زبانه‌ها در پس‌زمینه باز می‌شوند (برای مثال، با کلیک راست و باز کردن در زبانه جدید):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

اگرچه این امر ممکن است برای تجزیه‌وتحلیل و موارد استفاده مشابه منطقی باشد، در موارد دیگر ممکن است بخواهید محتوای بیشتری برای آن موارد بار شود و بنابراین ممکن است بخواهید از document.prerendering و prerenderingchange برای هدف‌یابی خاص صفحه‌های پیش‌پرداز استفاده کنید.

نگه داشتن محتوای دیگر درطول پیش‌پرداز

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

برای مثال، این دستورگان را درنظر بگیرید:

<script src="https://example.com/app/script.js" async></script>

می‌توانید این را به عنصر دستورگان درج‌شده پویا تغییر دهید که فقط براساس تابع whenActivated قبلی درج می‌شود:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

درحالی‌که این امر شاید بااستفاده از پیش‌پرداز بیشتر اتفاق بیفتد، این شرایط برای صفحه‌های بارشده در برگه‌های پس‌زمینه که قبلاً ذکر شد نیز صادق است (بنابراین، تابع whenFirstVisible می‌تواند به‌جای whenActivated استفاده شود).

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

یکی از روش‌هایی که Chrome نیاز به پیچیدن دستی اسکریپت‌ها یا توابع را کاهش می‌دهد این است که همان‌طور که قبلاً ذکر شد، برخی‌از میاناهای برنامه‌سازی کاربردی نگه داشته می‌شوند و همچنین iframeهای شخص ثالث ارائه نمی‌شوند، بنابراین فقط محتوای بالای این است که باید به‌صورت دستی نگه داشته شود.

سنجش عملکرد

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

برای «هسته‌های حیاتی وب»، که توسط Chrome ازطریق گزارش تجربه کاربری Chrome اندازه‌گیری می‌شود، هدف اندازه‌گیری تجربه کاربری است. بنابراین این موارد براساس زمان فعال‌سازی اندازه‌گیری می‌شوند. این کار اغلب منجر به «بزرگ‌ترین رنگ محتوایی» ۰ ثانیه‌ای می‌شود، برای مثال، نشان دادن این روش عالی برای بهبود «شاخص‌های کلیدی عملکرد وب» شما است.

از نسخه ۳.۱.۰، کتابخانه web-vitals به‌روز شده است تا پیمایش‌های پیش‌پرداخت‌شده را به همان روشی که Chrome «شاخص‌های کلیدی عملکرد وب» را اندازه‌گیری می‌کند، مدیریت کند. این نسخه همچنین پیمایش‌های پیش‌پردازش‌شده را برای آن سنجه‌ها در مشخصه Metric.navigationType پرچم‌گذاری می‌کند، اگر صفحه به‌طور کامل یا جزئی پیش‌پردازش شده باشد.

اندازه‌گیری پیش‌پرداخت‌ها

اینکه صفحه‌ای پیش‌پردازش شده است یا نه را می‌توان با ورودی غیرصفر activationStart از PerformanceNavigationTiming مشاهده کرد. سپس می‌توان این را بااستفاده از «بُعد سفارشی» یا موارد مشابه هنگام ثبت بازدیدهای صفحه ثبت کرد، برای مثال بااستفاده از تابع pagePrerendered که قبلاً شرح داده شد:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

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

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

اندازه‌گیری نرخ‌های موفقیت

علاوه‌بر اندازه‌گیری تأثیر صفحه‌هایی که پس‌از پیش‌پرداز بازدید می‌شوند، اندازه‌گیری صفحه‌هایی که پیش‌پرداز می‌شوند و متعاقباً بازدید نمی‌شوند نیز مهم است. این امر می‌تواند به این معنی باشد که شما بیش‌ازحد پیش‌پرداز می‌کنید و منابع ارزشمند کاربر را برای سود کمی مصرف می‌کنید.

این را می‌توان با فعال کردن یک رویداد تجزیه‌وتحلیل هنگام درج قوانین گمانه‌زنی اندازه‌گیری کرد—پس‌از بررسی اینکه مرورگر از پیش‌پرداخت بااستفاده از HTMLScriptElement.supports('speculationrules') پشتیبانی می‌کند—تا نشان دهد که پیش‌پرداخت درخواست شده است. (توجه داشته باشید که صرفاً درخواست پیش‌پرداز نشان‌دهنده شروع یا تکمیل پیش‌پرداز نیست، زیرا همان‌طور که قبلاً اشاره شد، پیش‌پرداز یک اشاره به مرورگر است و ممکن است مرورگر براساس تنظیمات کاربر، استفاده کنونی از حافظه، یا سایر روش‌های اکتشافی تصمیم بگیرد صفحه‌ها را پیش‌پرداز نکند.)

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

سپس می‌توان «نرخ موفقیت» را با نگاه کردن به تفاوت بین این دو رقم تخمین زد. برای صفحه‌هایی که از Speculation Rules API برای پیش‌پرداز کردن صفحه‌ها استفاده می‌کنید، می‌توانید قوانین را به‌طور مناسب تنظیم کنید تا مطمئن شوید که نرخ موفقیت بالایی را حفظ می‌کنید تا تعادل بین استفاده از منابع کاربران برای کمک به آن‌ها در مقابل استفاده غیرضروری از آن حفظ شود.

توجه داشته باشید که ممکن است برخی‌از پیش‌پردازها به‌دلیل پیش‌پرداز نوار نشانی انجام شود و نه فقط به‌دلیل قوانین گمانه‌زنی شما. اگر می‌خواهید این موارد را از هم متمایز کنید، می‌توانید document.referrer را بررسی کنید (که برای پیمایش نوار نشانی، ازجمله پیمایش‌های نوار نشانی پیش‌پرداخت‌شده، خالی خواهد بود).

به‌یاد داشته باشید که صفحه‌هایی را که پیش‌پرداز نشده‌اند نیز بررسی کنید، زیرا این امر می‌تواند نشان دهد که این صفحه‌ها واجدشرایط پیش‌پرداز شدن نیستند، حتی از نوار نشانی. این یعنی ممکن است از این بهبود عملکرد بهره‌مند نشوید. تیم Chrome به‌دنبال افزودن ابزار اضافی برای آزمایش واجدشرایط بودن «پیش‌پرداز» است، شاید مشابه ابزار آزمایش حافظه نهان ناوبری بین صفحات، و همچنین احتمالاً افزودن یک میانای برنامه‌سازی کاربردی برای افشای دلیل ناموفق بودن پیش‌پرداز.

تأثیر بر افزونه‌ها

پست اختصاصی درباره افزونه‌های Chrome: گسترش دادن میانای برنامه‌سازی کاربردی برای پشتیبانی از «پیمایش فوری» را ببینید که جزئیات برخی ملاحظات اضافی را که ممکن است نویسندگان افزونه‌ها لازم باشد برای صفحه‌های پیش‌پرداخت‌شده درنظر بگیرند ارائه می‌دهد.

بازخورد

پیش‌پرداخت به‌طور فعال توسط تیم Chrome درحال توسعه است و برنامه‌های زیادی برای گسترش دامنه آنچه در نسخه Chrome 108 دردسترس قرار گرفته است وجود دارد. از هرگونه بازخورد درباره مخزن GitHub یا استفاده از ردیاب مشکل ما استقبال می‌کنیم و مشتاقانه منتظر شنیدن و هم‌رسانی مطالعات موردی این میانای برنامه‌سازی کاربردی جدید و هیجان‌انگیز هستیم.

تصدیق‌ها

ریزعکس از Marc-Olivier Jodoin در Unsplash