افزایش سرعت وردپرس بدون افزونه | ۱۲ اقدام در ۹۰ دقیقه

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

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

برای اینکه مرز دو رویکرد روشن شود، این مقایسه را ببینید:

۱.۱ چرا بعضی سایت‌ها با سی افزونه هم سریع‌اند؟

چون بردبار واقعیِ سرعت، «تعداد افزونه‌ها» نیست؛ «هزینه اجرای هر افزونه» است. ده افزونه سبک و استاندارد که هرکدام یک کار مشخص انجام می‌دهند، از یک قالب چندمنظوره سنگین به‌علاوه دو افزونه بدکد، بسیار کم‌هزینه‌ترند. سایت‌هایی را دیده‌ایم که با بیش از سی افزونه فعال، TTFB زیر ۲۰۰ میلی‌ثانیه دارند، چون هاست درستی رویشان سوار است، OPcache فعال است و قالبشان تمیز نوشته شده. در مقابل، سایت‌هایی دیده‌ایم که با پنج افزونه و یک افزونه کش معروف، TTFB بالای ۱.۲ ثانیه دارند؛ چون host ضعیف است و جدول wp_options به چند مگابایت رسیده است. همین یک تفاوت ذهنی، شروع درست افزایش سرعت وردپرس است.

۱.۲ چرا بعضی سایت‌ها حتی با افزونه کش هم کند می‌مانند؟

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

۲Core Web Vitals؛ آزمون رسمی گوگل برای سرعت وردپرس

قبل از دست‌کردن به سرور و کد، باید بدانیم گوگل با چه خط‌کشی قضاوت می‌کند. طبق مستند رسمی Web Vitals، سه متریک اصلی تجربه کاربری در صدک ۷۵ ترافیک واقعی سایت شما سنجیده می‌شود و دو متریک دیگر هم نقش زیرساختی دارند. این جدول را ذهن‌سپاری کنید؛ در همه بخش‌های بعدی به آن ارجاع می‌دهیم:

۲.۱ هر متریک Core Web Vitals با کدام اقدام افزایش سرعت وردپرس درست می‌شود؟

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

۳
اقدام ۱؛ دکتر سرور: PHP، OPcache و جراحی TTFB (بزرگ‌ترین قدم افزایش سرعت وردپرس)

مشکل چیست و چرا کند می‌کند؟ وردپرس با PHP نوشته شده و در هر لود صفحه، سرور باید صدها فایل PHP را بخواند، اجرا کند و با MySQL حرف بزند تا HTML بسازد. آن مدت، همان TTFB است. اگر هاست شما PHP قدیمی اجرا کند، OPcache خاموش باشد یا منابعش با صدها سایت همسایه تقسیم شده باشد، TTFB به راحتی از مرز ۶۰۰ میلی‌ثانیه رد می‌شود و هر بهینه‌سازی دیگری را خنثی می‌کند؛ چون مرورگر قبل از اینکه بخواهد عکس و فونت را دانلود کند، باید منتظر همین HTML بماند.

گام اول؛ وضعیت فعلی را دقیق بسنجید

اولین کار، سنجش است؛ نه تغییر. برای دیدن نسخه PHP از پیشخوان وردپرس کافی است به مسیر «ابزارها → سلامت سایت → اطلاعات → سرور» بروید. برای سنجش TTFB واقعی، روی هر اینترنتی این دستور را اجرا کنید:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/

گام دوم؛ نسخه PHP را به آخرین نسخه پایدار برسانید

هر نسخه جدید PHP سریع‌تر از قبلی است و بنچمارک‌های عمومی نشان می‌دهد جهش از PHP 7.4 به 8.x در بسیاری از بارهای کاری وردپرس، زمان اجرای PHP را به‌طور محسوس پایین می‌آورد. اگر روی هاست اشتراکی هستید، در cPanel دنبال «MultiPHP Manager» باشید و نسخه را به آخرین نسخه پایدارِ موجود (در حال حاضر خانواده 8.2 یا 8.3) تغییر دهید. قبل از تغییر، سازگاری قالب و افزونه‌ها را روی نسخه استیجینگ تست کنید؛ افزونه‌های خیلی قدیمی ممکن است با PHP 8 ناسازگار باشند. اگر به ترمینال دسترسی دارید، چک نسخه یک خط است:

php -v
# خروجی مطلوب: PHP 8.2.x تا 8.3.x

گام سوم؛ OPcache را روشن و پهن کنید

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

<?php phpinfo(); ?>

فایل را با نام موقت مثل check.php در ریشه بگذارید، یک‌بار بازش کنید و در نتیجه دنبال OPcache بگردید؛ بعد فایل را حتماً حذف کنید. اگر فعال نبود، از پشتیبانی هاست بخواهید روشنش کند. اگر به فایل تنظیمات دسترسی دارید (فایل .user.ini در ریشه هاست یا php.ini در VPS) این مقادیر پیشنهادی را قرار دهید:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
realpath_cache_size=4M
realpath_cache_ttl=600

گام چهارم؛ فشرده‌سازی و کش مرورگر را از خود .htaccess بگیرید

هیچ افزونه‌ای برای دو کار پایه‌ای لازم نیست: فشرده‌سازی خروجی و پیام دادن به مرورگر که فایل‌های ثابت را چند وقت نگه دارد. اگر هاستتان Apache است، این بلوک را به .htaccess ریشه اضافه کنید:

