برای افزایش سرعت سایت وردپرسی، نصب یک افزونه کش همیشه اولین یا بهترین اقدام نیست. کندی سایت میتواند از پاسخگویی ضعیف سرور، تصویر اصلی صفحه، فایلهای JavaScript، فونتها، افزونهها، دیتابیس، قالب، صفحهساز یا منابع خارجی ایجاد شود.
اگر بدون تشخیص علت اصلی، چند افزونه بهینهسازی نصب کنید و تمام گزینههای Minify، Delay و Lazy Load را فعال کنید، ممکن است امتیاز یکی از ابزارهای تست بهتر شود؛ اما همزمان منوی موبایل، فرمها، سبد خرید، درگاه پرداخت یا سیستم رهگیری تبلیغات دچار مشکل شود.
مسیر اصولی افزایش سرعت وردپرس چهار مرحله دارد:
- وضعیت فعلی سایت را اندازهگیری کنید.
- گلوگاه اصلی را پیدا کنید.
- تغییرات را یکییکی و در محیط امن اجرا کنید.
- نتیجه را در شرایط مشابه دوباره اندازهگیری کنید.
سرعت مناسب فقط برای گرفتن امتیاز بهتر در PageSpeed Insights نیست. یک صفحه باید برای کاربران واقعی، روی موبایلهای ضعیفتر و اتصالهای مختلف، سریع، پایدار و پاسخگو باشد.
عملکرد سایت همچنین بخشی از تجربه کلی کاربر از ورود به صفحه تا پیدا کردن پاسخ یا انجام اقدام موردنظر است. برای درک بهتر ارتباط میان سرعت، تجربه کاربری و سئو، میتوانید راهنمای بهینهسازی تجربه جستوجو یا SXO را نیز مطالعه کنید.
پاسخ سریع:
- اگر TTFB بالا است، ابتدا سرور، PHP، دیتابیس و Page Cache را بررسی کنید.
- اگر LCP ضعیف است، عنصر اصلی صفحه، زمان کشف آن، حجم منبع و CSS یا JavaScript مسدودکننده را بررسی کنید.
- اگر INP ضعیف است، Long Taskها، افزونهها و اسکریپتهای شخص ثالث را بررسی کنید.
- اگر CLS بالا است، ابعاد تصاویر، فونتها، تبلیغات و محتوای پویا را اصلاح کنید.
- اگر فقط پیشخوان وردپرس کند است، کوئریها، Cron، درخواستهای خارجی و پردازشهای پسزمینه را بررسی کنید.
قبل از بهینهسازی سرعت وردپرس چه کارهایی انجام دهیم؟
بعضی تنظیمات افزایش سرعت میتوانند ظاهر صفحه، فرمها، پنل مدیریت، سبد خرید یا تسویهحساب را دچار مشکل کنند. پیش از هر تغییر باید امکان بازگشت به وضعیت قبلی را فراهم کنید.
یک نسخه پشتیبان قابل بازیابی تهیه کنید
فقط وجود فایل بکاپ کافی نیست. باید مطمئن شوید که در صورت ایجاد مشکل، امکان بازیابی فایلها و دیتابیس وجود دارد.
پیش از انجام این تغییرات، بکاپ جدید بگیرید:
- تغییر افزونه کش
- پاکسازی دیتابیس
- تغییر نسخه PHP
- ویرایش فایل
wp-config.php - تغییر تنظیمات CDN
- حذف یا Delay کردن JavaScript
- تولید Critical CSS
- تغییر قالب یا افزونههای اصلی
تغییرات پرریسک را روی Staging آزمایش کنید
اگر سایت فروشگاهی، عضویتی، پربازدید یا درآمدزا است، تغییرات مهم را ابتدا روی نسخه آزمایشی انجام دهید.
حذف CSS بلااستفاده، Delay کردن JavaScript، پاکسازی جداول دیتابیس، تغییر PHP و اصلاح Cron میتوانند روی بخشهای مختلف سایت اثر بگذارند.
چند صفحه نماینده انتخاب کنید
فقط صفحه اصلی را آزمایش نکنید. ساختار و منابع مصرفی صفحات مختلف وردپرس یکسان نیست.
حداقل این صفحات را بررسی کنید:
- صفحه اصلی
- یک مقاله طولانی
- یک صفحه خدمات
- یک صفحه ساختهشده با Elementor
- صفحه دستهبندی
- صفحه محصول
- سبد خرید
- تسویهحساب
- حساب کاربری
ممکن است صفحه اصلی سریع باشد، اما صفحات محصول بهدلیل تصاویر، فیلترها، افزونههای WooCommerce یا کوئریهای متفاوت عملکرد ضعیفی داشته باشند.
نتیجه اولیه را ثبت کنید
پیش از اعمال تغییرات، اطلاعات زیر را ذخیره کنید:
- LCP
- INP در صورت وجود داده واقعی
- CLS
- TTFB
- عنصر LCP
- حجم انتقالیافته صفحه
- تعداد درخواستها
- زمان اجرای JavaScript
- فایلها و درخواستهای کند
- وضعیت موبایل و دسکتاپ
- زمان و موقعیت جغرافیایی تست
بدون ثبت وضعیت اولیه، نمیتوان مشخص کرد کدام تغییر واقعاً مؤثر بوده است.
سرعت سایت وردپرسی را چگونه اندازهگیری کنیم؟
برای ارزیابی درست سرعت، باید داده کاربران واقعی را از نتایج آزمایشگاهی جدا کنید. تکیه بر یک امتیاز PageSpeed یا یک بار اجرای تست، تصویر کاملی از عملکرد سایت ارائه نمیدهد.
تفاوت Field Data و Lab Data
Field Data یا داده میدانی، از تجربه کاربران واقعی در دستگاهها، مرورگرها، اتصالها و موقعیتهای مختلف به دست میآید.
PageSpeed Insights این اطلاعات را از Chrome User Experience Report یا CrUX دریافت میکند. دادههای میدانی معمولاً تجربه ۲۸ روز گذشته را نشان میدهند.
اگر یک URL بازدید کافی نداشته باشد، ممکن است:
- داده کل دامنه نمایش داده شود.
- فقط داده Origin در دسترس باشد.
- هیچ Field Data برای آن URL نمایش داده نشود.
Lab Data یا داده آزمایشگاهی در یک محیط شبیهسازیشده تولید میشود. این داده برای پیدا کردن علت مشکلات بسیار مفید است؛ اما الزاماً تجربه تمام کاربران واقعی را نشان نمیدهد.
بهصورت خلاصه:
- از Field Data برای تشخیص تجربه واقعی کاربران استفاده کنید.
- از Lab Data برای عیبیابی و پیدا کردن علت مشکل استفاده کنید.
PageSpeed Insights
با PageSpeed Insights میتوانید نسخه موبایل و دسکتاپ صفحه را بررسی کنید.
این ابزار برای موارد زیر مناسب است:
- مشاهده وضعیت Core Web Vitals
- تشخیص عنصر LCP
- پیدا کردن منابع مسدودکننده رندر
- شناسایی تصاویر بزرگ
- بررسی JavaScript بلااستفاده
- مشاهده Layout Shiftها
- بررسی زمان پاسخ سرور
امتیاز Lighthouse یک شاخص تشخیصی است، نه هدف نهایی. ممکن است یک صفحه امتیاز آزمایشگاهی خوبی داشته باشد، اما کاربران واقعی همچنان تجربه ضعیفی ثبت کنند.
Google Search Console
گزارش Core Web Vitals در Search Console، صفحات دارای الگوی عملکرد مشابه را در گروههای مختلف قرار میدهد.
این گزارش برای تشخیص مشکلات گسترده مفید است؛ برای مثال:
- تمام صفحات محصول LCP ضعیفی دارند.
- مقالات یک قالب مشخص CLS بالایی دارند.
- صفحات موبایل یک نوع Template مشکل INP دارند.
Search Console معمولاً برای پیدا کردن الگوهای گسترده بهتر از بررسی تصادفی یک URL است.
Chrome DevTools
پنلهای Network و Performance در Chrome DevTools برای تحلیل دقیقتر مناسباند.
با پنل Network میتوانید موارد زیر را بررسی کنید:
- ترتیب بارگذاری فایلها
- زمان انتظار هر درخواست
- فایل آغازکننده درخواست
- منابع Render-blocking
- اولویت بارگذاری منابع
- درخواستهای خارجی کند
در پنل Performance نیز میتوانید Long Taskها، اجرای JavaScript، Layout، Paint و رفتار Main Thread را بررسی کنید.
برای آشنایی بیشتر، مستندات رسمی پنل Performance کروم را مطالعه کنید.
شرایط تست را یکسان نگه دارید
برای مقایسه قبل و بعد، شرایط تست باید تا حد امکان مشابه باشد:
- همان URL
- همان نسخه موبایل یا دسکتاپ
- همان موقعیت جغرافیایی
- همان وضعیت ورود یا خروج کاربر
- همان شرایط کش
- همان ابزار تست
نتیجه تست موبایل را با دسکتاپ یا تست کاربر مهمان را با مدیر واردشده مقایسه نکنید.
Core Web Vitals فعلی شامل چه معیارهایی است؟
Core Web Vitals فعلی شامل سه معیار LCP، INP و CLS است. معیار FID دیگر یکی از سه معیار اصلی نیست و INP جایگزین آن شده است.
| معیار | چه چیزی را اندازه میگیرد؟ | محدوده خوب |
|---|---|---|
| LCP | سرعت نمایش محتوای اصلی صفحه | حداکثر ۲.۵ ثانیه |
| INP | سرعت پاسخ صفحه به تعامل کاربر | حداکثر ۲۰۰ میلیثانیه |
| CLS | ثبات بصری و جابهجایی ناگهانی عناصر | حداکثر ۰.۱ |
این محدودهها براساس صدک ۷۵ تجربه کاربران ارزیابی میشوند. یعنی صفحه باید برای بخش عمده کاربران، نه فقط در بهترین شرایط آزمایشگاهی، عملکرد مناسبی داشته باشد.
برای مشاهده تعریف رسمی این معیارها، راهنمای Core Web Vitals در web.dev را بررسی کنید.
Core Web Vitals مهم هستند؛ اما تمام تجربه کاربر را پوشش نمیدهند. امنیت، دسترسپذیری، کیفیت محتوا، عملکرد فرمها و سلامت فرایند خرید نیز اهمیت دارند.
چگونه علت کندی سایت وردپرسی را پیدا کنیم؟
پیش از اجرای راهحل، نشانه اصلی را مشخص کنید. هر نوع کندی میتواند علت متفاوتی داشته باشد.
| نشانه | علتهای محتمل | اولین بررسی |
|---|---|---|
| TTFB بالا | هاست، PHP، دیتابیس، Page Cache، پردازش سنگین | زمان انتظار سند HTML |
| LCP ضعیف | تصویر اصلی، TTFB، CSS، فونت یا تأخیر کشف منبع | عنصر LCP و اجزای زمان آن |
| INP ضعیف | JavaScript سنگین، افزونهها، DOM بزرگ یا اسکریپت خارجی | Long Taskها و تعامل کند |
| CLS بالا | تصویر بدون ابعاد، فونت، تبلیغ یا محتوای تزریقشده | Layout Shiftها |
| پیشخوان وردپرس کند است | کوئریها، Cron، API خارجی، افزونه یا Heartbeat | Query Monitor و لاگها |
| فقط صفحات محصول کند هستند | کوئری محصول، فیلتر، افزونه WooCommerce یا تصاویر | صفحه محصول و درخواستهای WooCommerce |
| فقط کاربران یک منطقه مشکل دارند | فاصله سرور، DNS، CDN یا مسیر شبکه | تست از چند موقعیت |
| سرعت بعد از ورود کاهش مییابد | نسخه بدون کش و درخواستهای شخصیسازیشده | تست کاربر واردشده |
| سرعت در ساعات شلوغ کاهش مییابد | محدودیت CPU، RAM، PHP Worker یا دیتابیس | مصرف منابع در ساعات شلوغ |
| پس از نصب افزونه سایت کند شده است | فایلهای Front-end، کوئری، Cron یا درخواست خارجی | مقایسه قبل و بعد و Query Monitor |
این جدول جای تحلیل فنی را نمیگیرد، اما کمک میکند نقطه شروع منطقیتری انتخاب کنید.
چگونه TTFB و پاسخگویی سرور را بهبود دهیم؟
TTFB مدتزمان بین شروع درخواست مرورگر و دریافت اولین بایت پاسخ است. اگر سند HTML دیر دریافت شود، بارگذاری CSS، JavaScript، فونتها و تصاویر نیز دیرتر آغاز خواهد شد.
به همین دلیل، TTFB بالا میتواند LCP را نیز ضعیف کند.
ابتدا درخواست اصلی HTML را بررسی کنید
در پنل Network مرورگر، درخواست اصلی صفحه را پیدا کنید. معمولاً نوع آن Document است.
اگر بخش Waiting یا Server Response Time طولانی باشد، مشکل احتمالاً فقط از تصاویر یا CSS نیست و باید سرور و پردازش وردپرس بررسی شود.
هاست را براساس نیاز واقعی سایت ارزیابی کنید
نام تجاری هاست یا عبارت «هاست وردپرس» بهتنهایی معیار کافی نیست.
موارد زیر را بررسی کنید:
- منابع CPU و RAM
- محدودیت پردازش همزمان
- تعداد PHP Workerها
- نوع و سرعت دیسک
- عملکرد MySQL یا MariaDB
- نسخه PHP
- Page Cache در سطح سرور
- پشتیبانی از Object Cache
- فاصله جغرافیایی سرور تا کاربران
- امکان ساخت Staging و بکاپ
اگر TTFB فقط در ساعات پرترافیک افزایش پیدا میکند، محدودیت منابع، تعداد کم PHP Worker یا ازدحام سرور میتواند عامل اصلی باشد.
نسخههای نرمافزار را بهروز نگه دارید
نسخههای جدید WordPress، PHP، قالب و افزونهها معمولاً شامل اصلاحات امنیتی، رفع خطا و بهبودهای عملکرد هستند.
با این حال، بهروزرسانی باید پس از بکاپ و بررسی سازگاری انجام شود. استفاده از نسخه جدید PHP بدون بررسی افزونهها و قالب میتواند خطا ایجاد کند.
Page Cache را فعال کنید
وردپرس برای تولید یک صفحه پویا ممکن است PHP را اجرا کند و چندین درخواست به دیتابیس بفرستد.
Page Cache نسخه آماده HTML را ذخیره میکند تا برای بازدیدهای بعدی، پردازش کامل دوباره انجام نشود.
این قابلیت معمولاً برای صفحات عمومی مانند مقالات، برگههای خدمات و صفحات دستهبندی تأثیر قابل توجهی دارد.
برای شناخت انواع کش، میتوانید راهنمای رسمی کش وردپرس را مطالعه کنید.
OPcache را بررسی کنید
PHP برای اجرای فایلها ابتدا کد را پردازش و کامپایل میکند. OPcache نسخه کامپایلشده کد PHP را در حافظه نگه میدارد تا این فرایند در هر درخواست از ابتدا تکرار نشود.
در بیشتر هاستهای مدیریتشده، OPcache از قبل فعال است. برای بررسی وضعیت آن میتوانید از پشتیبانی هاست سؤال کنید.
Object Cache را فقط در شرایط مناسب فعال کنید
Object Cache نتیجه بعضی کوئریها و دادههای پرتکرار را ذخیره میکند. این قابلیت با Page Cache یکسان نیست.
Object Cache پایدار مانند Redis یا Memcached میتواند برای این سایتها مفید باشد:
- سایتهای فروشگاهی
- سایتهای عضویتی
- سایتهای پرترافیک
- سایتهای دارای کوئریهای پرتکرار
- سایتهایی که کاربران واردشده زیادی دارند
فعالسازی Redis بدون پیکربندی صحیح الزاماً سرعت سایت را بهتر نمیکند. ابتدا باید مشخص شود که کندی واقعاً از کوئریها و دسترسی مکرر به دادههاست.
درخواستهای خارجی سرور را بررسی کنید
برخی افزونهها هنگام تولید صفحه به API خارجی متصل میشوند. اگر سرویس مقصد کند یا در دسترس نباشد، پاسخ وردپرس نیز ممکن است به تأخیر بیفتد.
نمونهها:
- بررسی لایسنس افزونه
- دریافت نرخ ارز
- همگامسازی محصول
- اتصال به CRM
- استعلام سرویس حملونقل
- اتصال به ابزارهای امنیتی
با Query Monitor میتوانید درخواستهای HTTP خارجی و زمان اجرای آنها را بررسی کنید.
چگونه LCP را در وردپرس بهبود دهیم؟
LCP زمان نمایش بزرگترین عنصر محتوایی قابل مشاهده در اولین Viewport را اندازهگیری میکند.
این عنصر معمولاً یکی از موارد زیر است:
- تصویر Hero
- تصویر شاخص مقاله
- بنر اصلی
- تیتر بزرگ
- یک بلوک متنی
- پوستر یا فریم ابتدایی ویدئو
ابتدا عنصر LCP را پیدا کنید
در PageSpeed Insights یا Chrome DevTools بررسی کنید عنصر LCP دقیقاً چیست.
تا زمانی که این عنصر را نشناسید، ممکن است زمان زیادی برای بهینهسازی تصویری صرف کنید که هیچ تأثیری روی LCP ندارد.
LCP از چه بخشهایی تشکیل میشود؟
زمان LCP را میتوان به چهار بخش تقسیم کرد:
| بخش | توضیح | مشکل رایج در وردپرس |
|---|---|---|
| TTFB | زمان دریافت اولین بایت HTML | هاست، PHP، دیتابیس یا نبود Page Cache |
| Resource Load Delay | فاصله دریافت HTML تا شروع دانلود منبع LCP | تصویر در CSS، Lazy Load یا کشف دیرهنگام |
| Resource Load Duration | زمان دانلود منبع LCP | فایل بزرگ، سرور دور یا اتصال ضعیف |
| Element Render Delay | فاصله پایان دانلود تا نمایش کامل عنصر | CSS، JavaScript، انیمیشن یا Main Thread شلوغ |
برای بهبود LCP نباید فقط روی حجم تصویر تمرکز کرد. در بسیاری از صفحات، تأخیر در شروع دانلود تصویر یا تأخیر رندر، مشکل مهمتری است.
راهنمای بهینهسازی LCP در web.dev این چهار بخش را با جزئیات بیشتری توضیح میدهد.
اگر عنصر LCP تصویر است
این موارد را بررسی کنید:
- ابعاد فایل متناسب با اندازه نمایش باشد.
- فرمت تصویر برای نوع محتوا مناسب باشد.
- فشردهسازی با کیفیت قابل قبول انجام شود.
- ویژگیهای
widthوheightوجود داشته باشند. - تصویر از HTML اولیه قابل کشف باشد.
- تصویر اصلی صفحه Lazy Load نشده باشد.
- منابع کماهمیت، دانلود آن را عقب نیندازند.
- در صورت نیاز، اولویت بارگذاری مناسبی داشته باشد.
تصویر داخل اولین Viewport و عنصر LCP نباید بهصورت عمومی Lazy Load شود.
یک تصویر نباید همزمان دارای loading="lazy" و fetchpriority="high" باشد؛ زیرا این دو دستور هدف متفاوتی دارند.
تصویر LCP را در CSS پنهان نکنید
اگر تصویر اصلی صفحه بهصورت Background Image در یک فایل CSS تعریف شده باشد، مرورگر ابتدا باید HTML و CSS را دریافت و پردازش کند تا متوجه وجود تصویر شود.
در بسیاری از صفحات، قرار دادن تصویر اصلی با تگ
Preload را محدود استفاده کنید
Preload زمانی مفید است که یک منبع مهم، مانند تصویر LCP یا فونت اصلی، دیر کشف شود.
Preload کردن تعداد زیادی فایل میتواند با منابع اصلی رقابت ایجاد کند.
قبل از افزودن Preload بررسی کنید:
- منبع واقعاً در اولین نمایش لازم است.
- مرورگر آن را بهصورت طبیعی زود پیدا نمیکند.
- Preload تکراری ایجاد نشده است.
- نوع فایل و ویژگیهای Preload صحیح هستند.
CSS مسدودکننده رندر را بررسی کنید
اگر مرورگر پیش از نمایش محتوای اصلی مجبور باشد فایلهای CSS بزرگ و متعدد را پردازش کند، LCP عقب میافتد.
راهحل ممکن است شامل این موارد باشد:
- حذف CSS بلااستفاده
- بارگذاری شرطی استایلها
- کاهش استایل افزونهها
- تولید Critical CSS با تست دقیق
- کاهش پیچیدگی بخش بالای صفحه
Critical CSS یا حذف CSS بلااستفاده ممکن است ظاهر بعضی صفحات را بههم بزند. این تغییرات را روی Staging آزمایش کنید.
Element Render Delay را فراموش نکنید
گاهی تصویر LCP دانلود شده است، اما بهدلیل اجرای JavaScript، انیمیشن ورودی، CSS یا شلوغ بودن Main Thread دیر نمایش داده میشود.
مواردی مانند Preloader، Fade-in، Slider و انیمیشن Hero میتوانند نمایش عنصر اصلی را عقب بیندازند.
چگونه INP را در وردپرس بهبود دهیم؟
INP پاسخگویی صفحه را در طول حضور کاربر بررسی میکند.
تعاملهای زیر میتوانند در INP اثر داشته باشند:
- باز کردن منوی موبایل
- انتخاب گزینه محصول
- اعمال فیلتر
- باز کردن Popup
- ارسال فرم
- افزودن محصول به سبد
- تغییر تعداد محصول
- باز کردن Accordion
هر تعامل از چه بخشهایی تشکیل میشود؟
زمان یک تعامل را میتوان به سه بخش تقسیم کرد:
| بخش | توضیح | علت احتمالی |
|---|---|---|
| Input Delay | زمان انتظار تا شروع اجرای Event Handler | Long Task یا Main Thread شلوغ |
| Processing Duration | زمان اجرای کد مرتبط با تعامل | JavaScript سنگین یا محاسبات زیاد |
| Presentation Delay | زمان لازم برای نمایش نتیجه تعامل | DOM بزرگ، Layout یا Paint سنگین |
برای بررسی دقیقتر، راهنمای بهینهسازی INP در web.dev را مطالعه کنید.
JavaScript سنگین را پیدا کنید
در پنل Performance مرورگر، Long Taskها را بررسی کنید.
یک فایل JavaScript ممکن است سریع دانلود شود، اما اجرای آن Main Thread را برای مدت طولانی مشغول کند.
منابع رایج JavaScript سنگین در وردپرس عبارتاند از:
- اسلایدرها
- Popupها
- چت آنلاین
- Heatmapها
- اسکریپتهای تبلیغاتی
- ویدئوهای Embed
- افزونههای صفحهساز
- Add-onهای Elementor
- فیلترهای پیچیده محصولات
- چند ابزار آمارگیری همزمان
اسکریپتهای غیرضروری را حذف کنید
Delay کردن یک فایل غیرضروری بهتر از حذف آن نیست.
ابتدا بررسی کنید قابلیت موردنظر واقعاً استفاده میشود یا خیر. اگر یک افزونه فقط برای یک Widget کوچک نصب شده است، جایگزینی آن با راهحل سبکتر ممکن است منطقیتر از تنظیم Delay JavaScript باشد.
اسکریپتها را براساس نیاز هر صفحه بارگذاری کنید
فایل فرم تماس نباید در تمام صفحات سایت بارگذاری شود. فایل اسلایدر نیز نباید روی صفحهای اجرا شود که هیچ اسلایدری ندارد.
بارگذاری شرطی منابع میتواند مؤثرتر از ترکیب تمام فایلها در یک Bundle بزرگ باشد؛ مخصوصاً در HTTP/2 و HTTP/3 که تعداد درخواستها تنها معیار تصمیمگیری نیست.
Long Taskها را به بخشهای کوچکتر تقسیم کنید
اگر یک پردازش JavaScript برای مدت طولانی Main Thread را اشغال کند، مرورگر نمیتواند سریع به تعامل کاربر پاسخ دهد.
در توسعه اختصاصی میتوان پردازشهای طولانی را به بخشهای کوچکتر تقسیم کرد تا مرورگر بین آنها فرصت پاسخگویی داشته باشد.
اندازه DOM را کاهش دهید
ساختار بسیار بزرگ و تودرتوی HTML میتواند هزینه Style Calculation، Layout و Paint را افزایش دهد.
این مشکل در صفحاتی که با چند Add-on و Containerهای تودرتو ساخته شدهاند بیشتر دیده میشود.
منابع شخص ثالث را محدود کنید
اسکریپتهای خارجی تحت کنترل کامل سایت نیستند. هر ابزار جدید میتواند درخواست شبکه، پردازش JavaScript و Cookie بیشتری اضافه کند.
برای هر منبع خارجی این پرسشها را مطرح کنید:
- آیا داده آن واقعاً استفاده میشود؟
- آیا ابزار دیگری همان کار را انجام میدهد؟
- آیا میتوان آن را بعد از رضایت یا تعامل کاربر بارگذاری کرد؟
- آیا میتوان Embed کامل را با یک تصویر یا Facade جایگزین کرد؟
چگونه CLS را کاهش دهیم؟
CLS جابهجایی ناگهانی عناصر صفحه را اندازهگیری میکند.
حرکت ناگهانی دکمه، متن، تصویر یا فرم میتواند باعث کلیک اشتباه و تجربه نامناسب شود.
برای تصاویر ابعاد مشخص کنید
تگ تصویر باید ویژگیهای width و height داشته باشد تا مرورگر پیش از دانلود فایل، فضای موردنیاز را رزرو کند.
<img
src="wordpress-speed-report.webp"
width="800"
height="600"
alt="نمایش گزارش سرعت سایت وردپرسی">در طراحی Responsive، CSS میتواند اندازه نمایش را تغییر دهد؛ اما نسبت ابعاد باید از ابتدا برای مرورگر مشخص باشد.
برای تبلیغات و محتوای پویا فضا رزرو کنید
بنر، ویدئو، نقشه، فرم، ابزار چت و محتوای Ajax نباید بدون فضای رزروشده وارد صفحه شوند و سایر محتواها را جابهجا کنند.
برای این عناصر میتوان از موارد زیر استفاده کرد:
- ابعاد ثابت یا حداقل ارتفاع
- نسبت تصویر
- Placeholder
- Skeleton با اندازه نهایی مشخص
رفتار فونت را کنترل کنید
فونت وب ممکن است پس از نمایش متن اولیه جایگزین شود و ابعاد متن را تغییر دهد.
اقدامات مناسب:
- استفاده از WOFF2
- حذف وزنهای بلااستفاده
- تعریف
font-displayمناسب - Preload محدود فونت اصلی
- انتخاب Fallback نزدیک به فونت نهایی
- میزبانی محلی فونت در صورت مناسب بودن شرایط
راهنمای بهینهسازی فونتها در web.dev روشهای اصلی کاهش تأخیر و جابهجایی متن را توضیح میدهد.
محتوای جدید را بالای محتوای موجود تزریق نکنید
نوار اطلاعرسانی، پیشنهاد ویژه یا پیام Cookie که بعد از بارگذاری بالای صفحه ظاهر میشود، ممکن است تمام صفحه را به پایین منتقل کند.
فضای این عناصر را از ابتدا رزرو کنید یا آنها را بهصورت Overlay نمایش دهید.
تصاویر و ویدئوهای وردپرس را چگونه بهینه کنیم؟
هدف، تولید کوچکترین فایل ممکن نیست. تصویر باید با کمترین حجم منطقی، کیفیت مناسب و ابعاد درست تحویل داده شود.
فرمت را براساس نوع تصویر انتخاب کنید
- JPEG: مناسب عکسهایی با جزئیات و رنگ زیاد
- PNG: مناسب شفافیت یا تصاویر نیازمند فشردهسازی Lossless
- WebP: مناسب بسیاری از عکسها و تصاویر وب
- AVIF: دارای ظرفیت فشردهسازی بالا، با نیاز به بررسی کیفیت و زمان پردازش
- SVG: مناسب آیکون و گرافیک برداری قابل اعتماد
هیچ فرمتی در تمام تصاویر بهترین نیست. خروجی WebP و AVIF را با تصویر اصلی مقایسه کنید و فقط براساس پسوند فایل تصمیم نگیرید.
تصویر را بزرگتر از نیاز ارسال نکنید
اگر تصویر با عرض ۸۰۰ پیکسل نمایش داده میشود، ارسال فایل ۳۰۰۰ پیکسلی معمولاً منابع اضافه مصرف میکند.
وردپرس برای تصاویر آپلودشده اندازههای مختلف تولید میکند. قالب باید srcset و sizes را بهدرستی استفاده کند تا مرورگر نسخه متناسب با نمایشگر را انتخاب کند.
Lazy Loading را برای تصاویر خارج از صفحه استفاده کنید
تصاویر پایین صفحه و iframeهای خارج از Viewport میتوانند Lazy Load شوند.
تصویر اصلی بالای صفحه و عنصر LCP را از Lazy Loading عمومی مستثنا کنید.
تصاویر تزئینی غیرضروری را حذف کنید
هر تصویر ارزش یکسانی ندارد. بعضی تصاویر فقط حجم صفحه را افزایش میدهند و کمکی به درک محتوا نمیکنند.
تصاویر آموزشی، اسکرینشات ابزارها و نمودارهای اختصاصی معمولاً از تصاویر تزئینی عمومی ارزش بیشتری دارند.
ویدئو را مستقیماً روی هاست معمولی قرار ندهید
ویدئوهای بزرگ میتوانند پهنای باند، فضای سرور و منابع زیادی مصرف کنند.
استفاده از سرویس ویدئویی یا زیرساخت مناسب پخش، در بسیاری از سایتها انتخاب عملیتری است.
برای Embedهای YouTube یا سرویسهای مشابه میتوان ابتدا تصویر Preview را نمایش داد و Player را پس از تعامل کاربر بارگذاری کرد.
کش وردپرس چگونه کار میکند؟
کش یک قابلیت واحد نیست. چند لایه مختلف کش میتوانند در کنار هم فعالیت کنند.
| نوع کش | چه چیزی ذخیره میشود؟ | کاربرد اصلی |
|---|---|---|
| Browser Cache | CSS، JavaScript، تصویر و فونت | کاهش دانلود در بازدیدهای بعدی |
| Page Cache | HTML آماده صفحه | کاهش اجرای PHP و کوئریها |
| Object Cache | نتیجه دادهها و آبجکتها | کاهش درخواستهای تکراری دیتابیس |
| Opcode Cache | کد کامپایلشده PHP | کاهش پردازش PHP |
| CDN Cache | فایل یا صفحه در Edge | کاهش فاصله و بار Origin |
فقط یک سیستم اصلی Page Cache داشته باشید
فعالکردن چند افزونه کش کامل میتواند باعث تداخل در این قابلیتها شود:
- Page Cache
- Minify
- Lazy Load
- Critical CSS
- Delay JavaScript
- پاکسازی کش
اگر هاست در سطح سرور Page Cache ارائه میدهد، پیش از نصب افزونه جدید مشخص کنید مسئولیت هر لایه با کدام ابزار است.
Cache Headerهای فایلهای استاتیک را بررسی کنید
فایلهایی مانند تصاویر، CSS، JavaScript و فونتها معمولاً باید برای مدت مناسبی در مرورگر ذخیره شوند.
Headerهایی مانند Cache-Control مشخص میکنند مرورگر تا چه زمانی میتواند از نسخه ذخیرهشده استفاده کند.
پس از هر تغییر کش را کامل پاک کنید
ممکن است نسخه قدیمی فایلها در یکی از این لایهها باقی مانده باشد:
- افزونه وردپرس
- سرور
- Object Cache
- CDN
- مرورگر
هنگام عیبیابی، لایههای مرتبط را پاک کنید و نتیجه را در پنجره ناشناس بررسی کنید.
کش در WooCommerce چه محدودیتهایی دارد؟
صفحات فروشگاهی همیشه مانند یک مقاله ثابت نیستند. سبد خرید، حساب کاربری، تسویهحساب و بعضی بخشهای محصول برای هر کاربر داده متفاوتی نمایش میدهند.
صفحات زیر باید از Page Cache عمومی مستثنا شوند:
- Cart
- My Account
- Checkout
بسته به سیستم کش، Sessionها و Cookieهای WooCommerce نیز ممکن است نیاز به تنظیمات مخصوص داشته باشند.
راهنمای رسمی تنظیم کش WooCommerce باید مبنای تنظیم صفحات پویا باشد.
پس از تغییر تنظیمات کش، این مسیرها را آزمایش کنید:
- افزودن محصول ساده به سبد
- افزودن محصول متغیر
- تغییر تعداد محصول
- حذف محصول
- اعمال کد تخفیف
- ورود و خروج کاربر
- بازیابی رمز عبور
- انتخاب روش ارسال
- انتخاب درگاه پرداخت
- ثبت سفارش آزمایشی
- نمایش صحیح موجودی و قیمت
بهبود امتیاز PageSpeed نباید به قیمت خراب شدن فرایند خرید تمام شود.
CSS و JavaScript را چگونه بهینه کنیم؟
حذف منابع غیرضروری معمولاً از فشردهسازی منابعی که استفاده نمیشوند مؤثرتر است.
Minify با حذف فایل فرق دارد
Minify فاصلهها، توضیحات و کاراکترهای غیرضروری را کاهش میدهد؛ اما کد بلااستفاده همچنان دانلود و اجرا میشود.
اولویت منطقی:
- حذف قابلیت یا فایل غیرضروری
- بارگذاری شرطی منابع
- کاهش وابستگیها
- Minify
- Defer یا Delay با تست
- ترکیب فایل فقط در صورت اثبات اثر مثبت
تمام فایلها را بدون بررسی ترکیب نکنید
ترکیب کامل CSS و JavaScript ممکن است یک فایل بزرگ ایجاد کند. با هر تغییر کوچک نیز کل فایل باید دوباره دانلود و کش شود.
در HTTP/2 و HTTP/3، ترکیب فایلها همیشه مزیت قطعی ندارد. تصمیم باید براساس Waterfall و تست قبل و بعد گرفته شود.
Defer و Delay را با هم اشتباه نگیرید
- Defer: دانلود فایل را متوقف نمیکند، اما اجرای آن را تا پایان پردازش HTML عقب میاندازد.
- Delay: بارگذاری یا اجرای فایل را تا تعامل کاربر یا زمان مشخص به تأخیر میاندازد.
Delay کردن فایلهای ضروری میتواند منو، فرم، فیلتر، Slider، Analytics یا درگاه پرداخت را خراب کند.
CSS بلااستفاده را با احتیاط حذف کنید
ابزارهای Remove Unused CSS ممکن است بعضی کلاسهای پویا را تشخیص ندهند.
اجزایی مانند Popup، منوی موبایل، Tab، Accordion و محتوای Ajax ممکن است در تست اولیه دیده نشوند؛ اما بعداً به CSS خود نیاز داشته باشند.
پس از تغییر فایلها چه چیزهایی را تست کنیم؟
- منوی موبایل
- فرمها
- Popupها
- اسلایدر
- جستوجوی سایت
- فیلتر محصول
- افزودن به سبد
- تسویهحساب
- درگاه پرداخت
- Tracking و Analytics
- نمایش کاربران واردشده
- خطاهای Console
فونتهای سایت را چگونه سبکتر کنیم؟
در سایتهای فارسی، یک خانواده فونت ممکن است شامل چندین وزن و فایل باشد.
بارگذاری وزنهایی که در طراحی استفاده نمیشوند، حجم و درخواست اضافی ایجاد میکند.
اقدامات مناسب:
- یک یا دو خانواده فونت انتخاب کنید.
- فقط وزنهای استفادهشده را نگه دارید.
- فایلها را با فرمت WOFF2 ارائه دهید.
- فونتهای مهم را در صورت مناسب بودن شرایط محلی میزبانی کنید.
font-displayمناسب تعریف کنید.- فقط فونت واقعاً حیاتی را Preload کنید.
- Fallback نزدیک به فونت اصلی انتخاب کنید.
Preload کردن تمام وزنهای فونت نتیجه معکوس دارد و میتواند با تصویر LCP و سایر منابع مهم رقابت کند.
در سایت فارسی بررسی کنید که آیا فونت شامل نویسهها و وزنهایی است که واقعاً در سایت استفاده میشوند یا خیر.
افزونهها چگونه سرعت وردپرس را کاهش میدهند؟
تعداد افزونهها بهتنهایی معیار دقیقی نیست. یک افزونه کوچک اما بدطراحی میتواند از چند افزونه سبک اثر منفی بیشتری داشته باشد.
افزونه را براساس اثر واقعی ارزیابی کنید
این موارد را بررسی کنید:
- کوئریهای دیتابیس
- درخواستهای خارجی
- فایلهای CSS و JavaScript
- کارهای زمانبندیشده
- پردازشهای پسزمینه
- حجم دادههای Autoload
- خطاها و Warningهای PHP
- بارگذاری منابع در صفحات غیرمرتبط
Query Monitor میتواند برای مشاهده کوئریها، Hookها، درخواستهای HTTP و خطاهای PHP مفید باشد.
ابزارهای Debug را فقط هنگام بررسی فعال کنید و پس از پایان کار غیرفعال کنید.
قابلیتهای تکراری را حذف کنید
ممکن است چند افزونه همزمان این قابلیتها را داشته باشند:
- Lazy Loading
- Minify
- تولید WebP
- Redirect
- Schema
- Backup
- Firewall
- Analytics
- SMTP
مشخص کنید هر مسئولیت بر عهده کدام ابزار است.
برای انتخاب ابزار متناسب با نوع سایت، مقاله بهترین افزونههای وردپرس را بررسی کنید.
افزونه غیرفعال را حذف کنید
افزونه غیرفعال معمولاً فایلهای Front-end خود را اجرا نمیکند؛ اما نگه داشتن افزونههای بلااستفاده میتواند مدیریت، امنیت و فرایند بهروزرسانی سایت را پیچیدهتر کند.
پس از اطمینان از نیاز نداشتن به افزونه و تهیه بکاپ، آن را حذف کنید.
قالب و Elementor را چگونه بهینه کنیم؟
کندی سایت Elementor الزاماً فقط از خود Elementor نیست. قالب، Add-onها، ساختار صفحه، تصاویر، فونتها، انیمیشنها و اسکریپتهای خارجی نیز مؤثرند.
ساختار صفحه را ساده کنید
- Containerهای غیرضروری را حذف کنید.
- از Nesting عمیق پرهیز کنید.
- Widgetهای تکراری را کاهش دهید.
- Slider و Motion Effect را فقط در صورت نیاز استفاده کنید.
- Popupهای متعدد را حذف کنید.
- نسخه موبایل را مستقل بررسی کنید.
Add-onهای Elementor را ارزیابی کنید
بعضی بستههای Add-on دهها Widget دارند، در حالی که سایت فقط از چند مورد استفاده میکند.
بررسی کنید:
- آیا امکان غیرفعال کردن Widgetهای بلااستفاده وجود دارد؟
- آیا فایلهای بسته در تمام صفحات بارگذاری میشوند؟
- آیا همان قابلیت با Elementor یا کد سبکتر قابل اجراست؟
Header و Footer را فراموش نکنید
مشکل همیشه از محتوای اصلی صفحه نیست.
Mega Menu، آیکونها، جستوجوی زنده، Popup، چت و Scriptهای Header در تمام صفحات تکرار میشوند و میتوانند اثر گستردهای داشته باشند.
انیمیشنهای ورودی را محدود کنید
انیمیشنهای زیاد میتوانند زمان نمایش محتوا، Main Thread و تجربه کاربران موبایل را تحت تأثیر قرار دهند.
بهخصوص برای تصویر و تیتر اصلی صفحه، نمایش مستقیم معمولاً بهتر از Fade-in یا انیمیشن طولانی است.
دیتابیس وردپرس را چگونه بهینه کنیم؟
دیتابیس بزرگ الزاماً دیتابیس کند نیست. مشکل زمانی ایجاد میشود که کوئریها، Indexها، دادههای Autoload یا جداول افزونهها بهشکل نامناسب مدیریت شوند.
دادههای قابل بررسی
- Revisionهای قدیمی
- Transientهای منقضی
- نظرات Spam و Trash
- جداول افزونههای حذفشده
- Sessionهای قدیمی
- صفهای پردازش
- دادههای Log
- گزینههای Autoload حجیم
Autoload Options را بررسی کنید
بعضی تنظیمات قالبها و افزونهها در هر بار بارگذاری وردپرس بهصورت خودکار از دیتابیس خوانده میشوند.
اگر حجم دادههای Autoload بیش از حد افزایش پیدا کند، میتواند پاسخگویی وردپرس را کندتر کند.
قبل از حذف یا تغییر یک Option باید مشخص شود متعلق به کدام افزونه یا قابلیت است. حذف تصادفی دادههای Autoload میتواند تنظیمات سایت را خراب کند.
پیش از پاکسازی بکاپ بگیرید
حذف جدول یا Option ممکن است برگشتناپذیر باشد. نام ناشناخته یک جدول به این معنا نیست که دیگر استفاده نمیشود.
برای اجرای ایمنتر پاکسازی، آموزش Advanced Database Cleaner و پاکسازی دیتابیس وردپرس را مطالعه کنید.
پاکسازی را با افزایش سرعت قطعی اشتباه نگیرید
حذف چند Revision ممکن است حجم دیتابیس را کاهش دهد؛ اما اگر کندی از JavaScript یا TTFB سرور باشد، تأثیر قابل توجهی در Front-end ایجاد نمیکند.
پاکسازی باید براساس علت واقعی انجام شود، نه فقط برای کاهش عدد حجم دیتابیس.
WP-Cron و پردازشهای پسزمینه را چگونه مدیریت کنیم؟
بکاپگیری، ارسال ایمیل، همگامسازی محصولات، اسکن امنیتی، ساخت گزارش و پردازش فیدها ممکن است در پسزمینه اجرا شوند.
اگر چند کار سنگین همزمان اجرا شود، پاسخگویی سرور کاهش پیدا میکند.
موارد زیر را بررسی کنید:
- تعداد رویدادهای زمانبندیشده
- رویدادهای تکراری یا بدون مالک
- مدت اجرای هر پردازش
- زمان اجرای بکاپ و اسکن
- صفهای Action Scheduler در WooCommerce
- Jobهای ناموفق یا معلق
آیا باید WP-Cron را به Cron واقعی منتقل کنیم؟
WP-Cron هنگام دریافت بازدید بررسی میکند آیا رویدادی باید اجرا شود یا خیر.
در سایتهای پرترافیک یا سایتهایی با پردازشهای متعدد، استفاده از Cron واقعی سرور میتواند اجرای وظایف را قابلکنترلتر کند.
با این حال، نباید WP-Cron را بدون ساخت جایگزین غیرفعال کنید. در غیر این صورت، انتشار زمانبندیشده، ایمیلها، پاکسازیها یا وظایف افزونهها ممکن است اجرا نشوند.
کارهای سنگین را در صورت امکان به ساعات کمترافیک منتقل کنید.
CDN چه زمانی برای وردپرس مفید است؟
CDN فایلها یا صفحات کششده را از نقاطی نزدیکتر به کاربران تحویل میدهد.
اثر آن به پراکندگی کاربران، محل سرور، تنظیمات کش، کیفیت شبکه و نوع محتوا بستگی دارد.
CDN احتمالاً مفید است اگر:
- کاربران در چند کشور قرار دارند.
- تصاویر و فایلهای استاتیک زیادی دارید.
- سرور از کاربران اصلی فاصله زیادی دارد.
- ترافیک بالا یا ناگهانی دارید.
- به WAF یا کنترل بیشتر در Edge نیاز دارید.
CDN ممکن است اثر محدودی داشته باشد اگر:
- بیشتر کاربران و سرور در یک منطقه نزدیک هستند.
- TTFB بهدلیل PHP یا دیتابیس بالا است.
- Cache Ruleها اشتباه تنظیم شدهاند.
- منابع اصلی از دامنههای خارجی دیگر بارگذاری میشوند.
- مسیر اتصال CDN برای کاربران هدف مناسب نیست.
CDN جایگزین هاست مناسب، کش صحیح یا اصلاح کد سنگین نیست.
بعد از فعالسازی CDN بررسی کنید
- فایلها واقعاً از CDN تحویل داده شوند.
- Headerهای Cache درست باشند.
- محتوای قدیمی پس از تغییر پاک شود.
- صفحات پویا اشتباهی کش نشوند.
- SSL یا Redirect Loop ایجاد نشده باشد.
- زمان پاسخ کاربران اصلی بهتر شده باشد.
کدام تنظیمات سرور میتوانند بر سرعت وردپرس اثر بگذارند؟
بخشی از عملکرد سایت خارج از تنظیمات افزونه کش قرار دارد و باید در سطح سرور بررسی شود.
فشردهسازی Brotli یا Gzip
فشردهسازی انتقال میتواند حجم فایلهای متنی مانند HTML، CSS و JavaScript را کاهش دهد.
معمولاً سرور یا CDN یکی از روشهای Brotli یا Gzip را براساس پشتیبانی مرورگر استفاده میکند.
فعالکردن چند سیستم فشردهسازی روی یک پاسخ لازم نیست. مهم این است که فایلها واقعاً با Header مناسب تحویل داده شوند.
HTTP/2 و HTTP/3
نسخههای جدید HTTP میتوانند مدیریت همزمان درخواستها را بهتر کنند.
با وجود HTTP/2 یا HTTP/3، توصیه قدیمی ترکیب تمام فایلها در یک فایل بزرگ همیشه بهترین انتخاب نیست.
PHP Worker
PHP Worker درخواستهای پویا را پردازش میکند. اگر تعداد درخواستهای همزمان بیشتر از ظرفیت Workerها باشد، درخواستها در صف قرار میگیرند.
این موضوع در سایتهای WooCommerce، عضویتی و کاربران واردشده اهمیت بیشتری دارد؛ زیرا بسیاری از صفحات آنها Page Cache عمومی دریافت نمیکنند.
خطاها و Logهای PHP
خطاهای تکراری PHP میتوانند پردازش و حجم فایلهای Log را افزایش دهند.
فایلهای Log را بررسی کنید، علت خطاها را برطرف کنید و نمایش خطا روی سایت زنده را غیرفعال نگه دارید.
امنیت چه ارتباطی با سرعت سایت دارد؟
باتها، Brute Force، اسکن فایل، درخواستهای نامعتبر و حملات میتوانند منابع سرور را مصرف کنند.
از طرف دیگر، افزونههای امنیتی با اسکن دائمی یا ثبت Log زیاد نیز ممکن است بار ایجاد کنند.
راهحل مناسب حذف امنیت نیست. باید موارد زیر بررسی شوند:
- زمانبندی اسکنها
- حجم و مدت نگهداری Log
- تعداد درخواستهای مسدودشده
- محل اجرای Firewall
- ترافیک باتها
- حملات به صفحه ورود
برای تنظیمات امنیتی، مقاله بهینهسازی امنیت سایت وردپرسی را مطالعه کنید.
Performance Budget چیست و چرا به آن نیاز داریم؟
Performance Budget یا بودجه عملکرد، محدودیتی است که پیش از طراحی یا توسعه برای منابع صفحه تعیین میشود.
هدف این نیست که یک عدد ثابت را برای تمام سایتها اجرا کنیم. هر پروژه باید براساس کاربران، قابلیتها و زیرساخت خود بودجه مناسبی داشته باشد.
موارد قابل کنترل در بودجه عملکرد:
- حجم JavaScript اولیه
- حجم CSS اولیه
- حجم تصویر Hero
- تعداد خانواده و وزنهای فونت
- تعداد اسکریپتهای شخص ثالث
- تعداد ابزارهای Analytics و تبلیغات
- تعداد درخواستهای اولیه
- پیچیدگی DOM
- هدف LCP، INP و CLS
برای مثال، قبل از اضافه کردن یک ابزار چت جدید باید مشخص شود چه مقدار JavaScript، Cookie و پردازش به صفحه اضافه میکند و آیا ارزش تجاری آن بیشتر از هزینه عملکردی آن است یا خیر.
بودجه عملکرد کمک میکند سایت پس از هر تغییر کوچک دوباره سنگین نشود.
بعد از افزایش سرعت چگونه عملکرد سایت را کنترل کنیم؟
بهینهسازی سرعت یک پروژه یکباره نیست. نصب افزونه، تغییر قالب، اضافه کردن ابزار تبلیغاتی یا انتشار یک صفحه جدید میتواند عملکرد سایت را تغییر دهد.
چه زمانی دوباره تست انجام دهیم؟
پس از این تغییرات، صفحات کلیدی را بررسی کنید:
- نصب یا حذف افزونه
- تغییر قالب
- تغییر نسخه PHP
- افزودن Script تبلیغاتی
- تغییر تنظیمات کش
- فعالسازی CDN
- طراحی مجدد Header یا Hero
- افزودن Popup، Slider یا چت آنلاین
- آپدیت بزرگ WooCommerce یا Elementor
یک Change Log نگه دارید
تاریخ تغییرات مهم را ثبت کنید:
- چه چیزی تغییر کرد؟
- چه کسی تغییر را انجام داد؟
- کدام صفحات تحت تأثیر بودند؟
- نتیجه قبل و بعد چه بود؟
- آیا خطایی ایجاد شد؟
این اطلاعات هنگام افت ناگهانی Core Web Vitals یا افزایش TTFB بسیار مفید خواهند بود.
داده واقعی را در طول زمان بررسی کنید
Field Data بلافاصله بعد از تغییر بهروزرسانی نمیشود. برای مشاهده اثر کامل تغییرات باید داده کاربران واقعی طی روزها و هفتههای بعد بررسی شود.
در کنار PageSpeed، گزارش Core Web Vitals در Search Console و دادههای Analytics را نیز بررسی کنید.
اشتباهات رایج هنگام افزایش سرعت وردپرس
تمرکز روی امتیاز ۱۰۰
امتیاز کامل در یک تست آزمایشگاهی تضمین نمیکند کاربران واقعی تجربه مناسبی داشته باشند.
ابتدا Field Data، عملکرد صفحات کلیدی و سلامت قابلیتهای سایت را بررسی کنید.
اجرای چند تغییر همزمان
اگر همزمان افزونه کش، هاست، تصاویر و JavaScript را تغییر دهید، نمیتوانید اثر هر اقدام را تشخیص دهید.
نصب چند افزونه بهینهسازی
همپوشانی قابلیتها میتواند باعث تداخل کش، دوبارهکاری، تغییر نادرست HTML و خرابی فایلها شود.
Lazy Load کردن تصویر LCP
تصویر اصلی بالای صفحه باید زود کشف و بارگذاری شود؛ نه اینکه تا اجرای JavaScript یا نزدیک شدن کاربر به آن تأخیر داشته باشد.
Preload کردن تعداد زیادی فایل
Preload برای منابع حیاتی است. استفاده بیش از حد از آن میتواند باعث رقابت شبکه و کاهش اولویت منابع اصلی شود.
پاکسازی دیتابیس بدون بکاپ
نام ناشناخته جدول یا Option بهمعنای بلااستفاده بودن آن نیست.
Delay کردن تمام JavaScriptها
برخی فایلها برای منو، فرم، فروشگاه و Tracking ضروریاند. Delay باید فایلبهفایل آزمایش شود.
نادیده گرفتن کاربران واردشده
مدیران، اعضا و مشتریان واردشده ممکن است نسخه بدون Page Cache را ببینند. سرعت آنها را جداگانه بررسی کنید.
نادیده گرفتن نسخه موبایل
یک سایت ممکن است روی دسکتاپ سریع باشد، اما روی موبایل ضعیف بهدلیل CPU محدود، JavaScript زیاد یا تصاویر بزرگ عملکرد نامناسبی داشته باشد.
مقایسه تستهای غیرهمسان
نتیجه موبایل را با دسکتاپ یا یک موقعیت جغرافیایی را با موقعیت دیگر مقایسه نکنید.
چکلیست مرحلهای افزایش سرعت وردپرس
مرحله اول: آمادهسازی
- ☐ بکاپ جدید و قابل بازیابی تهیه شده است.
- ☐ تغییرات پرریسک روی Staging انجام میشوند.
- ☐ صفحات نمونه مشخص شدهاند.
- ☐ نتیجه اولیه ثبت شده است.
- ☐ شرایط تست مشخص شده است.
مرحله دوم: تشخیص
- ☐ Field Data و Lab Data جداگانه بررسی شدهاند.
- ☐ عنصر LCP مشخص شده است.
- ☐ چهار بخش LCP بررسی شدهاند.
- ☐ TTFB سند اصلی بررسی شده است.
- ☐ Long Taskهای JavaScript بررسی شدهاند.
- ☐ تعاملهای کند مرتبط با INP پیدا شدهاند.
- ☐ منابع ایجادکننده CLS شناسایی شدهاند.
- ☐ صفحات موبایل جداگانه تست شدهاند.
مرحله سوم: اصلاح
- ☐ Page Cache فعال و تست شده است.
- ☐ تصاویر متناسب با محل نمایش هستند.
- ☐ تصویر LCP از Lazy Loading خارج شده است.
- ☐ منبع LCP از HTML قابل کشف است.
- ☐ فایلها و افزونههای بلااستفاده بررسی شدهاند.
- ☐ فونتها و وزنهای اضافی حذف شدهاند.
- ☐ منابع شخص ثالث محدود شدهاند.
- ☐ دادههای Autoload بررسی شدهاند.
- ☐ پردازشهای Cron و پسزمینه بررسی شدهاند.
- ☐ دیتابیس فقط پس از بکاپ پاکسازی شده است.
- ☐ صفحات پویا WooCommerce از کش عمومی مستثنا شدهاند.
مرحله چهارم: کنترل کیفیت
- ☐ فرمها کار میکنند.
- ☐ منوی موبایل سالم است.
- ☐ فرایند خرید آزمایش شده است.
- ☐ کد تخفیف و روش ارسال کار میکنند.
- ☐ رویدادهای Analytics و تبلیغات ثبت میشوند.
- ☐ خطای JavaScript یا PHP جدید ایجاد نشده است.
- ☐ کش افزونه، سرور و CDN پاک شده است.
- ☐ تست نهایی با شرایط مشابه انجام شده است.
- ☐ نتیجه تغییرات در Change Log ثبت شده است.
پرسشهای متداول درباره افزایش سرعت وردپرس
آیا نصب افزونه کش برای افزایش سرعت وردپرس کافی است؟
خیر. افزونه کش میتواند پردازش صفحات را کاهش دهد، اما مشکلاتی مانند هاست ضعیف، تصویر LCP سنگین، JavaScript زیاد، فونت نامناسب یا کوئریهای کند را بهتنهایی حل نمیکند.
ابتدا باید گلوگاه اصلی مشخص شود.
بهترین افزونه افزایش سرعت وردپرس کدام است؟
انتخاب افزونه به وبسرور، امکانات هاست، نوع سایت، WooCommerce، سطح مهارت کاربر و قابلیتهای فعال بستگی دارد.
افزونهای که روی یک سایت نتیجه مناسبی دارد، ممکن است روی سایت دیگر با کش سرور یا افزونههای موجود تداخل ایجاد کند.
چگونه سرعت وردپرس را بدون افزونه افزایش دهیم؟
بعضی اقدامات بدون افزونه نیز امکانپذیرند؛ مانند استفاده از هاست مناسب، بهروزرسانی PHP، بهینهسازی تصاویر، حذف اسکریپتهای غیرضروری، اصلاح قالب، تنظیم Cache Header و کاهش منابع شخص ثالث.
با این حال، اجرای بعضی قابلیتها مانند Page Cache بدون افزونه یا ابزار سرور به دانش فنی بیشتری نیاز دارد.
آیا تعداد زیاد افزونهها همیشه سایت را کند میکند؟
خیر. کیفیت کد، کوئریها، فایلهای Front-end و پردازشهای پسزمینه مهمتر از تعداد خام افزونههاست.
با این حال، افزونههای بلااستفاده یا دارای قابلیت تکراری باید حذف شوند.
چرا امتیاز PageSpeed هر بار تغییر میکند؟
تست آزمایشگاهی تحت تأثیر شرایط شبکه، سختافزار شبیهسازیشده، بار سرور و منابع خارجی قرار دارد.
برای تصمیمگیری، چند تست مشابه و داده واقعی کاربران را کنار هم بررسی کنید.
چرا امتیاز PageSpeed موبایل کمتر از دسکتاپ است؟
تست موبایل معمولاً شرایط سختتری برای CPU و شبکه شبیهسازی میکند. JavaScript زیاد، تصاویر بزرگ و Main Thread شلوغ در موبایل اثر بیشتری نشان میدهند.
آیا باید تصویر اصلی صفحه را Lazy Load کنیم؟
معمولاً خیر. اگر تصویر در اولین Viewport قرار دارد یا عنصر LCP است، Lazy Loading میتواند نمایش آن را به تأخیر بیندازد.
Lazy Loading بیشتر برای تصاویر و iframeهای پایین صفحه مناسب است.
آیا CDN همیشه سرعت سایت را افزایش میدهد؟
خیر. نتیجه به محل کاربران، سرور اصلی، تنظیمات Cache، کیفیت شبکه و نوع محتوای سایت بستگی دارد.
CDN نمیتواند پردازش کند PHP یا کوئریهای دیتابیس را بهطور خودکار اصلاح کند.
چرا سایت برای کاربران مهمان سریع و برای مدیر سایت کند است؟
کاربران مهمان معمولاً نسخه Page Cache را دریافت میکنند، اما کاربران واردشده ممکن است صفحه را بهصورت پویا ببینند.
افزونهها، نوار مدیریت، درخواستهای شخصیسازیشده و کوئریهای پنل نیز میتوانند سرعت کاربر واردشده را کاهش دهند.
علت کندی پیشخوان وردپرس چیست؟
کوئریهای سنگین، درخواستهای API خارجی، افزونهها، WP-Cron، Heartbeat، Action Scheduler و خطاهای PHP از علتهای رایج هستند.
برای تشخیص باید Query Monitor، Cron Eventها، درخواستهای HTTP و لاگ خطا بررسی شوند.
آیا پاکسازی دیتابیس سرعت سایت را زیاد میکند؟
گاهی مفید است؛ اما نتیجه به علت کندی بستگی دارد.
اگر مشکل اصلی JavaScript، هاست یا تصویر LCP باشد، حذف Revisionها تأثیر قابل توجهی روی Front-end ایجاد نمیکند.
هر چند وقت یکبار باید سرعت سایت را بررسی کنیم؟
پس از تغییر قالب، نصب افزونه، افزودن Script، تغییر هاست یا طراحی صفحات مهم باید تست انجام شود.
برای سایتهای فعال، مانیتورینگ دورهای Core Web Vitals و صفحات کلیدی مفیدتر از تست تصادفی روزانه است.
جمعبندی
افزایش سرعت سایت وردپرسی با نصب چند افزونه و فعال کردن تمام گزینههای Minify، Delay و Lazy Load انجام نمیشود.
ابتدا داده واقعی و آزمایشگاهی را جدا کنید. سپس مشخص کنید مشکل اصلی از TTFB، LCP، INP، CLS، تصاویر، JavaScript، افزونهها، دیتابیس یا پردازشهای پسزمینه است.
پس از پیدا کردن گلوگاه، هر تغییر را جداگانه اجرا و با شرایط مشابه آزمایش کنید.
در سایتهای WooCommerce، عضویتی و پرترافیک، سلامت سبد خرید، فرمها، Tracking و تجربه کاربران واردشده بهاندازه امتیاز ابزارهای تست اهمیت دارد.
اگر پس از اصلاح کش، تصاویر و فایلهای صفحه همچنان TTFB، LCP یا INP مناسب نیست، مشکل ممکن است به هاست، قالب، افزونهها، کوئریهای دیتابیس یا منابع خارجی مربوط باشد.
برای بررسی مسیر اجرا و خدمات مرتبط، میتوانید جزئیات تعرفه خدمات طراحی و بهینهسازی سایت را مشاهده کنید.
