برای پیمایش فوری صفحات، صفحات را در Chrome از قبل اجرا کنید

Barry Pollard

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

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

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

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

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

چگونه یک صفحه از قبل اجرا می شود؟

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

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

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

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

تاثیر پیش اجرا

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

سایت نمونه در حال حاضر یک سایت سریع است، اما حتی با این مورد نیز می توانید ببینید که چگونه پیش اجرا تجربه کاربر را بهبود می بخشد. بنابراین، این می تواند تأثیر مستقیمی بر Core Web Vitals یک سایت داشته باشد، با LCP نزدیک به صفر، کاهش CLS (زیرا هر بار CLS قبل از نمای اولیه اتفاق می افتد)، و INP بهبود یافته (زیرا بارگیری باید قبل از تعامل کاربر تکمیل شود).

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

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

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

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

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

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

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

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

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

• برای سطح اطمینان بیش از 50٪ (نشان داده شده با رنگ کهربایی)، Chrome به طور فعال به دامنه متصل می شود، اما صفحه را از قبل اجرا نمی کند.
• برای سطح اطمینان بیش از 80٪ (به رنگ سبز نشان داده شده است)، Chrome URL را از قبل اجرا می کند.

Speculation Rules API

برای گزینه Speculation Rules API prerender، توسعه دهندگان وب می توانند دستورالعمل های JSON را در صفحات خود درج کنند تا به مرورگر اطلاع دهند که کدام URL ها را باید از قبل اجرا کند:

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

یا براساس قوانین سند (موجود در Chrome 121)، که پیوندهای موجود در سند را بر اساس انتخابگرهای href (بر اساس الگوی URL 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>

تیم Chrome یک Codelab قوانین حدس و گمان آماده کرده است که شما را با افزودن قوانین حدس و گمان به یک سایت راهنمایی می کند.

اشتیاق

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

• immediate : برای حدس زدن در اسرع وقت، یعنی به محض رعایت قوانین حدس و گمان استفاده می شود.
• eager : این به طور یکسان با تنظیمات immediate عمل می کند، اما در آینده، ما به دنبال این هستیم که آن را جایی بین immediate و moderate ​​قرار دهیم.
• moderate ​​: اگر نشانگر را روی یک پیوند به مدت 200 میلی ثانیه نگه دارید (یا روی رویداد pointerdown اگر زودتر باشد و در تلفن همراهی که رویداد hover وجود ندارد) حدس و گمان را انجام می دهد.
• conservative : در مورد اشاره گر یا لمس پایین حدس می زند.

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

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

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

گزینه moderate ​​یک راه میانی است و بسیاری از سایت‌ها می‌توانند از قانون گمانه‌زنی زیر بهره ببرند که در هنگام نگه داشتن نشانگر روی پیوند به مدت 200 میلی‌ثانیه یا در رویداد pointerdown به‌عنوان یک پیاده‌سازی اساسی و در عین حال قدرتمند از قوانین گمانه‌زنی، پیوند را از قبل اجرا می‌کند:

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

واکشی از پیش

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

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

محدودیت های کروم

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

تنظیمات moderate ​​و conservative - که به تعامل کاربر بستگی دارد - به روش First In, First Out (FIFO) کار می کنند: پس از رسیدن به حد مجاز، یک حدس و گمان جدید باعث می شود که قدیمی ترین حدس و گمان لغو شود و با جدیدتر جایگزین شود تا حافظه ذخیره شود. یک حدس و گمان لغو شده می تواند دوباره فعال شود - برای مثال با نگه داشتن دوباره ماوس روی آن پیوند - که منجر به گمانه زنی مجدد آن URL می شود و قدیمی ترین حدس و گمان را از بین می برد. در این مورد، حدس و گمان قبلی، هر گونه منابع قابل ذخیره را در حافظه پنهان HTTP برای آن URL ذخیره می‌کند، بنابراین حدس‌زنی برای زمان بیشتر باید هزینه کمتری داشته باشد. به همین دلیل است که این محدودیت روی آستانه متوسط ​​2 تنظیم می شود. قوانین لیست استاتیک توسط یک اقدام کاربر ایجاد نمی شوند و بنابراین محدودیت بالاتری دارند زیرا مرورگر نمی تواند بداند کدام یک و چه زمانی مورد نیاز است.

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

کروم همچنین از استفاده از حدس و گمان در شرایط خاصی مانند:

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

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

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

نحوه گنجاندن قوانین حدس و گمان در یک صفحه

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

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

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

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

هدر Speculation-Rules HTTP

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

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

Speculation-Rules: "/speculationrules.json"

این منبع باید از نوع MIME صحیح استفاده کند و اگر منبع متقاطع است، یک بررسی CORS را پاس کند.

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

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

قوانین حدس و گمان و SPA

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

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

اشکال زدایی قوانین حدس و گمان

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

قوانین گمانه زنی متعدد

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

لیست URL ها:

<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>

پشتیبانی No-Vary-Search

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

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

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

پیشنهاد 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 متفاوت است. بنابراین ما آن URL را مشتاقانه از قبل واکشی می کنیم و باید یک هدر HTTP No-Vary-Search نشان دهد که نشان می دهد صفحه می تواند برای هر پارامتر جستجوی id استفاده شود.

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

حدس و گمان محدودیت ها و پیشرفت های آینده را قوانین می کند

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

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

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

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

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

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

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

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

پشتیبانی از 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);
}

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

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

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

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

برای افزودن قوانین حدس و گمان با استفاده از یک مدیر برچسب مانند Google Tag Manager (GTM) به جای افزودن عنصر <script type = "speculationrules"> مستقیماً به همان دلایلی که قبلاً ذکر شد، باید آنها را از طریق جاوا اسکریپت درج کنید:

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

قوانین حدس و گمان را لغو کنید

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

قوانین حدس و گمان و خط مشی امنیت محتوا

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

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

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

Prerender معمولاً یک تجربه مثبت برای کاربران است زیرا امکان رندر سریع صفحه را فراهم می کند - اغلب آنی. این به نفع کاربر و صاحب سایت است، زیرا صفحات از قبل اجرا شده تجربه کاربری بهتری را فراهم می‌کنند که در غیر این صورت ممکن است دستیابی به آن دشوار باشد.

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