# فشرده‌سازی فایل‌های متنی (اگر Brotli روی سرور باشد، خود هاست اولویت می‌دهد)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>

# کش مرورگر برای منابع ثابت
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

اگر هاست از LiteSpeed یا Nginx استفاده می‌کند، این تنظیمات را پنل هاست یا پشتیبانی انجام می‌دهد؛ فقط مطمئن شوید Gzip/Brotli فعال است (در تب Network دیو‌تولز، هدر content-encoding پاسخ را ببینید). درباره DNS هم دو تصمیم ساده کافی است: از DNS ارائه‌دهنده معتبر استفاده کنید و TTL رکوردها را برای رکوردهای پایدار بالا بگذارید تا کاربران تکراری زمان کمتری در حلقه اول زنجیره بگذرانند.

چک‌لیست انتخاب هاست مناسب برای سرعت وردپرس

قبل و بعد این اقدام (سناریوی واقعی)

📍 سناریو: سایت یک فروشگاه اینترنتی با ووکامرس، PHP 7.4 و OPcache خاموش. فقط با ارتقای PHP به 8.2، فعال‌سازی OPcache با مقادیر بالا و افزودن قوانین .htaccess، TTFB صفحه اصلی از حدود ۹۰۰ میلی‌ثانیه به محدوده ۳۵۰ تا ۴۵۰ میلی‌ثانیه رسید و LCP موبایل از ۴.۸ ثانیه به حدود ۳.۱ ثانیه. هنوز کار مانده بود، ولی هیچ‌کدام از اقدام‌های بعدی بدون این پایه، چنین پرشی نمی‌دادند.

۴اقدام ۲؛ جراحی دیتابیس: کابوس wp_options، ترنزینت‌ها و بازبینی‌ها

مشکل چیست و چرا کند می‌کند؟ در هر لود صفحه، وردپرس ده‌ها کوئری به MySQL می‌زند: محتوای صفحه، منوها، ابزارک‌ها، تنظیمات و مهم‌تر از همه، گروهی از رکوردهای جدول wp_options که پرچم autoload دارند و در همه صفحات، حتی صفحاتی که به آن‌ها نیازی نیست، خوانده می‌شوند. مستند رسمی ووکامرس درباره wp_options تأیید می‌کند که انبساط بی‌رویه این جدول یکی از دلایل مستقیم کندی سایت است؛ چون حجم داده‌ای که در تک‌تک صفحات از روی دیسک خوانده و در حافظه باز می‌شود، بالا می‌رود. به همین دلیل، جراحی دیتابیس در هر برنامه جدی افزایش سرعت وردپرس قدم دوم است، نه قدم دهم.

گام اول؛ وزن autoload را اندازه بگیرید

وارد phpMyAdmin شوید، دیتابیس سایت را انتخاب کنید و این کوئری را در تب SQL اجرا کنید. توجه: از وردپرس 6.6 مقادیر autoload فقط yes و no نیست و خانواده جدیدی دارد؛ پس کوئری مدرن را استفاده کنید:

-- حجم کل داده‌ای که در هر لود صفحه خوانده می‌شود
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

-- سنگین‌ترین رکوردهای autoload را نشان بده
SELECT option_id, option_name, autoload,
       ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY size_kb DESC
LIMIT 20;

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

-- نمونه: توقف بارگذاری خودکار یک رکورد بزرگِ بلااستفاده
UPDATE wp_options SET autoload = 'no'
WHERE option_name = 'old_plugin_settings';

UPDATE wp_options SET autoload = 'no'
WHERE option_name = '_transient_dirsize_cache';

گام دوم؛ ترنزینت‌های منقضی را جارو کنید

ترنزینت‌ها (Transients) کش موقت وردپرس و افزونه‌ها هستند که قرار بوده بعد از انقضا حذف شوند ولی در عمل پشت هم انباشته می‌شوند. این کوئری‌ها برای پاک‌سازی امن‌اند و داده مفیدی حذف نمی‌کنند:

-- حذف ترنزینت‌های منقضی‌شده روی جدول wp_options
DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_timeout\_%'
  AND option_value < UNIX_TIMESTAMP();

DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
  AND option_name NOT LIKE '\_transient\_timeout\_%'
  AND option_name NOT IN (
    SELECT option_name FROM wp_options
    WHERE option_name LIKE '\_transient\_timeout\_%'
);

گام سوم؛ بازبینی‌ها (Revisions) را محدود و پاک کنید

هر بار که دکمه «به‌روزرسانی» را می‌زنید، وردپرس یک نسخه کامل از محتوا را در wp_posts ذخیره می‌کند. روی سایتی با ۵۰۰ مقاله و بیست ویرایش برای هر مقاله، ده هزار ردیف اضافه دارید که هم جدول را سنگین می‌کند و هم بکاپ‌ها را فربه. دو کار لازم است: سقف گذاشتن برای آینده (در اقدام ۱۱ با wp-config انجام می‌دهیم) و پاک‌سازی گذشته:

-- اول ببینید چه حجمی از جدول دست‌وپاگیر است
SELECT COUNT(*) AS revisions_count FROM wp_posts
WHERE post_type = 'revision';

-- سپس فقط بازبینی‌های قدیمی‌تر از ۹۰ روز را پاک کنید
DELETE FROM wp_posts
WHERE post_type = 'revision'
  AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

