Speculative Loading در وردپرس چیست؟ آموزش تنظیم Prefetch و Prerender برای باز شدن سریع‌تر صفحات

از WordPress 6.8 به بعد، وردپرس یک قابلیت مهم برای سریع‌تر شدن جابه‌جایی بین صفحات سایت دارد: Speculative Loading یا «بارگذاری پیش‌دستانه». ایده ساده است؛ مرورگر قبل از اینکه کاربر واقعاً وارد صفحه بعدی شود، با توجه به قوانین مشخص بخشی از کار بارگذاری آن صفحه را زودتر انجام می‌دهد. در نتیجه وقتی کاربر روی لینک کلیک می‌کند، صفحه مقصد می‌تواند سریع‌تر و در بعضی شرایط تقریباً فوری نمایش داده شود.

این قابلیت با Speculation Rules API مرورگر کار می‌کند و 2 حالت اصلی دارد: Prefetch و Prerender. Prefetch فقط سند صفحه بعدی را زودتر دریافت می‌کند، اما Prerender یک قدم جلوتر می‌رود و صفحه مقصد را در پس‌زمینه بارگذاری و رندر می‌کند؛ حتی JavaScript و زیرمنابع آن نیز می‌توانند اجرا یا دریافت شوند.

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

در این آموزش ابتدا تفاوت Prefetch، Prerender، Preload و Lazy Load را روشن می‌کنیم؛ سپس رفتار پیش‌فرض وردپرس را بررسی می‌کنیم، نحوه تغییر حالت و میزان حساسیت را با کد و افزونه رسمی توضیح می‌دهیم، مسیرهای حساس را از بارگذاری پیش‌دستانه خارج می‌کنیم و در پایان با Chrome DevTools مطمئن می‌شویم قابلیت واقعاً کار می‌کند.

اگر هنوز مشکلات عمومی سرعت سایت را بررسی نکرده‌اید، پیشنهاد می‌کنیم در کنار این راهنما مقاله افزایش سرعت سایت وردپرسی را هم مطالعه کنید. Speculative Loading فقط سرعت ناوبری بعدی را هدف می‌گیرد و جای کش، بهینه‌سازی تصویر، PHP مناسب یا هاست سریع را نمی‌گیرد.

Speculative Loading چیست؟

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

در روش جدید، سایت یک مجموعه قانون در اختیار مرورگر قرار می‌دهد. مرورگر نیز براساس آن قانون و شرایط دستگاه تصمیم می‌گیرد آیا درخواست زودهنگام را انجام بدهد یا نه. بنابراین سایت «دستور قطعی» صادر نمی‌کند؛ Speculation Rules در عمل یک راهنمای عملکردی برای مرورگر است و مرورگر می‌تواند به‌دلیل محدودیت حافظه، Data Saver، Battery Saver یا شرایط دیگر از اجرای آن صرف‌نظر کند.

در وردپرس، این قوانین در خروجی HTML به‌شکل یک اسکریپت JSON با نوع speculationrules چاپ می‌شوند. نمونه ساده مفهومی:

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

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

Speculative Loading از چه نسخه‌ای وارد هسته وردپرس شد؟

قابلیت Speculative Loading در WordPress 6.8 وارد هسته شد. پیش از آن، تیم Performance وردپرس آن را از طریق افزونه آزمایشی و رسمی Speculative Loading بررسی می‌کرد. داده‌های منتشرشده توسط تیم Core نشان داد سایت‌هایی که این قابلیت را از طریق افزونه فعال کرده بودند، در سطح مجموعه داده CrUX و HTTP Archive به‌طور میانه حدود 1.9% افزایش در نرخ قبولی LCP داشتند.

این عدد را نباید به‌عنوان وعده «1.9% سریع‌تر شدن سایت شما» تفسیر کرد. داده مربوط به مجموعه بزرگی از سایت‌ها و نرخ قبولی LCP بوده است. میزان اثر واقعی روی هر سایت به سرعت سرور، ساختار صفحات، نرخ کلیک روی لینک‌ها، کش، اندازه صفحات و نوع تنظیم Prefetch یا Prerender بستگی دارد.

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

