چگونه مشکل سرعت سایت را عیب‌یابی کنیم؟
چرا عیب‌یابی سرعت سایت وردپرسی بدون «عدد» به بن‌بست می‌رسد و چطور با یک ترتیب مشخص از هاست تا افزونه و تصویر، گلوگاه واقعی را در چند ساعت پیدا کنیم؟ راهنمای عملی.
درخواست کمک برای «کندی سایت» تقریباً همیشه با یک جمله تمام می‌شود: «هر کاری کردم، درست نشد». و وقتی می‌پرسم «چه کارهایی؟»، جواب تقریباً ثابت است: افزونهٔ کش نصب کرده، چند تصویر را کم‌حجم کرده، «بهین‌ساز» هم زده — ولی هیچ‌وقت ندانسته گلوگاه واقعی کجاست. تجربه‌ام در ده‌ها پروژه این است: کندی سایت تقریباً همیشه یک مقصر مشخص دارد، ولی برای پیدا کردنش باید به‌جای آزمون‌وخطا، یک ترتیب مشخص را دنبال کرد. در این راهنما همان مسیری را می‌روم که در عیب‌یابی هر پروژه طی می‌کنم.
گام صفر: اول عدد بگیرید، بعد دست بزنید
بدون عدد، عیب‌یابی فقط حدس است. پنج عدد کلیدی که در ابتدای هر عیب‌یابی ثبت می‌کنم:
- TTFB (Time To First Byte): چند میلی‌ثانیه طول می‌کشد تا اولین بایت از سرور برسد؟
- LCP (Largest Contentful Paint): بزرگ‌ترین عنصر دیدی صفحه چه زمانی ظاهر می‌شود؟
- مجموع بایت‌های CSS/JS: صفحهٔ اول چند کیلوبایت استایل و اسکریپت می‌گیرد؟
- تعداد درخواست‌ها: مرورگر برای کامل‌کردن صفحه چند درخواست می‌زند؟
- مصرف CPU در پنل هاست: در ساعات پیک، چه شکلی است؟
این پنج عدد را قبل و بعد از هر تغییر ثبت کنید؛ همان کاری که در راهنمای افزایش سرعت وردپرس به‌عنوان ستون فقرات روش توضیح داده‌ام.
بهینه‌سازی بدون اندازه‌گیری، مثل جراحی بدون آزمایش است؛ ممکن است درست باشد، ولی احتمال اشتباهش زیاد است.
چهار لایهٔ کندی سایت
در تجربه‌ام، کندی سایت تقریباً همیشه در یکی از چهار لایه رخ می‌دهد:
| لایه | نشانه |
|---|---|
| هاست و سرور | TTFB بالا روی همهٔ صفحات |
| قالب و CSS/JS | مجموع بایت زیاد، DOM عمیق |
| افزونه‌ها و دیتابیس | کندی انتخابی، کندی پیشخوان |
| تصویر و فایل | حجم زیاد صفحه، LCP کند |
لایهٔ هاست و TTFB
اگر TTFB روی همهٔ صفحات بالای ۸۰۰ میلی‌ثانیه است، بدون شک لایهٔ اول درگیر است. نشانه‌های هاست ضعیف را در تأثیر هاست بر سرعت سایت باز کرده‌ام؛ اینجا فقط یک قاعدهٔ عملی می‌گویم: هیچ افزونه‌ای TTFBِ ضعیف را حل نمی‌کند. اگر مقصر هاست است، ارتقا یا مهاجرت امن، اولین قدم است. ترتیب درست در مهاجرت سایت وردپرسی به هاست جدید آمده.
لایهٔ قالب و CSS/JS
اگر TTFB خوب است ولی مجموع بایت‌های CSS/JS بالای ۵۰۰ کیلوبایت است، مقصر لایهٔ قالب است. علل دقیق کندی قالب را در چرا بعضی قالب‌ها سایت را کند می‌کنند کالبدشکافی کرده‌ام؛ راه‌حل عملی: مهاجرت به قالب سبک با پروتکل امن.
لایهٔ افزونه‌ها و دیتابیس
اگر کندی روی صفحات خاصی ظاهر می‌شود ولی صفحه‌های دیگر سالم‌اند، مظنون اصلی افزونه‌ها هستند. روش تشخیص:
- غیرفعال‌سازی دسته‌ای: افزونه‌ها را در پنج دسته خاموش کنید و اعداد را مقایسه کنید.
- تک‌نفره درون دسته: در دستهٔ مشکوک، یکی‌یکی روشن کنید تا مقصر پیدا شود.
- گزارش Query Monitor: افزونه‌ای که تعداد کوئری‌ها را در هر صفحه می‌شمارد.
اگر مشکل در پیشخوان هم هست، دیتابیس مظنون جدی است. راهنمای کامل در تأثیر دیتابیس بر سرعت سایت و بهینه‌سازی جدول‌های MySQL.
لایهٔ تصویر و فایل‌های حجیم
اگر LCP کند است ولی TTFB و بایت‌های CSS/JS خوب‌اند، مقصر تصویر است. مسیر درمان:
- فرمت درست: WebP یا AVIF به‌جای JPEG حجیم.
- فشرده‌سازی: مسیر کامل در فشرده‌سازی تصاویر سایت.
- srcset و lazy-load: تصویر به‌اندازه درست و بارگذاری هوشمند.
گلوگاه تصویر در اکثر سایت‌های محتوایی، مقصر اصلی است. یک بار بهینه‌سازی کتابخانهٔ موجود می‌تواند نصف بایت‌های صفحه را از بین ببرد.
ترتیب درست شک کردن
ترتیبی که در همهٔ پروژه‌ها استفاده می‌کنم:
- عدد بگیرید (پنج عدد کلیدی).
- اگر TTFB بد است → هاست و سرور.
- اگر TTFB خوب است ولی بایت‌های CSS/JS بالاست → قالب.
- اگر کندی انتخابی است → افزونه‌ها و دیتابیس.
- اگر LCP کند است ولی بقیه خوب است → تصویر.
- کش را همیشه در لایهٔ آخر بگذارید؛ کش، سقف سرعت قالب و هاست را بالا نمی‌برد.
کشِ درست، تأثیر بزرگی دارد ولی جای گلوگاه اصلی را نمی‌گیرد. راهنمای انتخابش در بهترین افزونه‌های کش وردپرس.
اشتباهات رایج در عیب‌یابی
- نصب چند افزونهٔ کش همزمان: نه‌فقط سرعت نمی‌دهد، بلکه صفحه‌ها را می‌شکند.
- عوض کردن هاست بدون تشخیص: گران‌ترین اشتباه؛ اول عدد بگیرید.
- تست فقط روی دسکتاپ: همیشه روی موبایل و اینترنت واقعی هم تست کنید.
- نادیده‌گرفتن پیشخوان: اگر پیشخوان کند است، مشکل از دیتابیس یا افزونه‌های پیشخوان است، نه لایهٔ فرانت.
- قضاوت بر اساس PageSpeed آزمایشگاهی: دادهٔ میدانی (CrUX) داوری می‌کند؛ توضیح این تفاوت را در Core Web Vitals چیست آورده‌ام.
در عیب‌یابی سرعت، «ترتیب» مهم‌تر از «ابزار» است؛ ابزار خوب در ترتیب غلط، فقط سریع‌تر به بن‌بست می‌رسد.
جمع‌بندی مسیر
عیب‌یابی سرعت سایت وردپرسی در یک جمله خلاصه می‌شود: پنج عدد، چهار لایه، یک ترتیب مشخص. اگر همین ساختار را در پروژه‌های خودتان جا بیندازید، دیگر هر بار نصب افزونهٔ تازه یک قمار نیست؛ هر تغییر، بخشی از یک نقشهٔ مشخص است. تجربه‌ام این است: سایت‌هایی که با این روش عیب‌یابی شده‌اند، پایدارتر از سایت‌هایی هستند که با آزمون‌وخطا سرعت گرفته‌اند — چون در حالت اول، دلیل هر تغییر را می‌دانید و در حالت دوم، فقط شانس داشته‌اید. اگر در پروژهٔ خودتان به گلوگاهی برخورد کرده‌اید که این نقشه جای دیگری نشانش می‌داد، در دیدگاه‌ها بنویسید تا همان مسیر را بازتر کنم. ⚡
نویسنده در وردپرس کار.