گام چهارم؛ کوئری‌های کند را شکار کنید

الآن نوبت پیدا کردن قاتل‌های پنهان است. ابزار استاندارد این کار، Query Monitor است؛ یک افزونه توسعه‌دهنده که فقط برای عیب‌یابی، موقتاً نصب می‌شود و بعد از پایان کار حذفش می‌کنید (نصب موقت ابزار تشخیصی، ناقض عنوان «بدون افزونه» نیست؛ چون روی خروجی نهایی سایت چیزی نمی‌ماند). با آن می‌بینید دقیقاً کدام کوئری، توسط کدام قالب یا افزونه، چند میلی‌ثانیه طول کشیده و کدام کوئری تکراری است. دو الگوی رایجی که پیدا خواهید کرد: کوئری‌های meta_query گران‌قیمت روی wp_postmeta برای ساخت «محصولات پرفروش» در هر صفحه، و فراخوانی‌های تکراری get_option که با مرتب‌کردن autoload درمان می‌شوند. برای سایت‌های بسیار بزرگ، از فروشنده هاست بخواهید Slow Query Log را برای چند ساعت روشن کند تا مستقیم از خود MySQL گزارش بگیرید.

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

SHOW INDEX FROM wp_options;

📍 سناریوی واقعی: سایت شرکتی با ۶ سال سابقه؛ حجم autoload به ۳.۸ مگابایت رسیده بود و بیشترش بقایای سه افزونه فرم‌ساز و اسلایدر حذف‌شده بود. با همین سه کوئری (اندازه‌گیری، شناسایی سنگین‌ها، توقف autoload و پاک‌سازی ترنزینت‌ها) حجم به ۶۱۰ کیلوبایت رسید و TTFB حدود ۲۰۰ میلی‌ثانیه پایین آمد؛ بدون تعویض هاست و بدون یک خط کدنویسی جدید.

۵
اقدام ۳؛ رژیم سخت برای قالب: متغیری که بیشترین اثر را روی افزایش سرعت وردپرس دارد

مشکل چیست و چرا کند می‌کند؟ قالب، کارخانه خروجی HTML سایت شماست. قالب‌های چندمنظوره برای اینکه «برای همه همه‌چیز داشته باشند»، معمولاً صدها کیلوبایت CSS و JS در تک‌تک صفحات لود می‌کنند؛ حتی صفحه‌ای که فقط یک متن ساده دارد. وقتی قالب برای نمایش یک صفحه درباره ما، کتابخانه اسلایدر، انیمیشن‌ها و آیکون‌های پنج سبک مختلف را هم بارگذاری کند، بهینه‌سازی تصویر و فونت مثل تمیزکردن اتاقی است که دیوارهایش نم دارند.

۳.۱ اول تشخیص بدهید قالب شما چقدر سنگین است

سریع‌ترین آزمون: همین الان روی صفحه اصلی سایتتان کلیک راست کنید، «View Page Source» را باز کنید و در سورس دنبال .css و .js بگردید. بشمارید و وزنشان را در تب Network دیو‌تولز ببینید. سیگنال‌های هشدار را این جدول خلاصه می‌کند:

۳.۲ ارتش شکیلِ لود نشدنی: dequeue کردن فایل‌های بلااستفاده

اگر تعویض قالب در برنامه‌تان نیست، حداقل جلوی لود فایل‌هایی را بگیرید که در بعضی صفحات هیچ کاربردی ندارند. الگوی رایج: فرم‌ساز و اسلایدر که روی همه صفحات فایل تزریق می‌کنند ولی فقط در صفحه تماس و صفحه اصلی لازم‌اند. این کد را در functions.php قالب فرزند (Child Theme) قرار دهید:

// نمونه: فایل‌های فرم‌ساز فقط در صفحه تماس لود شوند
add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_page( 'contact-us' ) ) {
        wp_dequeue_style( 'contact-form-7' );
        wp_dequeue_script( 'contact-form-7' );
    }
}, 20 );

چطور نام هندل (handle) هر فایل را پیدا کنید؟ با همان Query Monitor موقت، بخش «Scripts & Styles» دقیقاً نام هندل ها را نشان می‌دهد. همیشه اول روی استیجینگ تست کنید؛ dequeue اشتباه یعنی صفحه بدون استایل یا فرم خراب.

۳.۳ functions.php؛ محلی که معمولاً به آشی سنگین تبدیل می‌شود

در پروژه‌های تحویلی، دیده‌ایم functions.php به چند هزار خط برسد: اسنیپت‌هایی که سال‌ها قبل از بلاگ‌ها کپی شده و هر کدام در هر لود اجرا می‌شوند. سه قانون: اسنیپت‌های غیرفعال را کاملاً پاک کنید (نه کامنت)، کدهای سنگینِ محاسباتی را پشت شرط is_admin یا شرط صفحه پنهان کنید، و هر کدی که به ابزارک یا منوی قدیمی مربوط است و دیگر رندر نمی‌شود، حذف شود. اگر قالب فعلی‌تان اساساً اصلاح‌ناپذیر است، بازطراحی با قالب سبک و اختصاصی، همان کاری است که در پروژه‌های طراحی سایت انجام می‌دهیم: خروجی تمیز، DOM جمع‌وجور و فایل‌های کمتر؛ در عمل همین تصمیم‌ها بزرگ‌ترین سهم افزایش سرعت وردپرسِ بیشتر سایت‌ها را می‌سازند.

