پیش‌بارگذاری لینک‌ها در وردپرس؛ افزایش سرعت باز شدن صفحات

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

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

پیش‌بارگذاری لینک‌ها در وردپرس یعنی چه؟

فرض کنید کاربر اکنون در صفحه A است و داخل آن لینکی به صفحه B وجود دارد.

در حالت عادی مسیر تقریباً این است:

کلیک ← درخواست B ← انتظار برای پاسخ ← نمایش B

اما با آماده‌سازی هوشمند:

تشخیص احتمال رفتن به B ← دریافت یا آماده‌کردن B ← کلیک ← نمایش سریع‌تر

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

پیش‌دریافت صفحه با آماده‌سازی کامل صفحه چه تفاوتی دارد؟

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

بنابراین آماده‌سازی کامل تهاجمی‌تر است و برای هر لینک و هر سایتی انتخاب مناسبی نیست.

آیا WordPress خودش پیش‌بارگذاری لینک دارد؟

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

در WordPress 7.1، یعنی نسخه فعلی در زمان نگارش این مقاله، حالت پیش‌فرض همچنان:

پیش‌دریافت + رفتار محافظه‌کارانه

است. این قابلیت در Frontend برای بازدیدکنندگان عادی فعال است، اما به‌طور پیش‌فرض برای کاربران واردشده و سایت‌هایی که Pretty Permalinks ندارند غیرفعال می‌شود. WordPress 7.1 همچنین امکان تغییر پیش‌فرض‌ها از طریق constant یا environment variable را اضافه کرده است.

نکته مهم: قرار بود در شرایط دارای کش، رفتار Core تهاجمی‌تر شود، اما این تغییر در 7.1 نهایی نشد و اکنون برای WordPress 7.2 دنبال می‌شود.

چرا وردپرس حالت محافظه‌کارانه را انتخاب کرده است؟

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

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

چطور بفهمیم قابلیت لود پیش‌بینانه WordPress روی سایت فعال است؟

ابتدا سایت را در حالت خروج از حساب باز کنید؛ تست با حساب مدیر می‌تواند گمراه‌کننده باشد.

در View Source یا DevTools عبارت زیر را جست‌وجو کنید:

speculationrules

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

روش دوم، بررسی درخواست‌ها در Network است.

چطور با Network بفهمیم صفحه قبل از کلیک آماده شده؟

1. صفحه موردنظر سایت را باز کنید.
2. DevTools را باز کنید.
3. وارد تب Network شوید.
4. فهرست درخواست‌ها را پاک کنید.
5. هنوز روی لینک مقصد کلیک نکنید.
6. تعامل لازم، مانند نگه‌داشتن ماوس یا شروع فشردن لینک، را انجام دهید.
7. ببینید URL مقصد پیش از Navigation ظاهر شده است یا خیر.

اگر درخواست پیش‌بینانه ایجاد شده باشد، در Header آن ممکن است Sec-Purpose: prefetch یا در آماده‌سازی کامل prefetch;prerender دیده شود. رفتار دقیق DevTools به روش و مرورگر بستگی دارد. بخش Speculative loads در ابزارهای Chrome نیز برای عیب‌یابی دقیق‌تر مفید است.

Hover چه نقشی در افزایش سرعت باز شدن صفحات دارد؟

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

نکته مهم این است که حالت محافظه‌کارانه فعلی WordPress Core با Hover شروع نمی‌شود؛ شروع فشردن ماوس یا لمس، سیگنال اصلی آن است. در حالت متوسط مرورگرهای Chromium، نگه‌داشتن نشانگر حدود ۲۰۰ میلی‌ثانیه روی لینک می‌تواند آماده‌سازی را آغاز کند.

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

آیا Hover صفر میلی‌ثانیه بهتر است؟

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

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

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

روی موبایل که Hover نداریم چه اتفاقی می‌افتد؟

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

فاصله لمس تا انتقال صفحه بسیار کوتاه است؛ بنابراین فرصت آماده‌سازی محدودتر از دسکتاپ است. Chromium در رفتار متوسط از اوت ۲۰۲۵ برای موبایل از منطق مبتنی بر لینک‌های داخل محدوده قابل مشاهده نیز استفاده می‌کند.

به همین دلیل استراتژی موبایل نباید صرفاً نسخه کپی‌شده تنظیمات دسکتاپ باشد.

