چگونه WordPress را در سال ۲۰۲۶ سریع‌تر کنیم: یک فهرست بهینه‌سازی عملکرد

سایت خود را از PageSpeed Insights (pagespeed.web.dev) عبور دهید و چهار رقم را یادداشت کنید: LCP (Largest Contentful Paint، زمان تا ظاهر شدن محتوای اصلی)، INP (Interaction to Next Paint، پاسخ‌گویی)، CLS (Cumulative Layout Shift، پایداری بصری) و وزن کل صفحه. آستانه‌های Core Web Vitals گوگل: LCP زیر ۲٫۵ ثانیه، INP زیر ۲۰۰ میلی‌ثانیه، CLS زیر ۰٫۱. آن‌ها از سال ۲۰۲۱ مستقیماً بر رتبه‌بندی شما تأثیر می‌گذارند. زیر آن آستانه‌ها «خوب» است؛ بین آستانه‌ها و ۴ ثانیه/۵۰۰ میلی‌ثانیه/۰٫۲۵ «نیاز به بهبود» است؛ بدتر از آن «ضعیف» است. کل هدف از بهینه‌سازی سرعت WordPress، بردن این سه رقم به منطقه سبز است. به امتیازهای GTmetrix یا دیگر ارزیابی‌های تجمیعی اعتماد نکنید: آن‌ها با سیگنال‌های واقعی گوگل مطابقت ندارند.

TTFB (Time To First Byte) را از جغرافیای مخاطب خود با WebPageTest بررسی کنید. اگر TTFB از ۱ ثانیه بیشتر باشد، هاستینگ شما گلوگاه است: هیچ بهینه‌سازی فرانت‌اندی آن را درست نمی‌کند. مقصران رایج: هاستینگ اشتراکی ارزان با سرورهای پربار، هاستینگ در قاره‌ای متفاوت از مخاطب شما، نبود opcache مربوط به PHP (هر نسخه PHP 7+ باید آن را به‌طور پیش‌فرض فعال داشته باشد). ارزان‌ترین راه‌حل تغییر به یک هاستینگ سریع‌تر در همان سطح طرح است. برای کمتر از ۵۰٬۰۰۰ بازدید در ماه، Hostinger Business با LiteSpeed Cache یک TTFB زیر ۴۰۰ میلی‌ثانیه تولید می‌کند. برای ترافیک بیشتر، Kinsta یا WP Engine در سطح پریمیوم Google Cloud به‌طور پیوسته یک TTFB زیر ۳۰۰ میلی‌ثانیه تولید می‌کنند. تغییر هاستینگ کار بیشتری از نصب یک افزونه دارد، اما بهبود معمولاً چشمگیر است.

به‌طور پیش‌فرض، WordPress هر صفحه را در هر درخواست از PHP + MySQL تولید می‌کند. کش صفحه، HTML تولیدشده را ذخیره می‌کند و آن را مستقیماً به بازدیدکنندگان بعدی سرو می‌کند: معمولاً ۱۰ تا ۲۰ برابر سریع‌تر. روی هاستینگ‌های مبتنی بر LiteSpeed (Hostinger، بیشتر Bluehost، A2 Turbo، NameHero)، LiteSpeed Cache (رایگان) را نصب کنید: با کش در سطح سرور یکپارچه می‌شود. روی هاستینگ‌های Apache/Nginx، WP Rocket (۵۹ دلار در سال) را نصب کنید: باکیفیت‌ترین افزونه کش است و ارزش قیمتش را دارد. جایگزین‌های رایگان (W3 Total Cache، WP Super Cache) کار می‌کنند اما به پیکربندی بیشتری نیاز دارند. پس از فعال کردن کش صفحه، دوباره در PageSpeed Insights آزمایش کنید: باید افت چشمگیر TTFB را ببینید.

تصاویر معمولاً ۶۰ تا ۸۰٪ وزن یک صفحه WordPress هستند. دو پیروزی برای به‌دست آوردن: (۱) فشرده‌سازی: هر تصویر باید پیش از بارگذاری فشرده شود. از فشرده‌ساز تصویر ما استفاده کنید یا ShortPixel/Smush را برای فشرده‌سازی خودکار هنگام بارگذاری نصب کنید. هدف: تصاویر سرصفحه زیر ۲۰۰ کیلوبایت، تصاویر محتوا زیر ۱۰۰ کیلوبایت. (۲) فرمت‌های مدرن: WebP (یا AVIF) را به‌جای JPG/PNG سرو کنید. WebP با همان کیفیت ۲۵ تا ۳۵٪ کوچک‌تر است. ShortPixel و Smush Pro به‌طور خودکار تبدیل می‌کنند؛ به‌عنوان جایگزین، بهینه‌سازی تصویر Cloudflare تصاویر را در لحظه بازنویسی می‌کند. (۳) بارگذاری معوق: تصاویر زیر خط تا (below the fold) فقط باید هنگام پیمایش به سمت آن‌ها بارگذاری شوند. WordPress 5.5+ به‌طور خودکار loading='lazy' را اضافه می‌کند؛ با مشاهده کد منبع بررسی کنید که کار می‌کند. (۴) صفات عرض: همیشه یک width/height صریح روی تصاویر تنظیم کنید تا از CLS جلوگیری شود.