رفتار پیش‌فرض Speculative Loading در WordPress 6.8 و نسخه‌های جدیدتر

در حالت پیش‌فرض، WordPress Core از ترکیب زیر استفاده می‌کند:

• Mode: prefetch
• Eagerness: conservative
• کاربران هدف: کاربران خارج‌شده از حساب
• شرط پیوند یکتا: Pretty Permalinks باید فعال باشد

در حالت conservative، مرورگر زمانی شروع به Prefetch می‌کند که کاربر عملاً در حال فعال کردن لینک است؛ مثلاً هنگام pointer down یا لمس اولیه. زمان جلو افتادن ممکن است فقط کسری از ثانیه باشد، اما چون سند صفحه مقصد زودتر در اختیار مرورگر قرار می‌گیرد، همین فاصله کوتاه می‌تواند ناوبری را سریع‌تر کند.

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

تفاوت Prefetch و Prerender چیست؟

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

Prefetch دقیقاً چه چیزی را دانلود می‌کند؟

در Speculation Rules API، Prefetch برای ناوبری صفحه طراحی شده است. مرورگر سند HTML مقصد را دریافت می‌کند، اما زیرمنابع آن صفحه مثل CSS، تصویر و JavaScript را به‌طور کامل مثل Prerender بارگذاری و اجرا نمی‌کند.

این موضوع با <link rel="prefetch"> قدیمی تفاوت دارد. MDN و Chrome برای Prefetch کردن سندِ ناوبری آینده، استفاده از Speculation Rules را ترجیح می‌دهند؛ در حالی که rel="prefetch" همچنان می‌تواند برای بعضی زیرمنابع کاربرد داشته باشد.

Prerender دقیقاً چه کاری انجام می‌دهد؟

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

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

تفاوت Speculative Loading با Preload و Lazy Load

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

پس Preload و Lazy Load عمدتاً به منابع صفحه فعلی مربوط‌اند، در حالی که Speculative Loading برای ناوبری احتمالی بعدی طراحی شده است.

Eagerness در Speculative Loading یعنی چه؟

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

در WordPress Core، تنظیم عمومی wp_speculation_rules_configuration برای Eagerness از conservative، moderate و eager پشتیبانی می‌کند. مقدار immediate برای Rule عمومی مبتنی بر تمام لینک‌های سند عمداً در این تنظیم در دسترس نیست، چون برای چنین کاربرد گسترده‌ای بیش از حد تهاجمی است.

چرا وردپرس Prefetch + Conservative را پیش‌فرض انتخاب کرده است؟

اگر WordPress از همان ابتدا تمام لینک‌ها را با Prerender و Eager آماده می‌کرد، روی میلیون‌ها سایت ممکن بود ترافیک و پردازش زیادی ایجاد شود. تنظیم پیش‌فرض Core باید برای طیف وسیعی از سایت‌ها کم‌ریسک باشد.

ترکیب prefetch + conservative چند مزیت دارد:

• فقط زمانی اجرا می‌شود که احتمال Navigation بسیار بالاست؛
• هزینه شبکه و حافظه کمتر از Prerender است؛
• JavaScript صفحه مقصد قبل از ورود واقعی کاربر اجرا نمی‌شود؛
• ریسک ثبت اشتباه Analytics یا اجرای رفتار Client-side کمتر است؛
• برای هاست‌های محدود نیز محافظه‌کارانه‌تر است.

اگر سایت سریع، Cache مناسب و مسیرهای قابل پیش‌بینی دارد، می‌توان بعد از تست سراغ moderate یا Prerender رفت.

چگونه بفهمیم Speculative Loading در وردپرس فعال است؟

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

در انتهای صفحه باید کدی با این الگو پیدا شود:

<script type="speculationrules">
...
</script>

خروجی واقعی Core شامل Ruleهایی برای مستثنا کردن مسیرهای داخلی و لینک‌های خاص است. اگر چیزی پیدا نکردید، این موارد را بررسی کنید:

• نسخه وردپرس حداقل 6.8 باشد؛
• از حساب کاربری خارج شده باشید؛
• پیوند یکتای زیبا فعال باشد؛
• قالب شما wp_footer() را درست فراخوانی کند؛
• افزونه یا کد دیگری Speculative Loading را غیرفعال نکرده باشد.