آماده‌سازی لینک‌های جلوی چشم کاربر

فرض کنید صفحه دسته‌بندی فروشگاه ۱۲ محصول دارد، اما در نمایش موبایل فقط چهار محصول فعلاً روی صفحه دیده می‌شوند.

این چهار لینک از نظر احتمال تعامل می‌توانند مهم‌تر از محصولاتی باشند که چند اسکرول پایین‌تر قرار دارند. موتورهای لود هوشمند می‌توانند «قابل مشاهده بودن» را یکی از سیگنال‌های انتخاب مقصد بدانند.

اما Visible بودن به معنی دانلود فوری همه لینک‌های Visible نیست.

چرا همه لینک‌های قابل مشاهده نباید هم‌زمان درخواست شوند؟

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

Chrome نیز برای جلوگیری از افراط، روی بارگذاری‌های وابسته به تعامل محدودیت هم‌زمانی اعمال می‌کند.

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

صف آماده‌سازی و تعداد درخواست هم‌زمان

فرض کنید ۱۰ مقصد مناسب پیدا شده ولی سقف هم‌زمانی دو درخواست است.

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

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

اولویت لینک‌ها چگونه تعیین شود؟

یک ترتیب منطقی می‌تواند چنین باشد:

1. شروع کلیک یا لمس؛ بالاترین احتمال انتقال.
2. ماندن ماوس روی لینک.
3. مقصدی که رفتار قبلی کاربر آن را محتمل کرده است.
4. لینکی که صرفاً داخل محدوده دید قرار گرفته است.

اگر لینکی قبلاً با اولویت پایین در صف باشد و کاربر ناگهان روی همان لینک مکث کند، بهتر است همان رکورد ارتقای اولویت بگیرد، نه اینکه یک درخواست دوم ساخته شود.

چرا URL تکراری نباید چند بار آماده شود؟

آدرس‌هایی مانند:

/product/
/product/#reviews

می‌توانند به همان سند اصلی اشاره کنند. نسخه دارای Fragment نباید بی‌دلیل باعث دریافت دوباره همان صفحه شود.

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

نرمال‌سازی Query String یا Trailing Slash نیز نباید کورکورانه انجام شود، چون در بعضی سایت‌ها می‌تواند معنای URL را تغییر دهد.

صفحه‌ای که کاربر داخل آن است نباید دوباره Prefetch شود

اگر کاربر اکنون داخل /product/example/ قرار دارد، آماده‌سازی دوباره همین URL هیچ مزیت ناوبری ایجاد نمی‌کند.

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

چه لینک‌هایی برای پیش‌بارگذاری مناسب‌تر هستند؟

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

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

چه لینک‌هایی را نباید از قبل آماده کرد؟

لینک‌های خروج از حساب، حذف، تغییر وضعیت، دانلود عملیاتی، URLهای دارای nonce، لینک‌های خارجی و آدرس‌های mailto:، tel:، javascript: و Anchor داخل همان صفحه گزینه‌های مناسبی برای آماده‌سازی کورکورانه نیستند.

از نظر طراحی سایت ، درخواست GET بهتر است وضعیت کاربر را تغییر ندهد؛ ولی در عمل افزونه‌هایی وجود دارند که «Action URL» می‌سازند. خود WordPress نیز به همین دلیل Query Parameterها و چند گروه URL حساس را در قوانین پیش‌فرض محدود می‌کند.

پیش‌بارگذاری لینک‌ها در WooCommerce

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

اما Cart، Checkout، My Account، Login/Logout، حذف محصول، لینک Add to Cart، wc-ajax، nonce و URLهای پرداخت یا تغییر وضعیت باید بسیار محافظه‌کارانه مدیریت شوند.

WooCommerce رسماً Cart، Checkout و My Account را صفحات پویا و وابسته به مشتری می‌داند. همچنین URLهایی مانند ?add-to-cart=123 صرفاً با بازشدن آدرس می‌توانند سبد خرید را تغییر دهند.

پس در فروشگاه، «لینک داخلی بودن» به‌تنهایی معیار امن‌بودن نیست.

کاربران واردشده چه تفاوتی دارند؟

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

همین موضوع یکی از دلایلی است که WordPress Core لود پیش‌بینانه را در حالت پیش‌فرض برای کاربران واردشده غیرفعال می‌کند.

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

اینترنت ضعیف و حالت کاهش مصرف داده

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

