این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

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

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

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

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

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

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

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

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

نمونه ای از تاثیر پیش اجرا.

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

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

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

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

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

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

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

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

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

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

ویژگی «Typeahead» نوار آدرس Chrome — ویژگی «Typeahead» نوار آدرس.

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>

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

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

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

اشتیاق	واکشی از پیش	پیش اجرا
`immediate` / `eager`	50	10
`moderate` / `conservative`	2 (FIFO)	2 (FIFO)

محدودیت حدس و گمان در کروم

تنظیمات 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"> مستقیماً به همان دلایلی که قبلاً ذکر شد، باید آنها را از طریق جاوا اسکریپت درج کنید:

پیکربندی تگ HTML سفارشی در Google Tag Manager — افزودن قوانین حدس و گمان از طریق Google Tag Manager.

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

کنسول در Chrome DevTools فعال سازی مثبت را نشان می دهد. شروع نشان می دهد صفحه از قبل اجرا شده است — آزمایش پیش اجرا در کنسول.

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

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

هشدار: PerformanceNavigationTiming.type از مقدار prerender ، که برای نوع پیمایش <link rel="prerender"...> قدیمی تر و اصلی بود، استفاده نمی کند. این ممکن است در آینده تغییر کند، اما در حال حاضر، مشتریان باید از document.prerendering API برای شناسایی صفحات پیش اجرا و یک فیلد غیر صفر PerformanceNavigationTiming.activationStart برای شناسایی صفحات از قبل اجرا شده که از آن زمان فعال شده اند استفاده کنند.

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

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

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

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

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

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

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

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

بازخورد

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

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

قدردانی

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

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

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

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

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

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

Speculation Rules API

اشتیاق

واکشی از پیش

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

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

هدر Speculation-Rules HTTP

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

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

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

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

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

پشتیبانی از API قوانین گمانه زنی

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

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

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

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

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

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

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

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

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

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

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

پیش اجراها را اندازه گیری کنید

نرخ ضربه را اندازه گیری کنید

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

بازخورد

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

قدردانی

هدر `Speculation-Rules` HTTP

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