📍 سناریوی واقعی: وبلاگ شرکتی با قالب چندمنظوره بازاری؛ صفحه تکی نوشته ۱۹ فایل CSS و ۱۴ فایل JS لود می‌کرد. با dequeue شرطی سه کتابخانه بلااستفاده و حذف اسنیپت‌های مرده functions.php، حجم JS صفحه تقریباً نصف شد و INP موبایل از محدوده نامطلوب به خوب برگشت؛ بدون تعویض قالب.

۶اقدام ۴؛ کاهش درخواست‌های HTTP و مهار اسکریپت‌های شخص ثالث

مشکل چیست و چرا کند می‌کند؟ هر فایل CSS، JS، فونت، عکس و هر خط به یک سرور خارجی، یک درخواست جداگانه است که باید DNS را طی کند، اتصال بسازد و دانلود شود. با HTTP/2 و HTTP/3 هزینه موازی‌سازی کمتر شده، ولی هزینه اتصال‌های جدید به دامنه‌های بیرونی هنوز سنگین است. تب Network دیو‌تولز را باز کنید: اگر واترفال سایت شما پر از دامنه‌های نامتجانس است (چت آنلاین، پیکسل تبلیغاتی، آنالتیکس، ویدئوپلیر، CDN فونت)، بخش مهمی از کندی‌تان را نه سرور شما، که همسایه‌های مجازی‌تان می‌سازند. نظم دادن به این دامنه‌ها، قسمت پرتعداد پروژه افزایش سرعت وردپرس در سایت‌های واقعی است.

گام اول؛ ممیز درخواست‌ها

در تب Network دیو‌تولز، فیلتر Domain را باز کنید و دامنه‌ها را بر اساس تعداد و حجم مرتب کنید. اصول قضاوت ساده است: هر منبع بیرونی‌ای که مستقیم در درآمد یا تجربه کاربر نقش ندارد، کاندید حذف یا تأخیر است. الگوهای رایجی که در ممیزی سایت‌های ایرانی می‌بینیم: دو یا سه ابزار چت هم‌زمان از روی مانده دوره‌های مختلف، آنالتیکس دوبل (هم گوگل آنالتیکس، هم ابزار داخلی، هم هوت‌جر)، و لینک فونت و آیکون از CDNهایی که از ایران به‌کندی در دسترس‌اند.

گام دوم؛ preconnect و dns-prefetch برای دامنه‌هایی که واقعاً می‌مانند

برای دامنه‌های بیرونی ضروری (مثلاً گوگل آنالتیکس یا یک CDN که واقعاً استفاده می‌کنید)، هزینه اتصال را از قبل پرداخت کنید. وردپرس هوک استانداردی برای این کار دارد:

add_filter( 'wp_resource_hints', function( $urls, $relation_type ) {
    if ( 'preconnect' === $relation_type ) {
        $urls[] = 'https://www.googletagmanager.com';
    }
    return $urls;
}, 10, 2 );

گام سوم؛ قانون سه‌سؤالی برای هر اسکریپت خارجی

• آیا در ۳ ماه گذشته کسی از دیتایش استفاده کرده؟ اگر نه، حذفش کنید.
• آیا روی همه صفحات لازم است؟ اگر نه، با همان ترفند dequeue اقدام قبل، فقط در صفحات لازم بیاید.
• آیا می‌شود با تأخیر لودش کرد؟ ابزارهای چت و هیت‌مپ تقریباً همیشه می‌توانند بعد از تعامل اول کاربر بیایند؛ در اقدام ۷ روش دقیق تأخیر را می‌دهیم.

📍 سناریوی واقعی: پوشش سایت خبری که ۴ ابزار بیرونی داشت (دو سیستم آماده، چت، پلیر ویدئو). حذف یکی از سیستم‌های آماری که سال‌ها بود کسی به آن نگاه نمی‌کرد + تأخیر چت، تعداد دامنه‌های بیرونی را از ۹ به ۵ رساند و حدود ۴۰۰ میلی‌ثانیه از زمان تعامل‌پذیری موبایل کم شد.

۷اقدام ۵؛ تصاویر: بزرگ‌ترین برد سریع در افزایش سرعت وردپرس (LCP و CLS با هم)

مشکل چیست و چرا کند می‌کند؟ در بیشتر سایت‌های وردپرسی، سنگین‌ترین عنصر صفحه یک عکس است و اگر همان عکس هم پشت چین بالای صفحه باشد، مستقیم روی LCP ضربه می‌زند. دو خطای کلاسیک: آپلود عکس دوربینی ۴ مگابایتی در جایی که حداکثر ۱۲۰۰ پیکسل عرض نشان داده می‌شود، و عکس بدون width و height که مرورگر نمی‌داند چقدر فضا برایش باز نگه دارد و صفحه حین لود می‌پرد (CLS).

۵.۱ قبل از آپلود: ریسایز و تبدیل به WebP

قانون ساده: هر عکسی را در همان ابعادی آپلود کنید که نمایش داده می‌شود و قبل از آپلود، فرمتش را مدرن کنید. برای تعداد کم، ابزار رایگان Squoosh کافی است. برای آرشیو چندصدتایی، ابزار خط فرمان cwebp گوگل روی کامپیوترتان همه‌کاره است:

# تبدیل دسته‌ای به WebP با کیفیت ۸۲ (تعادل تنفسی خوب بین حجم و کیفیت)
for f in *.jpg; do cwebp -q 82 "$f" -o "${f%.jpg}.webp"; done

۵.۲ الگوی HTML درست برای تصویر شاخص (درمان هم‌زمان LCP و CLS)

اگر قالب یا محتوایتان را مستقیم ویرایش می‌کنید، این الگو، چهار درمان را یک‌جا در خود دارد: ابعاد صریح (CLS)، نسخه‌های ریسپانسیو (حجم)، واکنش‌گرایی برای موبایل، و اولویت دانلود برای LCP:

<img
  src="hero-800.webp"
  srcset="hero-480.webp 480w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450"
  alt="توصیف واقعی و کوتاه تصویر"
  fetchpriority="high"
  loading="eager"
  decoding="async">

و اگر می‌خواهید دانلود تصویر LCP حتی از تحلیل HTML هم جلوتر بیفتد، همان تصویر را در head قالب preload کنید:

<link rel="preload" as="image" href="/wp-content/uploads/hero-800.webp">

📍 سناریوی واقعی: فروشگاه پوشاک؛ عکس هیروی صفحه اصلی یک JPEG با حجم ۱.۹ مگابایت بود. ریسایز به ۱۲۰۰ پیکسل، تبدیل به WebP با کیفیت ۸۲ (خروجی حدود ۱۴۰ کیلوبایت)، افزودن width و height. نتیجه: LCP موبایل از ۴.۱ به ۲.۳ ثانیه رسید و CLS آن صفحه عملاً صفر شد؛ فقط با یک فایل، بدون هیچ افزونه‌ای.

۸اقدام ۶؛ CSS: از دیوار ۹۰۰ کیلوبایتی تا استایل حیاتی برای سرعت وردپرس

مشکل چیست و چرا کند می‌کند؟ CSS یک منبع «قفل‌کننده رندر» است: مرورگر تا وقتی همه استایل‌شیت‌های لینک‌شده در head را دانلود و پردازش نکرده، هیچ پیکسلی نقش نمی‌بندد. در قالب‌های سنگین، بیشتر این CSS برای کامپوننت‌هایی است که در صفحه جاری اصلاً استفاده نمی‌شوند. در تب Coverage دیو‌تولز (در منوی DevTools گزینه Coverage) می‌توانید ببینید چند درصد CSSها واقعاً به کار رفته‌اند؛ روی قالب‌های بازاری معمولاً عددی شوکه‌کننده است.

۶.۱ Critical CSS دستی برای صفحه‌های کلیدی

برای صفحه اصلی و صفحه محصول (دو صفحه‌ای که رتبه و درآمد را می‌سازند)، استایل‌های لازم برای «بخش قابل مشاهده اولیه» را استخراج و داخل head اینجکت کنید و بقیه فایل را بدون قفل رندر لود کنید:

<style>
  /* فقط استایل‌های بخش بالای صفحه: ریست، تایپوگرافی، هدر، هیرو */
  body{margin:0;font-family:Vazirmatn,Tahoma,sans-serif}
  .site-header{display:flex;align-items:center;min-height:64px}
  .hero{background:#1a1a2e;color:#fff;padding:40px 24px}
</style>
<link rel="stylesheet" href="main.css" media="print" onload="this.media='all'">

۶.۲ سه تغییر کوچک با اثر بزرگ

• Minify دستی: نسخه نهایی CSS را با ابزار آنلاین CSS Minifier فشرده کنید و همان را در قالب نگه دارید؛ نسخه خوانا فقط برای توسعه بماند.
• حذف قوانین مرده: با گزارش Coverage، کامپوننت‌هایی را که ماه‌هاست استفاده نشده‌اند (قالب‌های اسلایدر قدیمی، سبک‌های صفحه قدیمی) از فایل حذف کنید.
• منع import@: هر import@ در CSS، یک رفت‌وبرگشت اضافه به سرور است؛ فایل‌ها را مستقیم لینک کنید یا در یک فایل ادغامشان کنید.

📍 سناریوی واقعی: سایت شرکتی با main.css به حجم ۴۸۰ کیلوبایت. پوشش Coverage نشان داد فقط ۱۳٪ از قوانین روی صفحه اصلی استفاده می‌شود. استخراج Critical CSS (۹ کیلوبایت) و لود غیرقفل‌کننده باقی فایل، FCP را حدود ۰.۷ ثانیه بهتر کرد؛ کاری که هیچ افزونه مینیفای‌کننده‌ای به‌تنهایی انجامش نمی‌دهد، چون مشکل حجم بود نه فاصله‌های اضافی.

۹اقدام ۷؛ جاوااسکریپت بدون قفل؛ درمان INP در افزایش سرعت وردپرس

مشکل چیست و چرا کند می‌کند؟ رشته اصلی مرورگر یک کارگر بیشتر ندارد. وقتی ۶۰۰ کیلوبایت جاوااسکریپت پیج‌بیلدر، اسلایدر و ابزارهای بازاریابی باید دانلود، پارس و اجرا شوند، همان کارگر برای هر کلیک بعدی کاربر صف می‌کشد و INP قرمز می‌شود. برخلاف تصویر که فقط وزنش گران است، جاوااسکریپت دوباره هزینه می‌تراشد: یک‌بار دانلود، یک‌بار اجرا. پس هر بایتی که از این فایل‌ها حذف یا به تعویق بیفتد، یک گام مستقیم در افزایش سرعت وردپرس است.

۷.۱ defer و async؛ دو کلیدواژه که نصف درد را درمان می‌کنند

در وردپرس می‌توانید با فیلتر استاندارد script_loader_tag رفتار لود هر هندل را عوض کنید؛ بدون دست‌کاری هسته:

add_filter( 'script_loader_tag', function( $tag, $handle ) {
    // این اسکریپت‌ها به رندر اولیه نیازی ندارند
    $defer = [ 'comment-reply', 'wp-embed' ];
    if ( in_array( $handle, $defer, true ) ) {
        return str_replace( ' src', ' defer src', $tag );
    }
    return $tag;
}, 10, 2 );

۷.۲ حذف jquery-migrate و تأخیر هوشمند برای ابزارها

خیلی از قالب‌ها هنوز jquery-migrate را لود می‌کنند؛ لایه سازگاری برای افزونه‌هایی که ممکن است سال‌هاست دیگر وجود نداشته باشند. اگر بعد از حذفش (در قالب فرزند، فقط روی استیجینگ) هیچ خطای کنسولی ندیدید، ۱۵ تا ۲۰ کیلوبایت جاوااسکریپت از هر صفحه کم شده است:

add_action( 'wp_default_scripts', function( $scripts ) {
    if ( ! is_admin() ) {
        $scripts->remove( 'jquery-migrate' );
    }
} );

برای ابزارهایی مثل چت آنلاین، الگوی استاندارد تأخیر این است: فایل را با رویداد اولین اسکرول/کلیک/حرکت موس یا پس از چند ثانیه لود کنید. همین تصمیم، در خیلی از پروژه‌ها تنها فرق بین INP قرمز و سبز است.

📍 سناریوی واقعی: سایت آموزشی با قالب مبتنی بر پیج‌بیلدر؛ INP موبایل حدود ۴۸۰ میلی‌ثانیه بود. defer برای اسکریپت‌های غیرحیاتی، حذف jquery-migrate و تأخیر ابزار چت، آن را به زیر ۱۹۰ میلی‌ثانیه رساند؛ بدون برداشتن حتی یک امکان از سایت.

۱۰اقدام ۸؛ فونت‌ها: قاتل خاموش CLS در افزایش سرعت وردپرس

مشکل چیست و چرا کند می‌کند؟ لود فونت از دامنه خارجی (مثل فونت‌های گوگل) یعنی یک اتصال جدید، چند فایل CSS و چند فایل woff2 قبل از اینکه متن خوانا شود. اگر فونت دیر برسد، متن یا نامرئی می‌ماند (FOIT) یا با فونت جایگزین رندر و بعد می‌پرد (FOUT) و هر دو برای CLS و تجربه کاربر بد است. فونت فارسی هم چون زیرمجموعه گلیف‌هایش از لاتین بزرگ‌تر است، حجمش حساس‌تر است.

۸.۱ میزبانی محلی فونت؛ گام قطعی افزایش سرعت وردپرس موبایل

فایل woff2 فونت فارسی‌تان (مثلاً وزیرمتن یا ایران‌سنس) را داخل پوشه قالب بگذارید و با font-face تعریف کنید؛ این کار، اتصال به دامنه خارجی را کلاً حذف می‌کند:

@font-face {
  font-family: 'Vazirmatn';
  src: url('/wp-content/themes/your-theme/fonts/vazirmatn-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

و برای فونتی که در بالای صفحه حتماً لازم است، preload کنید تا دیر نرسد:

<link rel="preload" href="/wp-content/themes/your-theme/fonts/vazirmatn-regular.woff2" as="font" type="font/woff2" crossorigin>

۸.۲ سه قانون که فرق می‌سازند

• font-display: swap همیشه: متن فوراً با فونت جایگزین نشان داده می‌شود و وقتی فونت اصلی رسید جایگزین می‌شود. برای فارسی، سعی کنید فونت پشتیبان (fallback) Tahoma یا system-ui باشد تا جهش چیدمان کمتر دیده شود.
• فقط وزن‌هایی که واقعاً استفاده می‌کنید: بسیاری از سایت‌ها ۵ وزن فونت لود می‌کنند درحالی‌که در همه سایت فقط از معمولی و بولد استفاده می‌شود. هر وزن حذف‌شده، ده‌ها کیلوبایت کمتر.
• فقط فرمت woff2: فرمت‌های قدیمی (ttf, eot) برای مرورگرهای کهنه وظیفه‌ای ندارند که شما هنوز انجامش بدهید؛ woff2 برای وب امروزی کافی است.

انتخاب فونت پشتیبان هم در ثبات چیدمان فارسی اثر دارد:

📍 سناریوی واقعی: مجله فارسی که فونت ایران‌سنس را از یک CDN خارجی با ۴ وزن لود می‌کرد. میزبانی محلی دو وزن پرکاربرد + preload + swap، زمان قابل‌خواندن شدن متن را در موبایل حدود نیم ثانیه جلو انداخت و جهش متن هنگام تعویض فونت به چشم‌پوشی قابل تحمل رسید.

۱۱اقدام ۹؛ کرون واقعی به جای WP-Cron: توقف سلف‌مچ‌گری سرور در هر بازدید

مشکل چیست و چرا کند می‌کند؟ وردپرس برای کارهای زمان‌بندی‌شده (انتشار نوشته‌های برنامه‌ریزی‌شده، پاک‌سازی، چک آپدیت) یک کرون ساختگی دارد: wp-cron.php که با هر بازدید صفحه چک می‌شود. روی سایت پرترافیک، یعنی هر چند هزار بازدید، چند هزار فراخوانی اضافه برای «ببینم کاری هست یا نه». روی سایت کم‌ترافیک مشکل دیگری است: کرون دیر می‌گذرد چون کسی سایت را باز نکرده. هر دو حالت را یک راه‌حل واقعی جمع می‌کند: کرون سرور؛ یکی از بی‌سروصدا‌ترین قدم‌های افزایش سرعت وردپرس در سایت‌های پرترافیک.

گام اول؛ خاموش کردن کرون داخلی

در فایل wp-config.php، کمی بالاتر از خط پایانی ویرایش، این را اضافه کنید:

define( 'DISABLE_WP_CRON', true );

گام دوم؛ ساختن کرون واقعی در هاست

در cPanel به بخش Cron Jobs بروید و یک کرون روی هر ۱۵ دقیقه بسازید. فرمان استاندارد:

*/15 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

اگر به ترمینال دسترسی دارید و WP-CLI روی سرور نصب است، نسخه تمیزتر:

*/15 * * * * cd /home/user/public_html && wp cron event run --due-now >/dev/null 2>&1

📍 سناریوی واقعی: فروشگاه اینترنتی با اوج ترافیک ساعت‌های ۲۰ تا ۲۳. در همان ساعت‌ها که سرور باید تمام‌قد به سفارش‌ها جواب می‌داد، wp-cron در هر بازدید چک می‌شد و پروسه‌های PHP اشغال می‌کردند. انتقال به کرون ۱۵ دقیقه‌ای، در ساعت‌های اوج چند درصدی مصرف CPU را آزاد کرد؛ عددی که روی داشبورد هاست قابل مشاهده بود.

۱۲اقدام ۱۰؛ مهار Heartbeat API: درد پنهان مدیران و نویسندگان وبلاگ

مشکل چیست و چرا کند می‌ کند؟ Heartbeat API هر ۱۵ ثانیه از مرورگر شما به سرور پینگ می‌زند تا قفل نوشته، ذخیره خودکار و اعلان‌های پیشخوان را زنده نگه دارد. روی سایت تک‌نویسنده زیاد بد نیست، ولی روی سایتی با چند نویسنده هم‌زمان یا فروشگاهی که دائم پیشخوانش باز است، هر تب بازِ پیشخوان یعنی یک ریکوئست مکرر هر ۱۵ ثانیه به سرور. درواقع مصرف سرور در خواب فزاینده است، نه در ترافیک واقعی.

راه‌حل مرحله‌ای (بدون کورکردن سیستم)

توصیه ما حذف کامل Heartbeat نیست؛ کنترل آن است. این کد در functions.php قالب فرزند، فواصل را به ۶۰ ثانیه می‌رساند و فقط در پیشخوان باقی می‌ماند:

// کاهش فرکانس Heartbeat از ~۱۵ ثانیه به ۶۰ ثانیه
add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

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

add_action( 'init', function() {
    global $pagenow;
    // Heartbeat فقط هنگام ویرایش نوشته لازم است
    if ( ! in_array( $pagenow, [ 'post.php', 'post-new.php' ], true ) ) {
        wp_deregister_script( 'heartbeat' );
    }
}, 1 );

۱۳اقدام ۱۱؛ wp-config.php: هفت تنظیم سبک‌ سازی برای افزایش سرعت وردپرس

فایل wp-config.php قبل از همه چیز لود می‌شود و تعاریفش رفتار کل وردپرس را تعیین می‌کند. به‌جای ده‌ها اسنیپت پراکنده، این بلوک واحد را دقیقاً بالای خط «That’s all, stop editing» قرار دهید. هر ثابت را توضیح داده‌ام تا بدانید چه چیزی را خاموش یا محدود می‌کنید؛ این هفت تعریف، ارزان‌ترین قدم‌های افزایش سرعت وردپرس‌اند چون یک‌بار نوشته می‌شوند و برای همیشه اثر می‌گذارند:

// سقف حافظه PHP برای فرانت و مقدار بیشتر برای پیشخوان
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

// بازبینی‌ها: حداکثر ۵ نسخه برای هر محتوا (به‌جای بی‌نهایت)
define( 'WP_POST_REVISIONS', 5 );

// ذخیره خودکار هر ۲ دقیقه به‌جای هر ۶۰ ثانیه (ریسک کمتر، کوئری کمتر)
define( 'AUTOSAVE_INTERVAL', 120 );

// زباله‌دان هر ۷ روز یک‌بار خالی شود
define( 'EMPTY_TRASH_DAYS', 7 );

// ویرایشگر فایل قالب و افزونه از پیشخوان غیرفعال (امنیت + جلوگیری از خرابی‌های تصادفی)
define( 'DISALLOW_FILE_EDIT', true );

سه نکته مهم: اول، اگر هاست شما محدودیت حافظه سخت دارد، مقدار WP_MEMORY_LIMIT بیشتر از سقف هاست اثری ندارد؛ سقف واقعی را از «سلامت سایت» بخوانید. دوم، بازبینی‌هایی که با WP_POST_REVISIONS محدود می‌کنید از امروز به بعد آرام نمی‌شود؛ برای گذشته، کوئری پاک‌سازی اقدام ۲ را اجرا کنید. سوم، DISALLOW_FILE_EDIT اگرچه مستقیم سرعت را تغییر نمی‌دهد ولی از نصف خرابی‌های «کدی که داخل پیشخوان کپی شد» جلوگیری می‌کند؛ همان خرابی‌هایی که بعدا سرور را به زانو درمی‌آورند.

۱۴اقدام ۱۲؛ پاک‌ سازی خروجی Core؛ شش مهمان ناخوانده در مسیر سرعت وردپرس

وردپرس برای سازگاری با همه سناریوها، چیزهایی در خروجی head می‌گذارد که بیشتر سایت‌های مدرن هرگز استفاده‌شان نمی‌کنند. این‌ها جداگانه کوچک‌اند، ولی جمع‌شان چند درخواست و مقداری HTML در تک‌تک صفحات است که بابتش هیچ ارزشی به کاربر نمی‌دهید. این بلوک یک‌پارچه را در functions.php قالب فرزند بگذارید:

// ۱) اسکریپت و استایل ایموجی (وردپرس برای ایموجی قدیمی CDN لود می‌کند)
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

// ۲) اسکریپت embed (فقط اگر خودتان محتوایتان در سایت‌های دیگر embed نمی‌شود)
add_action( 'wp_footer', function() { wp_deregister_script( 'wp-embed' ); } );

// ۳) لینک‌های اضافه head: RSD، لینک کوتاه، نسخه وردپرس
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wp_shortlink_wp_head' );
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'wlwmanifest_link' );

// ۴) استایل آیکون‌های دشبورد برای کاربران مهمان (dashicons فقط برای پیشخوان است)
add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_user_logged_in() ) {
        wp_deregister_style( 'dashicons' );
    }
} );