پیش اجرا را در کروم فعال و غیرفعال کنید

اجرا اولیه فقط برای آن دسته از کاربران Chrome فعال است که تنظیمات "پیش بارگیری صفحات" را در chrome://settings/performance/ دارند. به‌علاوه، پیش‌اجرا در دستگاه‌های با حافظه کم نیز غیرفعال می‌شود، یا اگر سیستم عامل در حالت‌های Save-data یا Energy Saver باشد. بخش محدودیت‌های Chrome را ببینید.

شناسایی و غیرفعال کردن prerender سمت سرور

صفحات از قبل اجرا شده با هدر HTTP Sec-Purpose ارسال خواهند شد:

Sec-Purpose: prefetch;prerender

صفحات از پیش واکشی شده با استفاده از Speculation Rules API دارای این سرصفحه برای prefetch خواهند بود:

Sec-Purpose: prefetch

سرورها می توانند بر اساس این هدر پاسخ دهند، درخواست های گمانه زنی را ثبت کنند، محتوای مختلف را برگردانند یا از اجرای پیش اجرا جلوگیری کنند. اگر کد پاسخ نهایی ناموفق برگردانده شود - یعنی در بازه 200-299 پس از تغییر مسیرها نباشد - صفحه از قبل اجرا نمی شود و هر صفحه واکشی اولیه کنار گذاشته می شود. همچنین توجه داشته باشید که پاسخ‌های 204 و 205 علاوه بر این برای اجرای از قبل معتبر نیستند ، اما برای واکشی اولیه معتبر هستند.

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

شناسایی پیش اجرا در جاوا اسکریپت

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

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

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

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

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

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

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

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

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

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

با این حال - مخصوصاً هنگام استفاده از 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 برای هدف قرار دادن صفحات پیش اجرا استفاده کنید.

سایر محتواها را در حین اجرای پیش نمایش نگه دارید

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

به عنوان مثال، با توجه به این اسکریپت:

<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 نیز بررسی شود - برای مثال، هنگام بازگشت به صفحه‌ای که پس‌زمینه بوده است، شمارنده‌های سبد خرید باید با آخرین تعداد کالاهای موجود در سبد به‌روزرسانی شوند. بنابراین، این یک مشکل خاص پیش‌اجرا نیست، اما اجرای پیش‌پرداخت فقط یک مشکل موجود را آشکارتر می‌کند.

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

عملکرد را اندازه گیری کنید

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

برای Core Web Vitals که توسط Chrome از طریق گزارش تجربه کاربر Chrome اندازه‌گیری می‌شود، این موارد برای اندازه‌گیری تجربه کاربر در نظر گرفته شده‌اند. بنابراین اینها بر اساس زمان فعال سازی اندازه گیری می شوند. به عنوان مثال، این اغلب منجر به یک LCP 0 ثانیه ای می شود، که نشان می دهد این روش عالی برای بهبود Core Web Vitals شما است.

از نسخه 3.1.0، کتابخانه web-vitals به‌روزرسانی شده است تا پیمایش‌های از پیش اجرا شده را به همان روشی که Chrome Core Web Vitals را اندازه‌گیری می‌کند، انجام دهد. اگر صفحه به طور کامل یا جزئی از قبل اجرا شده باشد، این نسخه همچنین پیمایش‌های از پیش اجرا شده را برای آن معیارها در ویژگی 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') پشتیبانی می کند - نشان می دهد که از پیش درخواست درخواست شده است. (توجه داشته باشید که فقط به این دلیل که از یک پیش نویس درخواست شده است ، نشان نمی دهد که یک پیش نویس شروع یا تکمیل شده است ، همانطور که قبلاً ذکر شد ، یک پیش نویس یک اشاره به مرورگر است و ممکن است انتخاب کند که صفحات پیش نویس در تنظیمات کاربر ، استفاده از حافظه فعلی یا سایر مواد مجوز را انتخاب نکند.)

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

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

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

به یاد داشته باشید همچنین به صفحاتی که هیچ پیش نویس ندارند ، نگاه کنید ، زیرا این نشان می دهد که این صفحات حتی از نوار آدرس ، واجد شرایط برای پیش نویس نیستند. این ممکن است به این معنی باشد که شما از این تقویت عملکرد بهره نمی برید. تیم Chrome به دنبال اضافه کردن ابزاری اضافی برای تست واجد شرایط بودن پیش از این است که شاید شبیه به ابزار تست BFCache باشد ، و همچنین به طور بالقوه یک API را اضافه می کند تا چرا یک پیش نویس شکست خورده است.

تأثیر بر روی پسوندها

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

بازخورد

Prerendering توسط تیم Chrome در حال توسعه است و برنامه های زیادی برای گسترش دامنه آنچه در نسخه Chrome 108 در دسترس است وجود دارد. ما از هرگونه بازخورد در مورد repo github یا استفاده از ردیاب شماره خود استقبال می کنیم و مشتاقانه منتظر شنیدن و به اشتراک گذاری مطالعات موردی از این API جدید هیجان انگیز هستیم.

لینک های مرتبط

• قوانین حدس و گمان CodeLab
• اشکال زدایی قوانین حدس و گمان
• معرفی prefetch نوستات
• قوانین حدس و گمان مشخصات API
• گمانه زنی های ناوبری repo github
• برنامه های افزودنی Chrome: گسترش API برای حمایت از ناوبری فوری

قدردانی ها

تصویر تصویربرداری توسط Marc-Olivier Jodoin در Unsplash

Barry Pollard

تیم Chrome مجدداً صفحات آینده را که کاربر احتمالاً به آن حرکت می کند ، بازگرداند.

تاریخچه مختصری از prerender

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

این پیش نویس میراث با استفاده از لینک rel=prerender به نفع prefetch نوستات کاهش یافته است ، که در عوض منابع مورد نیاز صفحه آینده را بدست می آورد ، اما به طور کامل صفحه را انجام نمی داد و JavaScript را اجرا نمی کرد. Prefetch Nostate با بهبود بارگذاری منابع به بهبود عملکرد صفحه کمک می کند ، اما یک صفحه فوری را مانند یک پیش نویس کامل تحویل نمی دهد.