مرورگرهای پشتیبانی‌شده هنگام پیش‌دریافت می‌توانند تنظیماتی مانند Data Saver یا Battery Saver را در نظر بگیرند. اگر یک موتور سفارشی از اطلاعات اتصال استفاده می‌کند، باید ابتدا وجود آن قابلیت را بررسی کند؛ نباید فرض کرد همه مرورگرها navigator.connection یا داده مشابه ارائه می‌کنند.

آیا پیش‌بارگذاری لینک باعث فشار روی سرور می‌شود؟

بله، ممکن است.

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

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

فرق کش با پیش‌بارگذاری لینک چیست؟

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

فرق Preload با Prefetch صفحه چیست؟

Preload یا پیش‌بارگذاری منبع معمولاً برای منابع مهم صفحه فعلی مانند فونت، تصویر اصلی یا فایل ضروری استفاده می‌شود.

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

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

آیا پیش‌بارگذاری لینک PageSpeed را بهتر می‌کند؟

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

PageSpeed معمولاً بارگذاری همان URL آزمایش‌شده را ارزیابی می‌کند؛ در حالی که مزیت اصلی لود پیش‌بینانه هنگام Navigation از صفحه فعلی به صفحه بعدی آشکار می‌شود. WordPress نیز این قابلیت را با تمرکز بر بهبود تجربه جابه‌جایی بین صفحات وردپرس و عملکرد صفحه مقصد وارد Core کرده است.

پیش‌بارگذاری لینک چه زمانی تقریباً بی‌فایده است؟

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

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

پشتیبانی مرورگرها

قابلیت‌های اصلی موردنیاز وردپرس در مرورگرهای جدید مبتنی بر Chromium مانند Chrome و Edge پشتیبانی خوبی دارند. این API هنوز در MDN «Baseline» محسوب نمی‌شود، یعنی نمی‌توان فرض کرد همه مرورگرهای پرکاربرد رفتار یکسانی دارند.

این قابلیت به شکل Progressive Enhancement طراحی شده است: مرورگر فاقد پشتیبانی قوانین را نادیده می‌گیرد و Navigation معمولی سایت باید بدون اختلال ادامه پیدا کند.

افزونه رسمی Speculative Loading وردپرس چیست؟

تیم Performance وردپرس افزونه رسمی Speculative Loading را پیش از ادغام قابلیت با Core توسعه داد و توسعه آن ادامه دارد.

در زمان نگارش، نسخه 1.7.0 منتشر شده، حداقل WordPress 6.9 می‌خواهد و تا WordPress 7.1 آزمایش شده است. قابلیت پایه از 6.8 وارد Core شده، اما افزونه برای تنظیم روش و شدت بارگذاری و فعال‌سازی اختیاری برای کاربران احراز هویت‌شده کنترل بیشتری ارائه می‌کند.

تنظیمات تهاجمی‌تر همیشه بهتر نیستند

«پیش‌دریافت محافظه‌کارانه» درخواست‌های اشتباه کمتری تولید می‌کند اما فرصت آماده‌سازی کوتاه‌تر است.

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

بنابراین بهترین حالت باید با داده واقعی سایت مشخص شود.

LoadJox چه تفاوتی با حالت پیش‌فرض وردپرس دارد؟

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

نقطه شروع مقایسه باید روشن باشد: WordPress Core از نسخه 6.8 خودش زیرساخت لود پیش‌بینانه را دارد و LoadJox قرار نیست وجود این قابلیت در هسته را جایگزین یا انکار کند. Core در WordPress 7.1 به‌طور پیش‌فرض از پیش‌دریافت محافظه‌کارانه استفاده می‌کند؛ یعنی عمداً نزدیک به تعامل قطعی کاربر وارد عمل می‌شود.

تمرکز محصول LoadJox متفاوت است: مأموریت آن روی Smart Page Loading و آماده‌کردن مقصد احتمالی بعدی، در عین حفظ Navigation استاندارد مرورگر، تعریف شده است؛ نه تعویض DOM، شبیه‌سازی SPA یا ساخت سیستم کش صفحه.

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

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

در نتیجه مزیت واقعی LoadJox باید بر «کنترل و منطق تخصصی‌تر انتخاب مسیر» سنجیده شود، نه ادعای اینکه WordPress هیچ قابلیت مشابهی ندارد.

LoadJox چه چیزی نیست؟

