راهنمای اجرای قوانین حدس و گمان برای سایت های پیچیده تر، راهنمای اجرای قوانین حدس و گمان برای سایت های پیچیده تر

Barry Pollard

تاریخ انتشار: 07 مارس 2025

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

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

برنامه ریزی

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

تصمیم بگیرید که چگونه قوانین حدس و گمان را اجرا کنید

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

• مستقیماً در HTML صفحه
• با استفاده از جاوا اسکریپت
• استفاده از هدر HTTP

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

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

قوانین حدس و گمان را مستقیماً در HTML صفحه قرار دهید

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

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

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "selector_matches": ".prerender" }
    }],
    "prefetch": [{
      "where": { "selector_matches": ".prefetch" }
    }]
  }
</script>

اسکریپت قبلی پیوندها را با یک کلاس prerender اجرا می‌کند، و به‌طور مشابه زمانی که یک پیوند دارای کلاس prefetch باشد، پیش‌اجرا می‌شود. این به توسعه دهندگان این امکان را می دهد که این کلاس ها را در HTML بگنجانند تا حدس و گمان را راه بیندازند.

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

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

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

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

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

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

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

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

گزینه نهایی برای توسعه دهندگان این است که قوانین را با استفاده از هدر HTTP اضافه کنند:

Speculation-Rules: "/speculationrules.json"

برخی الزامات اضافی برای نحوه تحویل و استفاده از منبع قوانین ( /speculationrules.json در این مثال) وجود دارد.

این گزینه امکان استقرار آسان تر توسط CDN ها را بدون نیاز به تغییر محتوای سند فراهم می کند. این بدان معناست که تغییر قوانین حدس و گمان به صورت پویا با استفاده از جاوا اسکریپت یک گزینه نیست. با این حال، قوانین سند با راه‌اندازهای انتخابگر CSS همچنان می‌توانند تغییرات پویا را مجاز کنند - به عنوان مثال، با حذف کلاس prerender از یک پیوند.

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

پیامدهای هزینه را در نظر بگیرید

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

هزینه را برای کاربران در نظر بگیرید

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

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

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

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

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

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

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

بار اضافی اضافی را در نظر بگیرید

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

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

اطمینان از اینکه صفحات و منابع شما قابل کش هستند، میزان بارگذاری مبدا و در نتیجه ریسک کلی را به میزان قابل توجهی کاهش می دهد. هنگامی که با CDN همراه می شود، سرورهای مبدأ شما باید حداقل بار اضافی را ببینند - اگرچه هر گونه افزایش هزینه CDN را در نظر بگیرید.

یک سرور یا CDN همچنین می تواند برای کنترل نتایج حدس و گمان که توسط هدر HTTP هدف دوم شناسایی می شود استفاده شود. به عنوان مثال، محصول Speed ​​Brain Cloudflare فقط به گمانه‌زنی‌هایی اجازه می‌دهد که قبلاً در سرور لبه CDN ذخیره شده‌اند و درخواست‌ها را به مبدا ارسال نمی‌کنند.

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

تعادل بین حدس و گمان زیاد یا خیلی کم پیدا کنید

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

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

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

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

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

با واکشی اولیه شروع کنید

Prefetch معمولاً برای اکثر سایت ها نسبتاً ایمن است و این رویکرد اولیه ای است که بسیاری از آنها از جمله انتشار در مقیاس بزرگ مانند Cloudflare و WordPress اتخاذ کرده اند.

مسائل اصلی که باید از آنها آگاه بود این است که اگر واکشی از قبل URL باعث تغییر حالت و هزینه های سمت سرور، به ویژه برای صفحات غیرقابل ذخیره می شود. تغییرات حالت ایده‌آل - به عنوان مثال، واکشی از قبل یک صفحه /logout نباید به عنوان پیوندهای GET پیاده‌سازی شوند، اما متأسفانه این امر در وب غیر معمول نیست.

چنین URL هایی می توانند به طور خاص از قوانین مستثنی شوند:

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

واکشی‌های اولیه را می‌توان به پیمایش‌های رایج از یک صفحه به صفحه دیگر یا برای همه پیوندهای با مبدأ یکسان با استفاده از تنظیم eagerness moderate ​​یا conservative در نشانگر شناور یا کلیک کردن محدود کرد. تنظیم conservative کمترین خطر را دارد، اما کمترین پاداش بالقوه را نیز به همراه دارد. اگر از آنجا شروع کنید، حداقل به moderate ​​پیش بروید، اما در حالت ایده‌آل فراتر از این برای eager ، مزایای عملکرد بیشتری را به همراه خواهد داشت (و سپس ارتقاء بیشتر به prerender در جایی که منطقی است).

پیش اجراهای کم خطر

استقرار گمانه‌زنی‌های Prefetch آسان‌تر است، اما مزیت عملکرد نهایی برای API، اجرای پیش‌فرض است. این می تواند برخی ملاحظات اضافی داشته باشد، زمانی که صفحه در مدت کوتاهی پس از حدس و گمان بازدید نمی شود (که در بخش بعدی به آن خواهیم پرداخت)، اما با یک پیش اجرا moderate ​​یا conservative ، جایی که ناوبری احتمالاً کمی بعد انجام می شود، ممکن است مرحله بعدی نسبتاً کم خطر باشد.

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

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

یکی از تاکتیک‌های رایج این است که تعداد کمتری از صفحات بعدی که مکرراً بازدید می‌شوند در بارگذاری با تنظیمات eager (یا با مشخص کردن آنها در فهرست URL یا با استفاده از selector_matches ) و سپس اجرای اولیه با یک تنظیم moderate ​​است. از آنجایی که احتمالاً واکشی اولیه HTML تا زمانی که پیوند نشان داده می‌شود تکمیل شده باشد، این امر باعث افزایش پیش‌پرداخت در شناور بدون واکشی اولیه می‌شود.