تیم Chrome اکنون مجدداً مجدداً به Chrome بازگردد. برای جلوگیری از عوارض در استفاده از موجود ، و برای گسترش آینده در آینده ، این مکانیسم جدید پیش نویس از <link rel="prerender"...> syntax استفاده نمی کند ، که با توجه به بازنشستگی این در برخی از نقاط در آینده باقی می ماند.

چگونه صفحه ای از پیش تنظیم شده است؟

یک صفحه از چهار راه می تواند از قبل تنظیم شود ، که همه آنها هدف سریعتر کردن ناوبری ها هستند:

1. هنگامی که یک URL را در نوار آدرس Chrome تایپ می کنید (همچنین به عنوان "Omnibox" نیز شناخته می شود) ، Chrome ممکن است به طور خودکار صفحه را برای شما قرار دهد ، اگر اعتماد به نفس بالایی داشته باشد ، بر اساس سابقه مرور قبلی خود از آن صفحه بازدید خواهید کرد.
2. هنگامی که از نوار نشانک استفاده می کنید ، Chrome ممکن است به طور خودکار صفحه را برای شما در نگه داشتن نشانگر بر روی یکی از دکمه های نشانک قرار دهد.
3. هنگامی که یک اصطلاح جستجو را در نوار آدرس Chrome تایپ می کنید ، Chrome ممکن است به طور خودکار صفحه نتایج جستجو را انجام دهد ، هنگامی که به موتور جستجو این کار را انجام دهید.
4. سایت ها می توانند از API قوانین حدس و گمان استفاده کنند تا به طور برنامه ای به Chrome بگویند که صفحات را برای پیش نویس قرار می دهد. این جایگزین چیزی است که <link rel="prerender"...> استفاده می شود و به سایت ها اجازه می دهد تا صفحه ای را بر اساس قوانین حدس و گمان در صفحه انجام دهند. اینها می توانند از نظر آماری در صفحات وجود داشته باشند ، یا به صورت پویا توسط JavaScript تزریق شوند زیرا صاحب صفحه مناسب را می بیند.

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

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

تأثیر پیش نویس

Prerendering اجازه می دهد تا یک صفحه نزدیک نزدیک به صفحه همانطور که در فیلم زیر نشان داده شده است:

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

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

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

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

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

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

خطوط سبز نشانگر اعتماد به نفس کافی برای ایجاد پیش نویس است. در این مثال تایپ کردن "S" اعتماد به نفس معقول (کهربا) می دهد ، اما هنگامی که "SH" را تایپ می کنید ، کروم اطمینان کافی دارد که تقریباً همیشه به https://sheets.google.com حرکت می کنید.

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

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

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

• برای بیش از 50 ٪ سطح اطمینان (در کهربا نشان داده شده است) ، کروم به طور پیشگیرانه به دامنه متصل می شود ، اما صفحه را از پیش نمی گیرد.
• برای بیش از 80 ٪ سطح اطمینان (به رنگ سبز نشان داده شده است) ، Chrome URL را از قبل انتخاب می کند.

قوانین گمانه زنی API

برای گزینه API Prerender قوانین گمانه زنی ، توسعه دهندگان وب می توانند دستورالعمل های JSON را روی صفحات خود وارد کنند تا به مرورگر اطلاع دهند که کدام URL ها را به Prerender:

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

یا طبق قوانین اسناد (موجود از Chrome 121) ، که پیوندهای پیش نویس موجود در سند بر اساس انتخاب کنندگان href (بر اساس API الگوی URL ) یا انتخاب کننده 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>

تیم Chrome قوانین حدس و گمان CodeLab را تهیه کرده اند که شما را از طریق افزودن قوانین حدس و گمان به یک سایت پیاده می کند.

اشتیاق

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

• immediate : این مورد برای حدس و گمان در اسرع وقت استفاده می شود ، یعنی به محض مشاهده قوانین حدس و گمان.
• eager : این به طور یکسان با شرایط immediate رفتار می کند ، اما در آینده ، ما به دنبال این هستیم که این را در جایی بین immediate و moderate ​​قرار دهیم.
• moderate : اگر این نشانگر را بیش از پیوندی برای 200 میلی ثانیه (یا در رویداد pointerdown اگر زودتر باشد ، و در تلفن همراه که هیچ رویداد hover وجود ندارد) ، گمانه زنی ها را انجام می دهد.
• conservative : این حدس و گمان در مورد نشانگر یا لمس کردن است.

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

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

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

گزینه moderate یک میانه است و بسیاری از سایت ها می توانند از قانون گمانه زنی های زیر بهره مند شوند که هنگام نگه داشتن نشانگر از طریق لینک برای 200 میلی ثانیه یا در رویداد Pointerdown به عنوان یک اجرای اساسی - با اما قدرتمند - اجرای قوانین حدس و گمان ، پیوندی را از دست می دهد:

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

واکشی از پیش

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

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

محدودیت های کروم

Chrome برای جلوگیری از استفاده بیش از حد از قوانین گمانه زنی API محدودیت هایی دارد:

تنظیمات moderate ​​و conservative - که به تعامل کاربر بستگی دارد - در ابتدا به روش اول ، اول (FIFO) کار می کنند: پس از رسیدن به حد مجاز ، یک حدس و گمان جدید باعث می شود که قدیمی ترین حدس و گمان لغو شود و توسط یک جدیدتر جایگزین شود تا حافظه را حفظ کند. یک حدس و گمان لغو شده می تواند دوباره ایجاد شود-برای مثال با معلق در آن پیوند-که منجر به انتخاب مجدد URL می شود و قدیمی ترین گمانه زنی ها را بیرون می کشد. در این حالت ، گمانه زنی های قبلی هرگونه منبع ذخیره شده در حافظه پنهان HTTP را برای آن URL ذخیره کرده است ، بنابراین گمانه زنی ها در زمان بیشتر باید هزینه کمتری داشته باشند. به همین دلیل محدودیت در آستانه متوسط ​​2 تنظیم شده است. قوانین لیست استاتیک توسط یک عمل کاربر ایجاد نمی شود و بنابراین حد بالاتری دارند زیرا امکان وجود مرورگر امکان پذیر نیست که مورد نیاز و چه زمانی مورد نیاز باشد.

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

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