LoadJox افزونه کش صفحه، Minify یا پاک‌سازی دیتابیس نیست. CSS را بهینه نمی‌کند، JavaScript بلااستفاده را حذف نمی‌کند و زمان پاسخ بد سرور را درمان نمی‌کند.

همچنین قرار نیست سایت را SPA کند، History API را تصاحب کند یا رفتار عادی لینک‌ها را جایگزین کند. تعریف محصول بر حفظ Navigation استاندارد مرورگر تأکید دارد.

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

تنظیم مناسب برای سایت‌های مختلف

اعداد زیر نقطه شروع آزمایشی برای موتورهایی هستند که چنین کنترل‌هایی دارند، نه قانون ثابت:

چطور تنظیمات مناسب سایت خودمان را پیدا کنیم؟

از حالت محافظه‌کارانه شروع کنید. Network را بررسی کنید، تعداد درخواست‌های اضافه و مصرف CPU/هاست را ثبت کنید، سپس زمان Hover یا تعداد مقصدها را مرحله‌ای تغییر دهید.

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

قاعده مهم این است: هر بار فقط یک متغیر را تغییر دهید؛ وگرنه نمی‌فهمید بهتر یا بدترشدن نتیجه مربوط به کدام تنظیم بوده است.

چطور بفهمیم پیش‌بارگذاری واقعاً سرعت جابه‌جایی را بهتر کرده؟

یک مسیر ثابت انتخاب کنید؛ مثلاً:

صفحه اصلی ← دسته‌بندی ← محصول

یا:

مقاله ← مقاله بعدی

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

در Network زمان شروع درخواست مقصد، دریافت HTML و Navigation را مقایسه کنید. علاوه بر اعداد، تجربه واقعی کلیک روی همان مسیر را نیز بررسی کنید. تفاوت باید در جابه‌جایی صفحه دیده شود، نه فقط در یک امتیاز PageSpeed.

اشتباهات رایج پیش‌بارگذاری لینک‌ها

1. پیش‌دریافت تمام لینک‌های صفحه بدون تشخیص اهمیت.
2. هم‌زمانی بسیار بالا.
3. آماده‌کردن URL فعلی.
4. درخواست چندباره یک مقصد.
5. آماده‌کردن Cart و Checkout بدون بررسی.
6. نادیده‌گرفتن Logout و URLهای عملیاتی.
7. رفتار تهاجمی روی اتصال ضعیف.
8. تصور اینکه پیش‌دریافت جایگزین Cache است.
9. تلاش برای پنهان‌کردن TTFB بالا با آماده‌سازی.
10. تست فقط با حساب Administrator.
11. کپی‌کردن رفتار دسکتاپ روی موبایل.
12. سنجش نتیجه فقط با PageSpeed.
13. نادیده‌گرفتن Query String و nonce.
14. استفاده گسترده از آماده‌سازی کامل بدون بررسی JavaScript و Analytics.

چک‌لیست نهایی

□ نسخه WordPress و رفتار نسخه 6.8 به بعد بررسی شده است.
□ لود پیش‌بینانه Core بررسی شده است.
□ Network تست شده است.
□ URL فعلی دوباره درخواست نمی‌شود.
□ URL تکراری کنترل شده است.
□ تعداد درخواست‌های هم‌زمان کنترل می‌شود.
□ لینک‌های قابل مشاهده در منطق انتخاب مقصد مدیریت می‌شوند.
□ Hover و Touch اولویت متناسب دارند.
□ صفحات حساس مستثنا شده‌اند.
□ مسیرهای WooCommerce آزمایش شده‌اند.
□ موبایل جداگانه تست شده است.
□ اتصال ضعیف در نظر گرفته شده است.
□ بدون JavaScript، Navigation عادی لینک‌ها همچنان سالم است.

سوالات متداول

1. پیش‌بارگذاری لینک در وردپرس چیست؟

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

2. Prefetch چیست؟

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

3. Prerender چیست؟

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

4. وردپرس خودش Prefetch دارد؟

بله. از WordPress 6.8 لود پیش‌بینانه وارد هسته شده است. برای بازدیدکنندگان Frontend در شرایط عادی، WordPress می‌تواند مقصدهای مناسب را به‌صورت محافظه‌کارانه پیش‌دریافت کند. بنابراین نصب افزونه صرفاً برای اینکه «اصل قابلیت» وجود داشته باشد الزامی نیست؛ افزونه زمانی مطرح می‌شود که کنترل یا رفتار متفاوتی نیاز دارید.