بیشتر افزونه‌های کش (WP Rocket، LiteSpeed Cache) کوچک‌سازی CSS/JS را شامل می‌شوند: آن را فعال کنید. بزرگ‌ترین پیروزی، به‌تعویق انداختن یا حذف اسکریپت‌های استفاده‌نشده است. در صفحه خانه خود Chrome DevTools ← زبانه Coverage را اجرا کنید؛ نشان می‌دهد که چه بایت‌هایی از CSS و JS واقعاً استفاده می‌شوند. نتایج معمول: ۵۰ تا ۸۰٪ از CSS استفاده نمی‌شود، ۳۰ تا ۶۰٪ از JS استفاده نمی‌شود. راه‌حل‌ها: (الف) از یک قالب سبک‌تر استفاده کنید (GeneratePress یا Kadence کمتر از ۳۰ کیلوبایت CSS می‌فرستند)، (ب) افزونه‌های استفاده‌نشده را غیرفعال کنید (اغلب منشأ اسکریپت‌های استفاده‌نشده)، (ج) از افزونه‌ای مانند Asset CleanUp برای غیرفعال کردن اسکریپت‌ها در صفحاتی که به آن‌ها نیاز ندارند استفاده کنید (مثلاً Contact Form 7 به‌طور پیش‌فرض همه‌جا بارگذاری می‌شود حتی اگر فقط آن را در /contact استفاده کنید).

هر افزونه فعال WordPress در هر بارگذاری صفحه اجرا می‌شود و به‌طور بالقوه پرس‌وجو، JavaScript و CSS اضافه می‌کند. بیشتر سایت‌های کند بیش از ۳۰ تا ۵۰ افزونه فعال دارند که نیمی از آن‌ها دیگر استفاده نمی‌شوند. از Query Monitor (رایگان) برای دیدن اینکه کدام افزونه‌ها بیشترین پرس‌وجو به پایگاه‌داده را انجام می‌دهند استفاده کنید. از سطح رایگان New Relic یا APM مربوط به Kinsta برای دیدن اینکه کدام توابع افزونه بیشترین زمان را می‌برند استفاده کنید. متخلفان اصلی تاریخی: Jetpack (کارهای زیادی انجام می‌دهد، همه در هر درخواست)، افزونه‌های پشتیبان‌گیری متورم که در پیک ترافیک اجرا می‌شوند، افزونه‌های اشتراک‌گذاری اجتماعی که CSS/JS خود را حتی در صفحات بدون دکمه اشتراک‌گذاری بارگذاری می‌کنند، افزونه‌های امنیتی که اسکن فایل بلادرنگ انجام می‌دهند. یک افزونه را غیرفعال کنید، عملکرد را دوباره آزمایش کنید و تصمیم بگیرید که آیا آن قابلیت ارزش هزینه را داشت.

WordPress با گذر زمان زباله در پایگاه‌داده انباشته می‌کند: نسخه‌های بازنگری نوشته‌ها، transientهای منقضی، نظرات اسپم، فراداده‌های یتیم. WP-Optimize (رایگان) را نصب کنید و یک‌بار پاک‌سازی پایگاه‌داده را اجرا کنید. نگهداری ماهانه معقول: نسخه‌های بازنگری بیش از ۶۰ روز را حذف کنید (نسخه‌های اخیر را برای ایمنی نگه دارید)، transientهای منقضی، صف اسپم. برای سایت‌های پرترافیک، بزرگ‌ترین پیروزی پایگاه‌داده، کش شیء است: Redis یا Memcached نتایج پرس‌وجوهای پرهزینه MySQL را در حافظه ذخیره می‌کنند و از کار تکراری جلوگیری می‌کنند. بیشتر هاستینگ‌های مدیریت‌شده WordPress در سطوح بالاتر خود Redis را شامل می‌شوند؛ در هاستینگ اشتراکی پایه، این در دسترس نیست.

یک CDN (شبکه توزیع محتوا) منابع ایستای شما (تصاویر، CSS، JS) را در موقعیت‌های لبه نزدیک به بازدیدکنندگان شما کش می‌کند. برای مخاطبی صرفاً آمریکایی که در آمریکا میزبانی می‌شود، یک CDN بهبودی متوسط می‌آورد. برای مخاطبی جهانی، یک CDN ضروری است: تأخیر منابع را از ۲۰۰ تا ۵۰۰ میلی‌ثانیه به ۲۰ تا ۵۰ میلی‌ثانیه کاهش می‌دهد. سطح رایگان Cloudflare بیشتر نیازها را پوشش می‌دهد؛ BunnyCDN با ۰٫۰۱ تا ۰٫۰۵ دلار به ازای هر گیگابایت یک ارتقای پولی با عملکرد عالی است. به‌طور خاص برای تصاویر، Cloudflare Images یا Bunny Image Optimizer می‌توانند در لحظه اندازه را تغییر دهند و فرمت‌ها را تبدیل کنند.

پس از هر تغییر مهم، PageSpeed Insights را دوباره اجرا کنید. هدف، پیشرفت تدریجی است: بیشتر سایت‌ها با یک تغییر منفرد از «ضعیف» به «خوب» نمی‌روند. پس از یک گذر کامل بهینه‌سازی، نتایج معمول: یک فروشگاه WooCommerce روی هاستینگ اشتراکی از LCP ۴ تا ۶ ثانیه به LCP ۱٫۵ تا ۲٫۵ ثانیه می‌رود. یک بلاگ محتوایی روی هاستینگ مدیریت‌شده از LCP ۲ تا ۳ ثانیه به LCP ۰٫۸ تا ۱٫۵ ثانیه می‌رود. اگر پس از همه موارد بالا بالای ۳ ثانیه LCP باقی ماندید، گلوگاه احتمالاً قالب شماست: پیش از ادامه بهینه‌سازی به یک قالب سبک‌تر (GeneratePress، Kadence یا Astra) تغییر دهید.