• پس انداز داده
• صرفه جویی در مصرف انرژی در هنگام فعال شدن و باتری کم.
• محدودیت های حافظه.
• هنگامی که تنظیم "صفحات از پیش بار" خاموش می شود (که به صراحت توسط پسوندهای کروم مانند Origin Ublock خاموش می شود).
• صفحات در برگه های پس زمینه باز شده اند.

Chrome همچنین تا زمان فعال سازی ، Iframes را در صفحات پیش ساخته قرار نمی دهد.

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

نحوه شامل قوانین حدس و گمان در یک صفحه

قوانین حدس و گمان می تواند به صورت آماری در صفحه HTML یا پویا در صفحه توسط JavaScript وارد شود:

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

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

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

هدر HTTP Speculation-Rules

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

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

Speculation-Rules: "/speculationrules.json"

این منبع باید از نوع صحیح MIME استفاده کند و اگر یک منبع متقاطع است ، یک بررسی CORS را منتقل کنید.

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

اگر می خواهید از URL های نسبی استفاده کنید ، ممکن است بخواهید کلید "relative_to": "document" را در قوانین حدس و گمان خود درج کنید. در غیر این صورت ، URL های نسبی نسبت به قوانین گمانه زنی URL JSON FILE خواهند بود. این ممکن است به ویژه در صورت نیاز به انتخاب برخی از پیوندهای یا همه آنها-با منبت کاری ، مفید باشد.

قوانین حدس و گمان و اسپا

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

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

قوانین حدس و گمان اشکال زدایی

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

قوانین حدس و گمان چندگانه

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

لیست URL ها:

<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>

پشتیبانی No-Vary-Search

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

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

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

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

قوانین حدس و گمان با استفاده از 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>

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

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

محدودیت های قوانین حدس و گمان و پیشرفت های آینده

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

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

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

قوانین حدس و گمان از قبل از پیش تنظیمات متقاطع پشتیبانی می کنند ، اما باز هم فقط وقتی کوکی ها برای دامنه متقاطع وجود ندارند. اگر کوکی ها از کاربر که قبلاً از آن سایت بازدید کرده اند وجود داشته باشد ، حدس و گمان ایجاد نمی شود و شکست در Devtools را نشان می دهد.

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

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

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

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

ردیابی قوانین حدس و گمان پشتیبانی API

شما می توانید از قوانین مربوط به حدس و گمان پشتیبانی API با چک های استاندارد HTML استفاده کنید:

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

قوانین حدس و گمان را به صورت پویا از طریق JavaScript اضافه کنید

این نمونه ای از افزودن یک قانون حدس و گمان prerender با JavaScript است:

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);
}

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

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

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

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

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

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

قوانین حدس و گمان را لغو کنید

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

قوانین حدس و گمان و سیاست امنیت محتوا

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

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

تشخیص و غیرفعال کردن

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

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

Prerender را در Chrome فعال و غیرفعال کنید

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

طرف سرور prerender را تشخیص داده و غیرفعال کنید

صفحات پیش از پیش با عنوان HTTP Sec-Purpose ارسال می شود:

Sec-Purpose: prefetch;prerender

صفحات از پیش تنظیم شده با استفاده از قوانین حدس و گمان API این عنوان را prefetch می کند:

Sec-Purpose: prefetch

سرورها می توانند بر اساس این هدر پاسخ دهند ، تا درخواست های حدس و گمان را وارد کنند ، محتوای مختلفی را برگردانند یا از وقوع یک پیش نویس جلوگیری کنند. اگر یک کد پاسخ نهایی غیر موفق بازگردانده شود-یعنی در محدوده 200-299 پس از تغییر مسیر-آنگاه صفحه از پیش تنظیم نمی شود و هر صفحه پیش نمایش دور می شود. همچنین توجه داشته باشید که پاسخ های 204 و 205 علاوه بر این برای پیش نویس معتبر نیستند ، اما برای پیش نویس معتبر هستند.

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

تشخیص prerender در JavaScript

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

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

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

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

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

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

با استفاده از این API ها ، JavaScript Frontend می تواند به طور مناسب به صفحات پیش ساخته شده تشخیص داده و عمل کند.

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

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

صفحات فقط باید در صورت وجود احتمال زیاد صفحه توسط کاربر بارگیری شوند. به همین دلیل گزینه های پیش نمایش نوار آدرس Chrome فقط در شرایطی اتفاق می افتد که چنین احتمال بالایی وجود داشته باشد (بیش از 80 ٪ از زمان).

با این حال - به ویژه هنگام استفاده از 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 استفاده کنید. Prerendering and prerenderingchange برای هدف قرار دادن صفحات پیش نویس.

سایر مطالب را در حین پیش نویس نگه دارید

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

به عنوان مثال ، با توجه به این اسکریپت:

<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 بررسی شود - برای مثال ، هنگام بازگشت به صفحه ای که پس زمینه بوده است ، باید هر پیشخوان سبد خرید با آخرین تعداد موارد موجود در سبد به روز شود. So this is not a prerender-specific problem but prerender is just making an existing issue more obvious.

One way that Chrome mitigates some of the need for manually wrapping scripts or functions, is that certain APIs are held back as mentioned previously , and also third-party iframes are not rendered, so it's only content on top of this that is required to be manually held back.

عملکرد را اندازه گیری کنید

For measuring performance metrics, analytics should consider whether it is better to measure these based upon the activation time rather than the page load time that browser APIs will report.

For Core Web Vitals, measured by Chrome through the Chrome User Experience Report , these are intended to measure the user experience. So these are measured based on activation time. This will often result in a 0 second LCP for example, showing this is great way of improving your Core Web Vitals.

From version 3.1.0, the web-vitals library has been updated to handle prerendered navigations in the same way Chrome measures Core Web Vitals. This version also flags prerendered navigations for those metrics in the Metric.navigationType attribute if the page was fully or partially prerendered.

Measure prerenders

Whether a page is prerendered can be seen with a non-zero activationStart entry of PerformanceNavigationTiming . This can then be logged using a Custom Dimension, or similar when logging the page views, for example using the pagePrerendered function described previously :

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