<script type="speculationrules">
  {
    "prefetch": [{
      "urls": ["next.html", "next2.html"],
      "eagerness": "eager"
    }],
    "prerender": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

پیش رندرهای قبلی

در حالی که قوانین سند moderate ​​امکان استفاده نسبتاً کم خطر از API را با سهولت پیاده سازی مرتبط فراهم می کند، این اغلب زمان کافی برای پیش اجرا کامل نیست. برای دستیابی به ناوبری های فوری که این API اجازه می دهد، احتمالاً باید فراتر از آن بروید و صفحات را با اشتیاق بیشتری پیش اجرا کنید.

این امر با فهرست ایستا از URLها (مانند نمونه پیش واکشی قبلی) یا با selector_matches که تعداد کمی از URLها را شناسایی می کند (به طور ایده آل یک یا دو صفحه) به دست می آید، با قوانین سند که سایر URL ها را پوشش می دهد:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "selector_matches": : ".prerender"
        },
        "eagerness": "eager",
      },
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": {"href_matches": "/logout"}}
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

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

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

تجزیه و تحلیل، تبلیغات و جاوا اسکریپت

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

برخی از ارائه دهندگان تجزیه و تحلیل (مانند Google Analytics) و ارائه دهندگان تبلیغات (مانند Google Publisher Tag) قبلاً از قوانین حدس و گمان پشتیبانی می کنند و تا زمانی که صفحه فعال نشود، بازدیدها را ثبت نمی کنند. با این حال، سایر ارائه دهندگان یا تجزیه و تحلیل های سفارشی که پیاده سازی کرده اید، ممکن است نیاز به توجه بیشتری داشته باشند.

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

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

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

علاوه بر این، اگر هر محتوایی به جاوا اسکریپت بستگی دارد (مثلاً محتوای رندر شده توسط مشتری)، تأخیر در این امر تأثیر مثبتی را که اجرای پیش‌اجرا می‌تواند به همراه داشته باشد، بر LCP و CLS کاهش می‌دهد. یک رویکرد هدفمندتر برای اجرای بیشتر جاوا اسکریپت در مرحله پیش رندر منجر به تجربه بهتری می شود، اما ممکن است اجرای آن کمتر بی اهمیت باشد.

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

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

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

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

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

Broadcast Channel API یکی از راه‌هایی است که به یک صفحه در مرورگر اجازه می‌دهد به‌روزرسانی‌هایی مانند این را برای صفحات دیگر پخش کند. با این کار مشکل چندین تب نیز حل می شود. صفحات از قبل اجرا شده می توانند به پیام پخش گوش دهند - اگرچه تا زمانی که فعال نشده باشند نمی توانند پیام های پخش خود را ارسال کنند.

از طرف دیگر، صفحات از قبل اجرا شده می‌توانند با استفاده از سرور (با استفاده از fetch() دوره‌ای، یا اتصال WebSocket ) به‌روزرسانی دریافت کنند، اما با احتمال تاخیر در به‌روزرسانی.

گمانه زنی های پیش اجرا را لغو یا تازه کنید

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

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

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

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

async function refreshSpeculations() {
  const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');

  for (const speculationScript of speculationScripts) {
    // Get the current rules as JSON text
    const ruleSet = speculationScript.textContent;

    // Remove the existing script to reset prerendering
    speculationScript.remove();
    
    // Await for a microtask before re-inserting.
    await Promise.resolve();

    // Reinsert rule in a new speculation rules script
    const newScript = document.createElement('script');
    newScript.type = 'speculationrules';
    newScript.textContent = ruleSet;
    console.log(newScript);

    // Append the new script back to the document
    document.body.appendChild(newScript);
  }
}

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

این گزینه refresh به قوانین درج شده با جاوا اسکریپت محدود نمی شود. قوانین استاتیک موجود در HTML را نیز می توان به همان روش حذف یا تغییر داد، زیرا این یک تغییر استاندارد DOM است. قوانین حدس و گمان HTTP را نمی توان حذف کرد، اما معیارهای تطبیق (به عنوان مثال، کلاس های prerender ) را می توان حذف کرد و دوباره توسط جاوا اسکریپت اضافه کرد.

کروم همچنین به دنبال افزودن پشتیبانی Clear-Site-Header است تا به پاسخ‌های سرور اجازه دهد پیش‌اجراها را لغو کنند (مثلاً وقتی درخواست سبد به‌روزرسانی انجام می‌شود).

اندازه گیری تاثیر

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

هنگام پیاده سازی با چند مرحله (پیش واکشی، پیش اجراهای کم خطر و سپس پیش اجراهای اولیه) باید با هر مرحله اندازه گیری کنید.

چگونه موفقیت را اندازه گیری کنیم

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

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

نحوه اندازه گیری میزان مصرف و هدر رفتن

یکی دیگر از ملاحظات کلیدی این است که اندازه گیری کنید که آیا در صفحات صحیح حدس می زنید یا خیر. این کار هم از هدر رفتن جلوگیری می کند و هم تضمین می کند که بهترین صفحات را برای به دست آوردن از این API هدف قرار می دهید.

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

if (document.prerendering) {
  console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
  console.log("Page has already prerendered");
} else {
  console.log("This page load was not using prerendering");
}

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

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

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

نتیجه گیری

قوانین حدس و گمان امکان افزایش عملکرد چشمگیر را در عملکرد صفحه شما فراهم می کند. این راهنما توصیه هایی را در مورد ملاحظات در هنگام اجرای این API ارائه می دهد تا از هر گونه مشکل احتمالی جلوگیری شود و همچنین بیشترین بهره را از API ببرید.

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