// ۵) استایل کتابخانه بلوک در قالب‌های کلاسیک که از گوتنبرگ در قالب استفاده نمی‌کنند
add_action( 'wp_enqueue_scripts', function() {
    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'global-styles' );
}, 100 );

و دو مهمان دیگر: XML-RPC و پینگ‌بک

XML-RPC رابط قدیمی وردپرس برای اتصال اپلیکیشن‌هاست؛ اگر با اپ موبایل رسمی یا Jetpack کار نمی‌کنید، می‌توانید آن را در .htaccess کاملاً ببندید تا هم درخواست‌های بیهوده کم شود و هم حملات brute-force روی آن بی‌اثر:

<Files xmlrpc.php>
  Require all denied
</Files>

پینگ‌بک و ترک‌بک را هم از مسیر «تنظیمات ← گفت‌وگو» خاموش کنید؛ مکانیزمی قدیمی که علاوه بر اعلان‌های اسپم‌گونه، درگاهی برای درخواست‌های اضافه است و تأثیر مثبت قابل‌سنجشی روی سئو ندارد. اگر می‌خواهید کامل‌تر عمل کنید، متد پینگ‌بک را هم با این فیلتر از XML-RPC خارج کنید:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

📍 سناریوی واقعی: وب‌سایت خدماتی با قالب کلاسیک؛ حذف ایموجی، embed، dashicons مهمان و بستن XML-RPC در مجموع ۳ درخواست و حدود ۴۵ کیلوبایت از هر صفحه کم کرد. عدد کوچکی است، ولی وقتی با ۱۱ اقدام قبلی جمع می‌شود، همان مرزی است که سایت را از «نیاز به بهبود» به «خوب» می‌برد.