This will allow your analytics to show how many navigation are prerendered compared to other types of navigation, and also allow you to correlation any performance metrics or business metrics to these different navigation types. Faster pages means happier users, which can often have real impact on business measures as our case studies show.

As you measure the business impact of prerendering pages for instant navigations, you can decide whether it is worth investing more effort in using this technology to allow more navigations to be prerendered, or to investigate why pages are not being prerendered.

Measure hit rates

In addition to measuring the impact of pages that are visited after a prerender, it is also important to measure pages that are prerendered and not subsequently visited. This could imply you are prerendering too much, and using up valuable resources of the user for little benefit.

This can be measured by firing an analytics event when speculation rules are inserted—after checking the browser supports prerendering using HTMLScriptElement.supports('speculationrules') —to indicate that prerender was requested. (Note that just because a prerender was requested, does not indicate that a prerender was started or completed as, as noted previously, a prerender is a hint to the browser and it may choose not to prerender pages on user settings, current memory usage, or other heuristics.)

You can then compare the number of these events, to the actual prerender page views. Or alternatively fire another event on activation if that makes it easier to compare.

The "successful hit rate" can then be approximated by looking at the difference between these two figures. For pages where you are using the Speculation Rules API to prerender the pages, you can adjust the rules appropriately to ensure you keep a high hit rate to maintain the balance between using up the users resources to help them, versus using it needlessly.

Be aware that some prerendering may be taking place due to the address bar prerendering and not just your speculation rules. You can check the document.referrer (which will be blank for address bar navigation including prerendered address bar navigations) if you want to differentiate these.

Remember to also look at pages which have no prerenders, as that could indicate these pages are not eligible for prerendering, even from the address bar. That may mean you are not benefiting from this performance enhancement. The Chrome team is looking to add extra tooling to test for Prerender eligibility perhaps similar to the bfcache testing tool , and also potentially add an API to expose why a prerender failed.

Impact on extensions

See the dedicated post on Chrome Extensions: Extending API to support Instant Navigation which details some additional considerations extension authors may need to think about for prerendered pages.

بازخورد

Prerendering is in active development by the Chrome team, and there are plenty of plans to expand the scope of what has been made available in the Chrome 108 release. We welcome any feedback on the GitHub repo or using our issue tracker , and look forward to hearing and sharing case studies of this exciting new API.

لینک های مرتبط

• Speculation Rules Codelab
• اشکال زدایی قوانین حدس و گمان
• Introducing NoState Prefetch
• Speculation Rules API specification
• The Navigational speculation GitHub repo
• Chrome Extensions: Extending API to support Instant Navigation

قدردانی ها

Thumbnail image by Marc-Olivier Jodoin on Unsplash

Barry Pollard

The Chrome team has brought back full prerendering of future pages that a user is likely to navigate to.

A brief history of prerender

In the past, Chrome supported the <link rel="prerender" href="/next-page"> resource hint, however it was not broadly supported beyond Chrome, and it wasn't a very expressive API.

This legacy prerendering using the link rel=prerender hint was deprecated in favor of NoState Prefetch , which instead fetched the resources needed by the future page, but did not fully prerender the page nor execute JavaScript. NoState Prefetch does help improve page performance by improving the resource loading, but won't deliver an instant page load like a full prerender would.

The Chrome team has now reintroduced full prerendering back into Chrome. To avoid complications with existing usage, and to allow for future expansion of prerendering, this new prerender mechanism won't use the <link rel="prerender"...> syntax, which remains in place for NoState Prefetch, with a view of retiring this at some point in the future.

How is a page prerendered?

A page can be prerendered in one of four ways, all of which aim to make navigations quicker:

1. When you type a URL into the Chrome address bar (also known as "the omnibox"), Chrome may automatically prerender the page for you, if it has high confidence you will visit that page, based on your previous browsing history.
2. When you use the bookmarks bar, Chrome may automatically prerender the page for you on holding the pointer over one of the bookmark buttons.
3. When you type a search term into the Chrome address bar, Chrome may automatically prerender the search results page, when instructed to do so by the search engine.
4. Sites can use the Speculation Rules API , to programmatically tell Chrome which pages to prerender. This replaces what <link rel="prerender"...> used to do and allows sites to proactively prerender a page based on speculation rules on the page. These can statically exist on the pages, or be dynamically injected by JavaScript as the page owner sees fit.

In each of these cases, a prerender behaves as if the page has been opened in an invisible background tab, and then is "activated" by replacing the foreground tab with that prerendered page. If a page is activated before it has fully prerendered, then its current state is "foregrounded" and continues to load, which means you can still get a good head start.

As the prerendered page is opened in a hidden state, a number of APIs that cause intrusive behaviors (for example, prompts) are not activated in this state, and are instead delayed until the page is activated. In the small number of cases where this is not yet possible, the prerender is canceled. The Chrome team is working on exposing prerender cancellation reasons as an API, and also enhancing DevTools capabilities to make identifying such edge cases easier.

Impact of prerendering

Prerendering allows a near-instant page load as shown in the following video:

The example site is already a fast site, but even with this you can see how prerendering improves the user experience. This can therefore also have a direct impact on a site's Core Web Vitals , with near zero LCP, reduced CLS (since any load CLS happens before the initial view), and improved INP (since the load should be completed before the user interacts).

Even when a page activates before it is fully loaded, having a head start to the page load, should improve the loading experience. When a link is activated while prerendering is still happening, the prerendering page will move to the main frame and continue loading.

However, prerendering does use additional memory and network bandwidth. Be careful not to over-prerender, at a cost of user resources. Only prerender when there is a high likelihood of the page being navigated to.

See the Measuring performance section for more information on how to measure the actual performance impact in your analytics.

View Chrome's address bar predictions

For the first use case, you can view Chrome's predictions for URLs in the chrome://predictors page:

Green lines indicate enough confidence to trigger prerendering. In this example typing "s" gives a reasonable confidence (amber), but once you type "sh" then Chrome has enough confidence that you nearly always navigate to https://sheets.google.com .

This screenshot was taken in a relatively fresh Chrome install, and filtering out zero confidence predictions, but if you view your own predictors you will likely see considerably more entries, and potentially more characters required to reach a high enough confidence level.