5. WordPress 6.8 چه تغییری ایجاد کرد؟

WordPress 6.8 زیرساخت رسمی Speculation Rules را وارد Core کرد و برای سایت‌های واجد شرایط، پیش‌دریافت محافظه‌کارانه لینک‌ها را به رفتار پیش‌فرض تبدیل کرد. در نسخه فعلی 7.1 این پایه همچنان وجود دارد. 7.1 امکان تعیین پیش‌فرض mode و eagerness از طریق constant یا environment variable را نیز فراهم کرده است.

6. آیا Prefetch سرعت سایت را افزایش می‌دهد؟

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

7. آیا پیش‌بارگذاری لینک روی PageSpeed اثر دارد؟

اثر اصلی این تکنیک الزاماً در تست معمول تک‌صفحه‌ای PageSpeed دیده نمی‌شود. مزیت آن زمانی آشکار می‌شود که کاربر از صفحه A به B می‌رود و B قبلاً تا حدی آماده شده باشد. بنابراین برای ارزیابی، Network و تجربه Navigation واقعی معمولاً از مشاهده صرف امتیاز PageSpeed مناسب‌تر هستند.

8. آیا همه لینک‌های سایت را باید Prefetch کرد؟

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

9. Hover صفر خوب است؟

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

10. روی موبایل پیش‌بارگذاری چطور انجام می‌شود؟

موبایل Hover واقعی ندارد. می‌توان از شروع لمس، Pointer Down و در برخی پیاده‌سازی‌ها از احتمال تعامل با لینک‌های قابل مشاهده استفاده کرد. مرورگرهای Chromium نیز برای حالت متوسط منطق ویژه‌ای برای موبایل دارند. از آنجا که فاصله لمس تا Navigation کوتاه است، تنظیمات موبایل باید جداگانه ارزیابی شوند.

11. آیا Prefetch روی سرور فشار ایجاد می‌کند؟

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

12. آیا Cart و Checkout را باید Prefetch کرد؟

به‌صورت عمومی توصیه نمی‌شود بدون بررسی دقیق این مسیرها را وارد آماده‌سازی تهاجمی کنید. سبد خرید و تسویه‌حساب به Session و وضعیت مشتری وابسته‌اند و WooCommerce آن‌ها را صفحات پویا می‌داند. همچنین Add-to-Cart و بعضی URLهای عملیاتی می‌توانند با درخواست GET وضعیت سبد را تغییر دهند.

13. فرق Cache و Prefetch چیست؟

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

14. LoadJox چه تفاوتی با قابلیت خود WordPress دارد؟

WordPress Core یک پایه استاندارد و محافظه‌کارانه برای لود پیش‌بینانه دارد. LoadJox به‌عنوان موتور تخصصی لود هوشمند روی انتخاب و آماده‌سازی مقصد احتمالی بعدی و رفتار متناسب با تعامل کاربر متمرکز است. قابلیت‌های پیشرفته باید براساس Build فعلی افزونه سنجیده شوند و نباید ویژگی‌های صرفاً برنامه‌ریزی‌شده به‌عنوان قابلیت منتشرشده معرفی شوند.

15. آیا LoadJox سایت را SPA می‌کند؟

خیر. معماری تعریف‌شده LoadJox بر حفظ Navigation بومی مرورگر تأکید دارد. یعنی موتور می‌تواند مقصد احتمالی را قبل از انتقال آماده کند، اما بعد از کلیک خود مرورگر Navigation استاندارد را انجام می‌دهد. جایگزینی DOM، تصاحب History API یا تبدیل سایت وردپرسی به SPA جزو هدف محصول نیست.

جمع‌بندی

پیش بارگذاری لینک ها در وردپرس زمانی بیشترین فایده را دارد که خود صفحه مقصد سریع باشد، احتمال کلیک به‌درستی تشخیص داده شود، تعداد درخواست‌ها کنترل شود و URLهای حساس کنار گذاشته شوند. WordPress Core از نسخه 6.8 پایه لود پیش‌بینانه را در اختیار سایت‌ها قرار داده و در نسخه فعلی 7.1 همچنان رویکرد پیش‌دریافت محافظه‌کارانه را به‌عنوان پیش‌فرض حفظ کرده است.

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