۱۵ابزارهای سنجش: کدام ابزار چه چیزی را در مسیر افزایش سرعت وردپرس می‌بیند؟

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

۱۶
چک‌لیست اجرا: نقشه ۹۰ دقیقه‌ای افزایش سرعت وردپرس بدون افزونه + جدول ردیابی نتیجه

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

اقدام‌های ۳، ۴، ۶، ۷ و ۸ (قالب، شخص‌ثالث‌ها، CSS، JS و فونت) فنی‌ترند؛ اگر تجربه کدنویسی ندارید، آن مرحله را به برنامه‌ریز فنی بسپارید یا با مشاوره سئو تیم ویرا نقشه دقیق وضعیت سایت خودتان را بگیرید. کرم‌پودر روی بنیان ترک‌خورده، ساختمان نمی‌سازد.

۱۶.۱ جدول ردیابی قبل و بعد

۱۶.۲ جدول مرجع نهایی؛ هر اقدام، متریک و ابزار خودش

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

و در نهایت، نکته‌ای که هیچ چک‌لیستی نمی‌گوید: سرعت یک پروژه یک‌باره نیست. هر آپدیت قالب، هر افزونه جدید و هر کمپین تبلیغاتی می‌تواند هفته‌ها بهینه‌سازی را پس ببرد. همین جدول را ماهانه یک‌بار تکرار کنید؛ همین انضباط کوچک، تفاوت سایت‌هایی است که سریع می‌مانند با سایت‌هایی که هر سال دوباره «پروژه سرعت» تعریف می‌کنند.

۱۷سوالات متداول درباره افزایش سرعت وردپرس بدون افزونه (۵۰ پرسش کاربردی)