These predictors are also what drive the address bar suggested options you may have noticed:

Chrome will continually update its predictors based on your typing and selections.

• For a greater than 50% confidence level (shown in amber), Chrome proactively preconnects to the domain, but does not prerender the page.
• For a greater than 80% confidence level (shown in green), Chrome will prerender the URL.

The Speculation Rules API

For the Speculation Rules API prerender option, web developers can insert JSON instructions onto their pages to inform the browser about which URLs to prerender:

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

Or by document rules (available from Chrome 121), which prerenders links found in the document based on href selectors (based on the URL Pattern API ) or CSS selectors:

<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>

The Chrome team have prepared a Speculation Rules Codelab which will walk you through adding Speculation Rules to a site.

اشتیاق

An eagerness setting is used to indicate when the speculations should fire, which is particularly useful for document rules:

• immediate : This is used to speculate as soon as possible, that is, as soon as the speculation rules are observed.
• eager : This behaves identically to the immediate setting, but in future, we are looking to place this somewhere between immediate and moderate .
• moderate : This performs speculations if you hold the pointer over a link for 200 milliseconds (or on the pointerdown event if that is sooner, and on mobile where there is no hover event).
• conservative : This speculates on pointer or touch down.

The default eagerness for list rules is immediate . The moderate and conservative options can be used to limit list rules to URLs that a user interacts with to a specific list. Though in many cases, document rules with an appropriate where condition may be more appropriate.

The default eagerness for document rules is conservative . Given a document can consist of many URLs, use of immediate or eager for document rules should be used with caution (see also the Chrome limits section next).

Which eagerness setting to use depends on your site. For a lightweight, static site, speculating more eagerly may have little cost and be beneficial for users. Sites with more complex architectures and heavier page payloads may prefer to reduce waste by speculating less often until you get more positive signal of intent from users to limit waste.

The moderate option is a middle ground, and many sites could benefit from the following speculation rule that would prerender a link when holding the pointer over the link for 200 milliseconds or on the pointerdown event as a basic—yet powerful—implementation of speculation rules:

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

واکشی از پیش

Speculation rules can also be used to just prefetch pages, without a full prerender. This can often be a good first step on the road to prerendering:

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

Chrome limits

Chrome has limits in place to prevent overuse of the Speculation Rules API:

The moderate and conservative settings—which depend on user interaction—work in a First In, First Out (FIFO) manner : after reaching the limit, a new speculation will cause the oldest speculation to be canceled and replaced by the newer one to conserve memory. A canceled speculation can be triggered again—for example by hovering over that link again—which will result in that URL being re-speculated, pushing out the oldest speculation. In this case the previous speculation will have cached any cacheable resources in the HTTP Cache for that URL so speculationing a further time should have a reduced cost. This is why the limit is set to the modest threshold of 2. Static list rules are not triggered by a user action and so have a higher limit as it is not possible for the browser to know which are needed and when they are needed.

The immediate and eager limits are also dynamic, so removing a list URL script element will create capacity by canceling those removed speculations.

Chrome will also prevent speculations being used in certain conditions including:

• Save-Data .
• Energy saver when enabled and on low battery.
• Memory constraints.
• When the "Preload pages" setting is turned off (which is also explicitly turned off by Chrome extensions such as uBlock Origin).
• Pages opened in background tabs.

Chrome also does not render cross-origin iframes on prerendered pages until activation.

All of these conditions aim to reduce the impact of over-speculation when it would be detrimental to users.

How to include speculation rules on a page

Speculation rules can be statically included in the page's HTML or dynamically inserted into the page by JavaScript:

• Statically included speculation rules : For example a news media site, or a blog may prerender the newest article, if that is often the next navigation for a large proportion of users, Alternatively, document rules with a moderate or conservative can be used to speculate as users interact with links.
• Dynamically inserted speculation rules : This could be based on application logic, personalized to the user, or based on other heuristics.

Those favoring dynamic insertion based on actions such as hovering over, or clicking down on a link—as many libraries have done in the past with <link rel=prefetch> —are recommended to look at document rules, as these allow the browser to handle many of your use cases.

Speculation rules can be added in either the <head> or the <body> of in the main frame. Speculation rules in subframes are not acted upon, and speculation rules in prerendered pages are only acted upon once that page is activated.

The Speculation-Rules HTTP header

Speculation rules can also be delivered by using a Speculation-Rules HTTP header, rather than including them directly in the document's HTML. This allows easier deployment by CDNs without the need to alter document contents themselves.

The Speculation-Rules HTTP header is returned with the document, and points to a location of a JSON file containing the speculation rules:

Speculation-Rules: "/speculationrules.json"

This resource must use the correct MIME type and, if it is a cross-origin resource, pass a CORS check.

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

If you want to use relative URLs you may want to include the "relative_to": "document" key in your speculation rules. Otherwise, relative URLs will be relative to the speculation rules JSON file's URL. This may be particularly useful if you need to select some—or all—same-origin links.

Speculation rules and SPAs

Speculation rules are only supported for full page navigations managed by the browser, and not for Single Page Apps (SPA) or app shell pages. These architecture don't use document fetches, but instead make API or partial fetches of data or pages—which are then processed and presented in the current page. The data needed for these so called "soft navigations" can be prefetched by the app outside of speculation rules, but they cannot be prerendered.

Speculation Rules can be used to prerender the application itself from a previous page. This can help offset some of the extra initial load costs some SPAs have. However, route changes within the app cannot be prerendered.

Debug speculation rules

See the dedicated post on debugging speculation rules , for new Chrome DevTools features to assist with viewing and debugging this new API.

Multiple speculation rules

Multiple speculation rules can also be added to the same page, and they append to the existing rules. Therefore, the following different ways all result in both one.html and two.html prerendering:

List of URLs:

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

Multiple speculationrules scripts:

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

Multiple lists within one set of speculationrules

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

No-Vary-Search support

When prefetching or prerendering a page, certain URL parameters (technically known as search parameters ) may be unimportant to the page actually delivered by the server, and only used by client side JavaScript.

For example, UTM parameters are used by Google Analytics for campaign measurement, but usually don't result in different pages being delivered from the server. This means that page1.html?utm_content=123 and page1.html?utm_content=456 will deliver the same page from the server, so the same page can be reused from the cache.

