برای افزایش سرعت سایت وردپرسی، ابتدا باید مشخص کنید چه چیزی کند است: پاسخ سرور، نمایش تصویر اصلی، اجرای JavaScript یا واکنش صفحه به کلیک کاربر. نصب یک افزونه کش میتواند بخشی از مشکل را حل کند، اما هیچ تنظیم واحدی برای سایت شرکتی، فروشگاهی و وبسایت ساختهشده با المنتور مناسب نیست. این راهنما مسیر تشخیص، اصلاح و اندازهگیری نتیجه را با ابزارهای روز توضیح میدهد.
از کجا شروع کنیم؟ تست سرعت سایت وردپرسی
ابتدا سه نوع صفحه را انتخاب کنید: صفحه اصلی، یک صفحه مقاله یا خدمات و در فروشگاه یک صفحه محصول. هر صفحه را با PageSpeed Insights بررسی کنید. گزارش موبایل و دسکتاپ را جداگانه بخوانید. سپس در Chrome DevTools، بخش Network و Performance را برای یافتن منابع سنگین یا اجرای طولانی JavaScript باز کنید.
داده کاربران واقعی (Field Data) در گزارش Chrome UX Report از تجربه بازدیدکنندگان واقعی به دست میآید؛ اما آزمایش Lighthouse شرایطی شبیهسازیشده دارد و برای پیدا کردن علتهای فنی مناسبتر است. نبود داده واقعی برای یک URL به معنای سالم یا خراب بودن آن نیست.
استانداردهای Core Web Vitals در ۲۰۲۶
| شاخص | محدوده خوب | چه چیزی را میسنجد؟ |
|---|---|---|
| LCP | ۲٫۵ ثانیه یا کمتر | زمان نمایش بزرگترین عنصر محتوایی قابل مشاهده |
| INP | ۲۰۰ میلیثانیه یا کمتر | پاسخ رابط به تعاملهای واقعی کاربر |
| CLS | ۰٫۱ یا کمتر | پایداری بصری و جابهجایی ناخواسته عناصر |
این آستانهها در راهنمای رسمی web.dev تعریف شدهاند و برای ارزیابی تجربه واقعی در صدک ۷۵ بارگذاریهای موبایل و دسکتاپ بهصورت جداگانه استفاده میشوند. شاخص INP جایگزین FID شده است؛ بنابراین آموزشی که هنوز FID را معیار اصلی تعامل معرفی میکند نیازمند بهروزرسانی است.
جدول عیبیابی: مشکل سرعت از کجا میآید؟
| نشانه | علتهای احتمالی | اقدام بعدی و روش بررسی |
|---|---|---|
| TTFB بالا | پاسخ کند PHP، کوئری سنگین، هاست شلوغ یا کش غیرفعال | زمان پاسخ HTML را در Network بررسی کنید؛ پاسخ کششده و کشنشده را جدا مقایسه کنید. |
| LCP بالا | تصویر Hero سنگین، درخواست دیرهنگام تصویر، فونت یا CSS مسدودکننده | عنصر LCP را در Performance پیدا کنید؛ اولویت و زمان کشف منبع را بسنجید. |
| INP نامناسب | JavaScript سنگین، رویدادهای طولانی، ویجت و اسکریپت ثالث | در DevTools تعامل کند را ثبت و Long Taskها را بررسی کنید. |
| CLS بالا | تصویر بدون ابعاد، بنر پویا، فونت یا تبلیغ بدون فضای رزروشده | Layout Shifts را در Performance بررسی کنید. |
| صفحه محصول کند | اسکریپت متغیرها، افزونههای محصول، دیتابیس یا درخواست Ajax | در همان محصول، کوئریها، درخواستها و اجرای اسکریپتها را مقایسه کنید. |
| کندی فقط در پنل مدیریت | پیشخوان سنگین، WP-Cron، Heartbeat، کوئری یا پردازش پسزمینه | زمان درخواستهای admin-ajax و رویدادهای زمانبندیشده را بررسی کنید. |
۱. بهینهسازی TTFB، هاست و PHP
TTFB مدت رسیدن اولین بایت پاسخ است و میتواند تحت تأثیر DNS، اتصال، ریدایرکت، شبکه و زمان پردازش سرور قرار گیرد؛ پس بالا بودن آن لزوماً به معنای ضعیف بودن PHP نیست. اگر پاسخ اولیه HTML زیاد طول میکشد، ابتدا ریدایرکتها و وضعیت کش را بررسی کنید؛ سپس مصرف CPU و RAM، لاگ کندی PHP-FPM و کوئریهای دیتابیس را تحلیل کنید.
نسخه پشتیبانیشده PHP، تنظیم مناسب OPcache، منابع سرور و میزبانی متناسب با تعداد بازدیدکننده و افزونههای سایت مهماند. ارتقای PHP را در محیط آزمایشی انجام دهید و سازگاری قالب و افزونهها را پیش از اعمال روی سایت اصلی بررسی کنید.
۲. کش وردپرس را درست انتخاب و تنظیم کنیم
Page Cache خروجی HTML صفحات عمومی را برای درخواستهای بعدی آماده نگه میدارد. Object Cache نتایج برخی عملیات و کوئریها را میان درخواستها نگه میدارد و OPcache اجرای PHP را بهینه میکند؛ اینها جایگزین یکدیگر نیستند. مستندات رسمی WordPress درباره Cache مزایای ذخیره خروجی صفحات کمتغییر را توضیح میدهد.
- Page Cache: مناسب صفحات عمومی مانند مقالهها و بخش بزرگی از صفحههای خدمات.
- Object Cache: برای بعضی سایتهای پویا و فروشگاههای پررفتوآمد؛ نیازمند تنظیم درست و پایش حافظه.
- Browser Cache و CDN: کاهش دریافت دوباره منابع ثابت و بهبود تحویل فایلها به کاربران دورتر از سرور.
اگر از WP Rocket یا راهکار کش سطح سرور استفاده میکنید، همپوشانی آنها را بررسی کنید. فعالکردن همزمان چند سیستم بدون شناخت ترتیب اجرا میتواند عیبیابی را سختتر کند. کش HTML صفحات شخصیسازیشده، سبد خرید و تسویهحساب باید مطابق رفتار واقعی فروشگاه کنترل شود.
۳. تصاویر و LCP؛ مهمتر از صرفاً تبدیل JPG به WebP
اول عنصر LCP را مشخص کنید. در صفحه اصلی ممکن است تصویر بنر باشد و در مقاله یک تیتر متنی. اگر تصویر LCP است، نسخهای با ابعاد درست و حجم مناسب تحویل دهید، منبع آن را زود در HTML قابل کشف کنید و از Lazy Load کردن همان تصویر خودداری کنید. برای تصاویر پایین صفحه میتوان Lazy Loading را به کار برد.
<img
src="/images/hero-960.webp"
srcset="/images/hero-480.webp 480w,
/images/hero-960.webp 960w,
/images/hero-1440.webp 1440w"
sizes="(max-width: 48rem) 100vw, 70vw"
width="960" height="640"
fetchpriority="high"
alt="نمای اصلی خدمات سایت">
نام فایلها در این قطعه کد نمونه هستند. fetchpriority="high" را برای منابع مهم و واقعاً اولویتدار استفاده کنید، نه تمام تصاویر صفحه. در ووکامرس تصویر اصلی محصول، تصاویر گالری، تصاویر دسته و تصویر بنر را جداگانه بررسی کنید. فرمت AVIF یا WebP اغلب به کاهش حجم کمک میکند؛ اما تنظیم فشردهسازی و کیفیت تصویر باید با مقایسه واقعی انتخاب شود.
۴. کاهش هزینه JavaScript و بهبود INP
مهمترین سؤال این نیست که چند فایل JS داریم؛ بلکه این است که مرورگر چه مقدار کد را چه زمانی اجرا میکند. اسکریپتهای چت آنلاین، تبلیغات، اسلایدرهای سنگین و بعضی ویجتهای صفحهساز ممکن است Main Thread را درگیر کنند.
- اسکریپت غیرضروری را از صفحههایی که به آن نیاز ندارند حذف کنید.
- کارهای طولانی را به وظایف کوچکتر تقسیم کنید و از اجرای سنگین در رویداد کلیک پرهیز کنید.
- Delay و Defer را مرحلهای فعال کنید؛ عملکرد منو، جستوجو، فرم، انتخاب متغیر محصول و پرداخت را پس از هر تغییر تست کنید.
- از راهنمای رسمی بهبود Core Web Vitals برای اولویتبندی اصلاحات استفاده کنید.
برخلاف Lighthouse، اندازهگیری کامل INP به تعامل واقعی نیاز دارد. در گزارش آزمایشگاهی ممکن است TBT بهعنوان شاخص کمکی برای بررسی هزینه اجرای JavaScript دیده شود.
۵. CSS و فونتها؛ جلوگیری از کندی و جابهجایی
بارگذاری CSS ضروری بخش ابتدایی صفحه باید بهموقع انجام شود. پاکسازی CSS بدون تست میتواند استایل صفحههای خاص، پاپآپها یا نسخه موبایل را ناقص کند. فونتهای موردنیاز را محدود کنید، وزنهای غیرضروری را حذف کنید و اثر تغییر فونت بر عرض متن و CLS را بسنجید. انتخاب font-display باید با توجه به ظاهر نهایی و تجربه کاربر انجام شود.
برای تصاویر، ویدئوها و آیتمهایی که دیر وارد صفحه میشوند فضای مناسب تعریف کنید؛ چون CLS فقط با کوچککردن فایلها حل نمیشود.
۶. بهینهسازی دیتابیس و WP-Cron
حذف بیهدف همه Revisionها یا پاکسازی جدولهای ناشناخته، روش حرفهای افزایش سرعت نیست. نخست مشخص کنید درخواست کند کدام کوئری را اجرا میکند، آیا ایندکس مناسب دارد و آیا عملیات برنامهریزیشده پشتسرهم اجرا میشوند. در سایتهای پرترافیک، بررسی تنظیم WP-Cron و انتقال اجرای مناسب به زمانبند واقعی سرور ممکن است مفید باشد.
پیش از حذف دادههای دیتابیس حتماً بکاپ قابل بازیابی داشته باشید. افزایش حجم جدول بهتنهایی ثابت نمیکند که همان جدول علت کندی صفحه است.
۷. افزایش سرعت Elementor بدون خراب شدن طراحی
در المنتور ابتدا ساختار صفحه و تعداد ویجتهای واقعاً موردنیاز را بررسی کنید. بخشهای تکراری، اسلایدرهای بیاستفاده، افکتهای سنگین و تصویرهای بزرگ معمولاً فرصت بهینهسازی دارند. اگر قابلیت بهینهسازی DOM یا بارگذاری منابع را فعال میکنید، خروجی واقعی صفحه را در موبایل و دسکتاپ بررسی کنید؛ بهویژه فرم، منو، پاپآپ و المانهای چسبان.
هدف این نیست که همه جلوهها حذف شوند؛ باید مشخص شود کدام جلوه برای کاربر ارزش دارد و چه هزینهای در بارگذاری و تعامل تحمیل میکند.
۸. نکات ویژه سرعت ووکامرس و صفحات پویا
صفحه فروشگاه، صفحه محصول و تسویهحساب رفتار متفاوتی دارند. یک راهکار کش مناسب برای مقاله ممکن است برای سبد خرید صحیح نباشد. بررسی کنید اطلاعات سبد کاربر دیگر نمایش داده نشود، قیمت و موجودی متغیرها درست بهروزرسانی شود و روند پرداخت پس از تغییر تنظیمات JavaScript و کش سالم بماند.
| نوع صفحه | اولویت عملی |
|---|---|
| دسته محصولات | کش صفحات عمومی، بهینهسازی تصاویر لیست و فیلتر |
| صفحه محصول | بهینهسازی تصویر اصلی، اسکریپت متغیرها و دادههای مرتبط |
| سبد خرید | جلوگیری از کش مشترک داده شخصی و تست تغییر تعداد |
| تسویهحساب | تست درگاه، اعتبارسنجی فرم، حملونقل و بهروزرسانی سفارش |
۹. تنظیمات WP Rocket را به چه ترتیبی بررسی کنیم؟
- از وضعیت فعلی تنظیمات و نتیجه PageSpeed نسخه پشتیبان یا گزارش بگیرید.
- ابتدا وضعیت Page Cache و استثناهای صفحات پویا را بررسی کنید.
- تصاویر پایین صفحه و iframeهای مناسب را برای Lazy Load بررسی کنید؛ تصویر LCP را مستثنا کنید.
- بهینهسازی CSS را فعال کنید و استایل تمام قالبهای صفحه را آزمایش کنید.
- Delay یا Defer JavaScript را جداگانه بررسی و بعد از هر مرحله منو و فرم و خرید را تست کنید.
- کش و Preload را پس از تغییرات کنترل کنید و نتایج را با شرایط اولیه مقایسه کنید.
نام گزینهها و رفتار آنها ممکن است با نسخه افزونه تغییر کند؛ پس مستندات همان نسخه را ملاک قرار دهید. برای مطالعه بیشتر، راهنمای رسمی WP Rocket مفید است.
۱۰. تحلیل تخصصی با Vira Performance Inspector
وقتی PageSpeed نشان میدهد سایت کند است اما علت هنوز مشخص نیست، بررسی لایههای داخلی وردپرس اهمیت پیدا میکند. Vira Performance Inspector ابزار تحلیل عملکرد وردپرس است که برای بررسی TTFB و HTTP، کوئریهای دیتابیس، سربار افزونه و قالب، WP-Cron، WooCommerce و کش طراحی شده است. این ابزار در درجه اول برای تشخیص گلوگاههاست، نه یک راهحل جادویی که صرف نصب آن همه مشکلات را برطرف کند.
برای استفاده از چنین گزارشهایی، یافتهها باید با دادههای مرورگر، لاگ سرور و آزمایش تکرارشونده تطبیق داده شوند. انجام اصلاح حساس در سایت عملیاتی بدون نسخه پشتیبان و آزمون بازیابی مناسب نیست.
چکلیست قبل و بعد از بهینهسازی
| مرحله | اقدام قابل اندازهگیری |
|---|---|
| قبل از تغییر | آدرس صفحه، تاریخ آزمایش، دستگاه، LCP، INP/داده واقعی، CLS و زمان پاسخ را ثبت کنید. |
| تشخیص | عنصر LCP، درخواستهای سنگین، Long Taskها، خطاها و وضعیت کش را مشخص کنید. |
| اصلاح | هر بار یک دسته تغییر انجام دهید تا اثر آن قابل نسبت دادن باشد. |
| تست عملکرد | منو، جستوجو، فرم، تصویر، سبد خرید، متغیر محصول و درگاه پرداخت را کنترل کنید. |
| بعد از تغییر | با دستگاه، شبکه و شرایط مشابه مجدد آزمایش کنید؛ تغییرات داده واقعی را در بازه زمانی کافی پیگیری کنید. |
سؤالات متداول درباره افزایش سرعت وردپرس
قبل از نصب افزونه، علت کندی را با PageSpeed Insights و بررسی سرور مشخص کنید. اگر کش صفحه ندارید، یک راهکار کش متناسب با وبسرور انتخاب کنید؛ نصب چند افزونه کش مشابه معمولاً ضروری نیست.
خیر. امتیاز Lighthouse نتیجه آزمایش در شرایط شبیهسازیشده است. عملکرد کاربران واقعی، بهویژه معیارهای LCP، INP و CLS در صدک ۷۵، برای ارزیابی تجربه واقعی اهمیت دارد.
بخشهای پویا مانند سبد خرید، تسویهحساب و دادههای وابسته به کاربر نباید مثل صفحات عمومی با کش مشترک ارائه شوند. تنظیم استثناها و آزمایش خرید واقعی لازم است.
این فرمتها اغلب به کاهش حجم کمک میکنند، اما نتیجه به نوع تصویر و تنظیمات فشردهسازی بستگی دارد. ابعاد درست، تصویر مناسب viewport و اولویت بارگذاری تصویر اصلی نیز اهمیت دارد.
توان پردازشی کمتر بعضی گوشیها، محدودیت شبکه، اجرای JavaScript و تفاوت چیدمان میتوانند مؤثر باشند. برای نتیجه قابل اعتماد، داده کاربران واقعی موبایل را جداگانه بررسی کنید.
منابع و آموزشهای مرتبط
- Google web.dev — Core Web Vitals
- Google web.dev — Effective Ways to Improve Core Web Vitals
- WordPress Developer — Performance and Optimization
- WordPress Developer — Cache
- WP Rocket — WordPress Speed Optimization
- معرفی افزونه تحلیل عملکرد ویرا
- راهنمای طراحی ریسپانسیو وبسایت
سلام مرسی خیلی کمک کردش مخصوصا غیر فعال کردن دوره ای پلاگین ها