وردپرس کدام لینک‌ها و مسیرها را به‌صورت پیش‌فرض مستثنا می‌کند؟

هسته WordPress فقط یک Rule ساده «همه لینک‌ها» تولید نمی‌کند. چند دسته از URLها از Speculative Loading کنار گذاشته می‌شوند تا ریسک عملکرد ناخواسته کمتر شود.

در پیاده‌سازی Core، مسیرهای داخلی حساس یا فایل‌ها مانند موارد زیر از Rule اصلی کنار گذاشته می‌شوند:

• /wp-*.php از جمله مسیرهایی مانند Login؛
• /wp-admin/*؛
• مسیر Uploadها؛
• فایل‌های داخل wp-content، Pluginها، قالب فعال و Stylesheet؛
• در سایت دارای Pretty Permalinks، URLهای دارای Query String؛
• لینک‌های دارای rel="nofollow"؛
• لینک‌ها یا بلوک‌هایی که با کلاس‌های مخصوص از Prefetch یا Prerender خارج شده‌اند.

این رفتار مهم است؛ چون بعضی افزونه‌ها هنوز از URLهای GET برای عملیاتی مثل افزودن به علاقه‌مندی یا تغییر وضعیت استفاده می‌کنند. چنین URLهایی نباید بدون Navigation واقعی کاربر زودتر فراخوانی شوند.

آموزش تغییر Eagerness از Conservative به Moderate

اگر سایت شما کش مناسب دارد و می‌خواهید Prefetch زودتر شروع شود، می‌توانید فقط Eagerness را تغییر دهید و Mode را همان Prefetch نگه دارید.

add_filter(
    'wp_speculation_rules_configuration',
    function ( $config ) {
        if ( is_array( $config ) ) {
            $config['eagerness'] = 'moderate';
        }
        return $config;
    }
);

این کد را بهتر است در افزونه اختصاصی کوچک یا ابزار امن مدیریت Snippet قرار دهید، نه اینکه برای چنین تغییر مستقیمی Child Theme را بدون نیاز درگیر کنید.

با moderate مرورگر فرصت بیشتری برای دریافت سند صفحه مقصد پیدا می‌کند. در دسکتاپ، مرورگرهای Chromium معمولاً با Hover معنادار روی لینک می‌توانند Speculation را شروع کنند. روی موبایل رفتار براساس Heuristicهای مرورگر متفاوت است و لزوماً معادل Hover نیست.

آموزش فعال کردن Prerender + Moderate در وردپرس

اگر پس از تست Prefetch می‌خواهید جابه‌جایی بین صفحات بسیار سریع‌تر شود، می‌توانید Mode را به Prerender تغییر دهید:

add_filter(
    'wp_speculation_rules_configuration',
    function ( $config ) {
        if ( is_array( $config ) ) {
            $config['mode']      = 'prerender';
            $config['eagerness'] = 'moderate';
        }
        return $config;
    }
);

این تنظیم شبیه رفتار پیش‌فرض افزونه رسمی Speculative Loading است. اما قبل از استفاده روی سایت اصلی باید چند مورد را بررسی کنید:

• Analytics و Tag Manager هنگام Prerender Page View اشتباه ثبت نکنند؛
• صفحه مقصد روی Load، State کاربر را بدون Navigation واقعی تغییر ندهد؛
• JavaScript شخصی‌سازی‌شده با Prerender سازگار باشد؛
• سرور ظرفیت درخواست‌های اضافه را داشته باشد؛
• صفحات سنگین و ویدئویی بی‌دلیل Prerender نشوند؛
• مسیرهای Checkout، Account و Action URLها تست شده باشند.

برای چنین تغییراتی، استفاده از یک محیط تست بسیار ارزشمند است. اگر هنوز نسخه آزمایشی ندارید، راهنمای ساخت Staging وردپرس را ببینید.

روش ساده‌تر: استفاده از افزونه رسمی Speculative Loading

اگر نمی‌خواهید با Filterهای وردپرس کار کنید، افزونه رسمی Speculative Loading که توسط WordPress Performance Team توسعه داده می‌شود، همچنان کاربرد دارد. قابلیت پایه این افزونه از WordPress 6.8 وارد Core شده، اما افزونه رابط گرافیکی و تنظیمات بیشتری در اختیار شما می‌گذارد.

در زمان نگارش این مقاله، نسخه 1.7.0 افزونه روی WordPress.org منتشر شده و حداقل WordPress 6.9 و PHP 7.4 می‌خواهد. این جزئیات ممکن است در نسخه‌های بعدی تغییر کنند، بنابراین قبل از نصب صفحه رسمی افزونه را بررسی کنید.

بعد از نصب و فعال‌سازی افزونه:

1. به تنظیمات ← خواندن بروید.
2. بخش Speculative Loading را پیدا کنید.
3. Mode را بین Prefetch و Prerender انتخاب کنید.
4. Eagerness مناسب را انتخاب کنید.
5. در صورت نیاز، رفتار کاربران واردشده را نیز کنترل کنید.

افزونه به‌صورت پیش‌فرض از Prerender + Moderate استفاده می‌کند؛ یعنی تنظیم آن از Core تهاجمی‌تر است و می‌تواند سود عملکردی بیشتری ایجاد کند، اما همان‌قدر هم به تست بیشتری نیاز دارد.

چگونه یک مسیر خاص را از Prefetch و Prerender خارج کنیم؟

اگر بخشی از سایت نباید زودتر بارگذاری شود، از Filter رسمی Core استفاده کنید. مثال زیر تمام URLهای زیر /cart/ را خارج می‌کند:

add_filter(
    'wp_speculation_rules_href_exclude_paths',
    function ( $exclude_paths ) {
        $exclude_paths[] = '/cart/*';
        return $exclude_paths;
    }
);

مسیرها باید با / شروع شوند و می‌توانید از * به‌عنوان Wildcard استفاده کنید. اگر WordPress داخل Subdirectory نصب شده باشد، Core Prefix لازم را مدیریت می‌کند.

فقط Prerender را غیرفعال کنیم، اما Prefetch باقی بماند

برای بعضی صفحات، Prefetch امن است ولی Prerender به‌دلیل اجرای JavaScript مناسب نیست. در این حالت پارامتر $mode را بررسی کنید:

add_filter(
    'wp_speculation_rules_href_exclude_paths',
    function ( $exclude_paths, $mode ) {
        if ( 'prerender' === $mode ) {
            $exclude_paths[] = '/personalized-area/*';
        }
        return $exclude_paths;
    },
    10,
    2
);

در این مثال صفحات بخش personalized-area هنوز می‌توانند Prefetch شوند، اما Prerender نخواهند شد.

کلاس‌های no-prefetch و no-prerender در وردپرس

WordPress Core یک روش ساده برای خارج کردن لینک یا بلوک خاص از Speculative Loading دارد. اگر یک بلوک یا لینک کلاس no-prefetch داشته باشد، Prefetch و در عمل Prerender آن نیز انجام نمی‌شود.

<a class="no-prefetch" href="/sensitive-page/">Sensitive page</a>

اگر فقط می‌خواهید Prerender غیرفعال شود ولی Prefetch مجاز بماند:

<a class="no-prerender" href="/dynamic-page/">Dynamic page</a>

در ویرایشگر بلوک نیز برای بسیاری از بلوک‌ها می‌توانید از بخش Advanced → Additional CSS class(es) این کلاس‌ها را اضافه کنید. اگر کلاس روی یک عنصر والد قرار بگیرد، لینک‌های داخل آن نیز می‌توانند تحت همان Exclusion قرار بگیرند.

آیا صفحات سبد خرید، Checkout و حساب کاربری را باید مستثنا کنیم؟

نسخه Core به‌طور پیش‌فرض URLهای دارای Query String را روی سایت‌های دارای Pretty Permalinks کنار می‌گذارد و بسیاری از مسیرهای حساس خود WordPress نیز از Rule حذف می‌شوند. اما این به معنی امن بودن خودکار تمام صفحات ووکامرس یا افزونه‌های دیگر نیست.

اگر سایت فروشگاهی دارید، به‌خصوص در صورت فعال کردن Prerender + Moderate/Eager، این صفحات را بررسی کنید:

• سبد خرید؛
• Checkout؛
• حساب کاربری؛
• ورود و خروج؛
• لینک‌های افزودن به سبد خرید مبتنی بر GET؛
• علاقه‌مندی یا مقایسه محصول؛
• لینک‌های دارای Nonce؛
• صفحات شخصی‌سازی‌شده براساس Cookie یا Session.

لازم نیست همه این مسیرها را بدون بررسی خارج کنید. ابتدا ببینید آیا صفحه فقط اطلاعات را نمایش می‌دهد یا در زمان Load واقعاً State کاربر را تغییر می‌دهد. Prefetch در بسیاری از موارد کم‌ریسک‌تر از Prerender است.

چرا WordPress برای کاربران واردشده Speculative Loading را غیرفعال می‌کند؟

صفحات کاربر واردشده معمولاً Cache عمومی ندارند و ممکن است برای هر درخواست PHP، دیتابیس و Session بیشتری مصرف کنند. اگر مرورگر قبل از هر Navigation چند صفحه را زودتر درخواست کند، این بار روی سایت‌هایی مثل فروشگاه، انجمن و سایت عضویتی قابل توجه می‌شود.

افزونه رسمی امکان Opt-in برای کاربران احراز هویت‌شده را فراهم کرده است، اما خود افزونه در نبود Persistent Object Cache هشدار می‌دهد. اگر کاربران واردشده زیادی دارید، قبل از فعال کردن این قابلیت برای آن‌ها این موارد را بسنجید:

• ظرفیت PHP Worker؛
• Object Cache مانند Redis یا Memcached؛
• زمان پاسخ صفحات Dynamic؛
• تعداد کاربران هم‌زمان؛
• هزینه Queryهای دیتابیس؛
• رفتار Session و شخصی‌سازی.

برای سایت عمومی محتوایی که بیشتر کاربران مهمان هستند، معمولاً نیازی نیست این محدودیت را تغییر دهید.

چرا Speculative Loading روی سایت بدون Pretty Permalinks غیرفعال است؟

وقتی Pretty Permalinks خاموش باشد، خود WordPress نیز برای مسیریابی از Query Parameter استفاده می‌کند. از طرف دیگر، افزونه‌ها هم ممکن است Query Parameterهایی برای عملیات مختلف داشته باشند. تشخیص اینکه کدام Query فقط Navigation عادی است و کدام Query باعث تغییر State می‌شود بسیار دشوارتر خواهد شد.

به همین دلیل Core در چنین سایتی Speculative Loading را به‌طور پیش‌فرض غیرفعال می‌کند. اگر ساختار URL قدیمی دارید، پیشنهاد بهتر این است که ابتدا دلیل استفاده نکردن از Pretty Permalinks را بررسی کنید، نه اینکه بدون تحلیل محدودیت Core را دور بزنید.

Prerender چه اثری روی Analytics و JavaScript دارد؟

این یکی از مهم‌ترین تفاوت‌های Prerender با Prefetch است. در Prerender، JavaScript صفحه مقصد می‌تواند قبل از اینکه کاربر واقعاً آن صفحه را ببیند اجرا شود. اگر اسکریپت شما روی Load عملی مانند ثبت Page View، Impression یا تغییر Local Storage انجام دهد، ممکن است رویداد زودتر از زمان واقعی ثبت شود.

برخی ابزارهای شناخته‌شده مانند Google Analytics برای Prerender سازگاری داخلی دارند و اجرای مربوط را تا Activation به تأخیر می‌اندازند، اما نمی‌توان همین فرض را برای همه سرویس‌ها یا کدهای اختصاصی داشت.

در JavaScript می‌توانید وضعیت Prerender را بررسی کنید:

function initAnalytics() {
    // Start analytics here.
}

if ( document.prerendering ) {
    document.addEventListener(
        'prerenderingchange',
        initAnalytics,
        { once: true }
    );
} else {
    initAnalytics();
}

در این نمونه اگر صفحه هنوز در حالت Prerender باشد، Analytics فقط وقتی شروع می‌شود که صفحه واقعاً برای کاربر فعال شود.

تأثیر Speculative Loading روی مصرف پهنای باند و سرور

هیچ بهینه‌سازی رایگان نیست. Prefetch و مخصوصاً Prerender درخواست‌هایی ایجاد می‌کنند که ممکن است در نهایت استفاده نشوند.

هزینه‌ها می‌توانند شامل این موارد باشند:

• ترافیک بیشتر سرور و CDN؛
• مصرف دیتای بیشتر برای کاربر؛
• مصرف حافظه و CPU مرورگر؛
• اجرای PHP بیشتر روی صفحات Cache نشده؛
• Query بیشتر برای صفحات Dynamic؛
• دانلود Resourceهایی که کاربر هرگز نمی‌بیند.

مرورگرهای پشتیبان خودشان محدودیت‌هایی برای تعداد Speculationهای هم‌زمان دارند و شرایطی مانند Data Saver یا کمبود حافظه می‌تواند اجرای Rule را متوقف کند. با این حال شما هم باید Strategy منطقی انتخاب کنید.

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

پشتیبانی مرورگرها از Speculation Rules API

این API هنوز از نظر MDN در گروه Limited Availability قرار دارد؛ یعنی نمی‌توان فرض کرد همه مرورگرهای پرکاربرد رفتار یکسانی دارند. مستندات فعلی افزونه WordPress، پشتیبانی کاربرد اصلی خود را برای مرورگرهای Chromium مانند Chrome، Edge و Opera از نسخه 121 به بالا ذکر می‌کند.

در مرورگرهایی که Rule را پشتیبانی نمی‌کنند، اسکریپت type="speculationrules" عملاً به‌عنوان یک Progressive Enhancement نادیده گرفته می‌شود و سایت باید مانند قبل کار کند. بنابراین نباید قابلیت حیاتی سایت را به اجرای Speculation Rules وابسته کنید.

چگونه Speculative Loading را با Chrome DevTools تست کنیم؟

Chrome ابزار اختصاصی برای بررسی Speculation Rules دارد. برای یک تست دقیق:

1. در حالت Incognito یا خارج‌شده از WordPress سایت را باز کنید.
2. DevTools را باز کنید.
3. به Application بروید.
4. در بخش Background services گزینه Speculative loads را انتخاب کنید.
5. صفحه را Reload کنید.
6. تب Rules را برای دیدن Ruleها بررسی کنید.
7. تب Speculations را باز کنید تا URL، Action و Status هر تلاش را ببینید.
8. روی یک لینک تعامل انجام دهید و ببینید Prefetch یا Prerender با موفقیت انجام شده یا نه.

اگر Rule شکست خورده باشد، DevTools در بسیاری از موارد Failure Reason را هم نمایش می‌دهد. این بخش برای فهمیدن اینکه چرا یک URL انتخاب نشده یا چرا Prerender لغو شده بسیار مفید است.

بررسی Prefetch در Network

برای Prefetch می‌توانید از Network هم استفاده کنید. درخواست Prefetch شده در Header درخواست معمولاً این مقدار را دارد:

Sec-Purpose: prefetch

در Prerender مقدار می‌تواند به‌شکل زیر باشد:

Sec-Purpose: prefetch;prerender

Prerender در Renderer جداگانه انجام می‌شود و ممکن است مثل Prefetch عادی در Network صفحه فعلی دیده نشود؛ به همین دلیل بخش Speculative loads ابزار قابل اتکاتری برای Debug آن است.

چگونه بفهمیم صفحه واقعاً Prerender شده است؟

بعد از ورود به صفحه مقصد، در Console می‌توانید مقدار زیر را بررسی کنید:

performance.getEntriesByType('navigation')[0]?.activationStart

اگر مقدار بزرگ‌تر از 0 باشد، صفحه قبل از Activation در حالت Prerender آماده شده است. برای تشخیص لحظه‌ای نیز document.prerendering در زمان Prerender مقدار true دارد.

چگونه Speculative Loading را در وردپرس غیرفعال کنیم؟

اگر بعد از تست متوجه شدید این قابلیت با ساختار سایت شما سازگار نیست، می‌توانید آن را برای درخواست‌های Frontend غیرفعال کنید:

add_filter(
    'wp_speculation_rules_configuration',
    function ( $config ) {
        return null;
    }
);

این کار باید آخرین انتخاب باشد. معمولاً بهتر است ابتدا مسیرهای مشکل‌دار را Exclude کنید یا تنظیم را از Prerender به Prefetch و از Moderate/Eager به Conservative برگردانید.

چگونه فقط چند URL مشخص را Prerender کنیم؟

برای سایت‌هایی که مسیر کاربر بسیار قابل پیش‌بینی است، می‌توانید به‌جای Prerender عمومی، فقط چند مقصد مشخص را زودتر آماده کنید. WordPress Core اکشن wp_load_speculation_rules را برای Ruleهای پیشرفته در اختیار توسعه‌دهندگان قرار می‌دهد.

نمونه زیر 2 مسیر مشخص را با prerender + moderate اضافه می‌کند:

add_action(
    'wp_load_speculation_rules',
    function ( WP_Speculation_Rules $speculation_rules ) {
        $speculation_rules->add_rule(
            'prerender',
            'hamyarwp-priority-pages',
            array(
                'source'    => 'list',
                'urls'      => array(
                    '/important-page/',
                    '/next-step/'
                ),
                'eagerness' => 'moderate',
            )
        );
    }
);

این روش برای Funnelهای مشخص یا مسیرهایی که داده واقعی Analytics نشان می‌دهد درصد زیادی از کاربران به آن‌ها می‌روند منطقی‌تر از Prerender گسترده است.

کدام تنظیم برای سایت من مناسب‌تر است؟

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

Speculative Loading چه اثری روی Core Web Vitals و LCP دارد؟

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

WordPress Performance Team در زمان ورود قابلیت به Core گزارش کرد که داده‌های سایت‌های استفاده‌کننده از افزونه، به‌طور میانه حدود 1.9% بهبود در نرخ قبولی LCP نشان داده‌اند. این آمار برای نشان دادن ظرفیت قابلیت مفید است، اما نباید از آن برای پیش‌بینی نتیجه یک سایت مشخص استفاده کرد.

Speculative Loading مشکل صفحه‌ای را که ذاتاً کند است اصلاح نمی‌کند. اگر Queryهای دیتابیس سنگین، CSS زیاد، JavaScript مسدودکننده یا تصویر LCP بسیار حجیم دارید، همان مشکلات همچنان وجود دارند؛ فقط ممکن است بخشی از کار زودتر انجام شود.

آیا Speculative Loading به سئو کمک می‌کند؟

این قابلیت را نباید یک فاکتور مستقیم رتبه‌بندی یا «ترفند سئو» معرفی کرد. اثر اصلی آن روی تجربه ناوبری و سرعت ادراک‌شده کاربر است. در صورت استفاده درست، Navigation سریع‌تر می‌تواند تجربه کاربری را بهتر کند و بعضی داده‌های Core Web Vitals را در ناوبری‌های پشتیبانی‌شده بهبود دهد.

اما استفاده اشتباه می‌تواند نتیجه معکوس داشته باشد؛ مثلاً:

• مصرف بیش از حد منابع سرور و کند شدن درخواست‌های واقعی؛
• ثبت اشتباه Analytics و Conversion؛
• دانلود بی‌استفاده روی اینترنت محدود کاربر؛
• اجرای زودهنگام JavaScript شخصی‌سازی‌شده؛
• نمایش محتوای کمی قدیمی در بعضی سناریوهای Prefetch Cache.

پس هدف باید تجربه بهتر واقعی باشد، نه صرفاً فعال بودن یک قابلیت جدید.

در چه سایت‌هایی باید با احتیاط بیشتری از Prerender استفاده کنیم؟

Prerender برای هر سایتی انتخاب پیش‌فرض مناسبی نیست. احتیاط بیشتر در این موارد ضروری است:

• فروشگاه‌های پرترافیک با Cart و Session پویا؛
• سایت عضویتی با محتوای شخصی‌سازی‌شده؛
• سایت دارای تبلیغات و Impression حساس؛
• صفحات دارای ویدئوی حجیم و منابع متعدد؛
• سایت با هاست محدود و PHP Worker کم؛
• صفحه‌ای که JavaScript آن در زمان Load State تغییر می‌دهد؛
• Funnelهایی که Query Parameter یا Nonce دارند؛
• صفحات دارای داده‌ای که باید دقیقاً در لحظه Navigation تازه باشد.

در این شرایط Prefetch محافظه‌کارانه معمولاً نقطه شروع بهتری است.

اشتباهات رایج در تنظیم Speculative Loading

نصب افزونه فقط برای فعال کردن قابلیتی که Core از قبل دارد

از WordPress 6.8 به بعد، قابلیت پایه در هسته وجود دارد. افزونه زمانی ارزش دارد که رابط تنظیمات، Prerender آسان‌تر یا کنترل بیشتر برای کاربران واردشده می‌خواهید.

فعال کردن Prerender + Eager بدون اندازه‌گیری

تنظیم تهاجمی باید براساس احتمال واقعی Navigation و ظرفیت زیرساخت باشد. زودتر شروع کردن همیشه به معنی بهتر بودن نیست.

فرض اینکه Hover تنها Trigger در همه دستگاه‌هاست

موبایل Hover ندارد و مرورگر از Heuristicهای دیگری استفاده می‌کند. رفتار Eagerness را به یک رویداد ساده در همه دستگاه‌ها تقلیل ندهید.

نادیده گرفتن Analytics

در Prerender، JavaScript می‌تواند قبل از مشاهده واقعی صفحه اجرا شود. Analytics و کدهای اختصاصی باید Prerender-aware باشند.

Prefetch کردن Action URLها

GET URLای که State سایت را تغییر می‌دهد از نظر طراحی وب مشکل‌دار است و نباید Speculative Load شود. مسیرهای چنین افزونه‌هایی را Exclude کنید.

تست کردن در حالی که داخل WordPress Login هستید

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

توقع پشتیبانی یکسان در همه مرورگرها

Speculation Rules API هنوز Limited Availability است. سایت باید بدون آن هم کاملاً سالم کار کند.

یکی گرفتن Speculative Loading با Lazy Load یا Preload

هرکدام هدف متفاوتی دارند. Speculative Loading برای Navigation آینده است، نه جایگزین Lazy Loading تصویر یا Preload فونت ضروری.

چک‌لیست امن فعال‌سازی و تنظیم Speculative Loading

جمع‌بندی

Speculative Loading یکی از مهم‌ترین قابلیت‌های Performance است که از WordPress 6.8 وارد Core شده است. WordPress برای کاهش ریسک، به‌صورت پیش‌فرض از prefetch + conservative استفاده می‌کند؛ یعنی فقط زمانی که قصد کاربر برای باز کردن لینک بسیار جدی است، سند صفحه مقصد کمی زودتر دریافت می‌شود.

برای بسیاری از سایت‌ها همین رفتار پیش‌فرض انتخاب خوبی است. اگر زیرساخت قوی، کش مناسب و مسیر کاربری قابل پیش‌بینی دارید، می‌توانید ابتدا Eagerness را به moderate تغییر دهید و بعد از تست دقیق سراغ prerender بروید. Prerender پتانسیل Navigation تقریباً فوری دارد، اما چون JavaScript و زیرمنابع را هم آماده می‌کند، باید Analytics، Session، Checkout و صفحات شخصی‌سازی‌شده را جدی‌تر بررسی کنید.

بهترین رویکرد این است که از عدد و تست واقعی تصمیم بگیرید: Rule را در HTML ببینید، Chrome DevTools بخش Speculative loads را بررسی کنید، صفحات حساس را Exclude کنید و در کنار تجربه کاربر، مصرف سرور و Analytics را هم زیر نظر داشته باشید.

برای مطالعه بیشتر می‌توانید مستندات رسمی Speculative Loading در WordPress 6.8، فیلتر تنظیم Speculation Rules در WordPress و راهنمای Speculation Rules API در MDN را ببینید.