Similarly, applications may use other URL parameters that are only handled client side.

The No-Vary-Search proposal allows a server to specify parameters that don't result in a difference to the resource delivered, and therefore allow a browser to reuse previously cached versions of a document which only differ by these parameters. This is supported in Chrome (and Chromium-based browsers) for navigation speculations for both prefetch and prerender.

Speculation rules support using expects_no_vary_search to indicate where a No-Vary-Search HTTP header is expected to be returned. Doing so can help further avoid unnecessary downloads.

<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>

In this example, the /products initial page HTML is the same for both product IDs 123 and 124 . However, the page contents eventually differ based on client-side rendering using JavaScript to fetch product data using the id search parameter. So we prefetch that URL eagerly and it should return a No-Vary-Search HTTP header showing the page can be used for any id search param.

However, if the user clicks on any of the links before the prefetch has completed, the browser may not have received the /products page. In this case, the browser does not know if it will contain the No-Vary-Search HTTP header. The browser is then left with a choice of whether to fetch the link again, or wait for the prefetch to complete to see if it contains a No-Vary-Search HTTP header. The expects_no_vary_search setting allows the browser to know the page response is expected to contain a No-Vary-Search HTTP header, and to wait for that prefetch to complete.

Speculation rules restrictions and future enhancements

Speculation rules are restricted to pages opened within the same tab, but we are working to reduce that restriction .

By default speculations are restricted to same-origin pages. Speculation same-site cross-origin pages (for example, https://a.example.com could prerender a page on https://b.example.com ). To use this the speculated page ( https://b.example.com in this example) needs to opt-in by including a Supports-Loading-Mode: credentialed-prerender HTTP header or Chrome will cancel the speculation.

Future versions may also allow prerender for non-same-site, cross-origin pages as long as cookies don't exist for the prerendered page and the prerendered page opts in with a similar Supports-Loading-Mode: uncredentialed-prerender HTTP header.

Speculation rules do already support cross-origin prefetches, but again only when cookies for the cross-origin domain don't exist. If cookies exist from the user having visited that site before, then the speculation won't be triggered and will show a failure in DevTools.

Given those current limitations, one pattern that can improve your users experiences for both internal links and external links where possible is to prerender same-origin URLs and attempt to prefetch cross-origin URLs:

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

The restriction to prevent cross-origin speculations for cross-origin links by default is necessary for security. It is an improvement over <link rel="prefetch"> for cross-origin destinations which will also not send cookies but still attempt the prefetch—which will be either result in a wasted prefetch that needs to be resent or, worse still, the incorrect page loading.

Speculation rules are not supported for prefetch for pages controlled by service workers. We are working to add this support. Follow this Support service worker issue for updates. Prerender is supported for service worker-controlled pages.

Detect Speculation Rules API support

You can feature detect Speculation Rules API support with standard HTML checks:

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

Add speculation rules dynamically through JavaScript

This is an example of adding a prerender speculation rule with JavaScript:

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);
}

You can view a demo of Speculation Rules API prerendering, using JavaScript insertion, on this prerender demo page .

Inserting a <script type = "speculationrules"> element directly into the DOM using innerHTML won't register the speculation rules for security reasons and this must be added as shown previously. However content inserted dynamically using innerHTML which contains new links, will be picked up by existing rules on the page.

Similarly, direct editing the Elements panel in Chrome DevTools to add the <script type = "speculationrules"> element does not register the speculation rules and instead the script to dynamically add this to the DOM must be run from the Console to insert the rules.

Add speculation rules through a tag manager

To add speculation rules using a tag manager like Google Tag Manager (GTM) requires these to be inserted through JavaScript, rather than adding the <script type = "speculationrules"> element though GTM directly for the same reasons as mentioned previously:

Note this example uses var as GTM does not support const .

Cancel speculation rules

Removing speculation rules will result in the prerender being cancelled but, by the time this has happened, resources will likely have already been spent to initiate the prerender, so it is recommended not to prerender if there is a likelihood of needing to cancel the prerender.

Speculation rules and Content Security Policy

As speculation rules use a <script> element, even though they only contain JSON, they need to be included in the script-src Content-Security-Policy if the site uses this—either using a hash or nonce.

A new inline-speculation-rules can be added to script-src allowing <script type="speculationrules"> elements injected from hash or nonced scripts to be supported. This does not support rules included in the initial HTML so rules need to be injected by JavaScript for sites that use a strict CSP.

Detect and disable prerendering

Prerender is usually a positive experience for users as it allows fast page rendering—often instant. This benefits both the user, and the site owner, since prerendered pages allow a better user experience that may be difficult to achieve otherwise.

However, there may be instances when you don't want prerendering of pages to happen , for example when pages change state—either based on the initial request, or based on JavaScript executing on the page.

Enable and disable prerender in Chrome

Prerender is only enabled for those Chrome users with the "Preload pages" setting in chrome://settings/performance/ . Additionally, prerender is also disabled on low-memory devices, or if the operating system is in Save-data or Energy saver modes. See the Chrome limits section.

Detect and disable prerender server-side

Prerendered pages will be sent with the Sec-Purpose HTTP header:

Sec-Purpose: prefetch;prerender

Prefetched pages using the Speculation Rules API will have this header set to just prefetch :

Sec-Purpose: prefetch

Servers can respond based on this header, to log speculation requests, return different content, or prevent a prerender from happening. If a non-success final response code is returned—that is, not in the 200-299 range after redirects—then the page won't be prerendered and any prefetch page will be discarded. Note also that 204 and 205 responses are additionally not valid for prerendering , but are valid for prefetch.

If you don't want a particular page to be prerendered, returning a non-2XX response code (such as 503) is the best way to ensure it won't happen. However, to deliver the best experience, it is recommended to instead allow prerendering, but delay any actions that should only happen then the page is actually viewed, using JavaScript.

Detect prerender in JavaScript

The document.prerendering API will return true while the page is prerendering. This can be used by pages to prevent—or delay—certain activities during the prerender until the page is actually activated.

Once a prerendered document is activated, PerformanceNavigationTiming 's activationStart will also be set to a non-zero time representing the time between when the prerender was started and the document was actually activated.

You can have a function to check for prerendering and prerendered pages like the following:

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

The easiest way to see if a page was prerendered (either in full or partially) is to open DevTools after the page is activated and type performance.getEntriesByType('navigation')[0].activationStart in the console. If a non-zero value is returned, you know the page was prerendered:

When the page is activated by the user viewing the page, the prerenderingchange event will be dispatched on the document , which can then be used to enable activities that previously would be started by default on page load but which you want to delay until the page is actually viewed by the user.

Using these APIs, frontend JavaScript can detect and act upon prerendered pages appropriately.

Impact on analytics

Analytics are used to measure website usage, for example using Google Analytics to measure page views, and events. Or by measuring performance metrics of pages using Real User Monitoring (RUM) .

Pages should only be prerendered when there is a high probability the page will be loaded by the user. This is why the Chrome address bar prerendering options only happen when there is such a high probability (greater than 80% of the time).

However—particularly when using the Speculation Rules API—prerendered pages may have an impact on analytics and site owners may need to add extra code to only enable analytics for prerendered pages on activation, as not all analytics providers may do this by default.

This could be achieved by using a Promise which waits for the prerenderingchange event if a document is prerendering, or resolves immediately if it is now:

// 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();

An alternative approach is to delay analytic activities until the page is first made visible, which would cover both the prerendering case, and also when tabs are opened in the background (for example, with right-click and open in new tab):

// 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();

While this may make sense for analytics and similar use cases, in other cases you may want more content loaded for those cases, and so may want to use document.prerendering and prerenderingchange to specifically target prerendering pages.

Hold back other content during prerendering

The same APIs discussed previously can be used to hold back other content during the prerender phase. This can be specific parts of JavaScript or whole script elements that you would prefer not to run during the prerender stage.

For example, given this script:

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

You can change this to a dynamically inserted script element which only inserts based on the previous whenActivated function:

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');

This can be useful to hold back distinct scripts that include analytics, or render content based on state or other variables that can change during the span of a visit. For example, recommendations, or login state, or shopping basket icons could all be held back to ensure the most up to date information is presented.

While this is perhaps more likely to happen more often with the use of prerendering, these conditions are also true for pages loaded in background tabs mentioned previously (so the whenFirstVisible function could be used in place of whenActivated ).

In many cases state should ideally also be checked on general visibilitychange changes—for example, when returning to a page that has been background, any shopping basket counters should be updated with the latest number of items in the basket. So this is not a prerender-specific problem but prerender is just making an existing issue more obvious.

One way that Chrome mitigates some of the need for manually wrapping scripts or functions, is that certain APIs are held back as mentioned previously , and also third-party iframes are not rendered, so it's only content on top of this that is required to be manually held back.

عملکرد را اندازه گیری کنید

For measuring performance metrics, analytics should consider whether it is better to measure these based upon the activation time rather than the page load time that browser APIs will report.

For Core Web Vitals, measured by Chrome through the Chrome User Experience Report , these are intended to measure the user experience. So these are measured based on activation time. This will often result in a 0 second LCP for example, showing this is great way of improving your Core Web Vitals.

From version 3.1.0, the web-vitals library has been updated to handle prerendered navigations in the same way Chrome measures Core Web Vitals. This version also flags prerendered navigations for those metrics in the Metric.navigationType attribute if the page was fully or partially prerendered.

Measure prerenders

Whether a page is prerendered can be seen with a non-zero activationStart entry of PerformanceNavigationTiming . This can then be logged using a Custom Dimension, or similar when logging the page views, for example using the pagePrerendered function described previously :

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

This will allow your analytics to show how many navigation are prerendered compared to other types of navigation, and also allow you to correlation any performance metrics or business metrics to these different navigation types. Faster pages means happier users, which can often have real impact on business measures as our case studies show.

As you measure the business impact of prerendering pages for instant navigations, you can decide whether it is worth investing more effort in using this technology to allow more navigations to be prerendered, or to investigate why pages are not being prerendered.

Measure hit rates

In addition to measuring the impact of pages that are visited after a prerender, it is also important to measure pages that are prerendered and not subsequently visited. This could imply you are prerendering too much, and using up valuable resources of the user for little benefit.

This can be measured by firing an analytics event when speculation rules are inserted—after checking the browser supports prerendering using HTMLScriptElement.supports('speculationrules') —to indicate that prerender was requested. (Note that just because a prerender was requested, does not indicate that a prerender was started or completed as, as noted previously, a prerender is a hint to the browser and it may choose not to prerender pages on user settings, current memory usage, or other heuristics.)

You can then compare the number of these events, to the actual prerender page views. Or alternatively fire another event on activation if that makes it easier to compare.

The "successful hit rate" can then be approximated by looking at the difference between these two figures. For pages where you are using the Speculation Rules API to prerender the pages, you can adjust the rules appropriately to ensure you keep a high hit rate to maintain the balance between using up the users resources to help them, versus using it needlessly.

Be aware that some prerendering may be taking place due to the address bar prerendering and not just your speculation rules. You can check the document.referrer (which will be blank for address bar navigation including prerendered address bar navigations) if you want to differentiate these.

Remember to also look at pages which have no prerenders, as that could indicate these pages are not eligible for prerendering, even from the address bar. That may mean you are not benefiting from this performance enhancement. The Chrome team is looking to add extra tooling to test for Prerender eligibility perhaps similar to the bfcache testing tool , and also potentially add an API to expose why a prerender failed.

Impact on extensions

See the dedicated post on Chrome Extensions: Extending API to support Instant Navigation which details some additional considerations extension authors may need to think about for prerendered pages.

بازخورد

Prerendering is in active development by the Chrome team, and there are plenty of plans to expand the scope of what has been made available in the Chrome 108 release. We welcome any feedback on the GitHub repo or using our issue tracker , and look forward to hearing and sharing case studies of this exciting new API.

لینک های مرتبط

• Speculation Rules Codelab
• اشکال زدایی قوانین حدس و گمان
• Introducing NoState Prefetch
• Speculation Rules API specification
• The Navigational speculation GitHub repo
• Chrome Extensions: Extending API to support Instant Navigation

قدردانی ها

Thumbnail image by Marc-Olivier Jodoin on Unsplash