کندی وردپرس از هاست است یا افزونه؟ مسیر تشخیص مرحله‌به‌مرحله
برای تشخیص علت کندی وردپرس، پاسخ اولیه، منابع، کش و اثر افزونه را با سناریوی ثابت بررسی کنید؛ بدون خاموش‌کردن افزونه‌های فروشگاه زنده.
هاستلینو۴ دقیقه مطالعه
فهرست مطالب
کندی وردپرس را نمی‌توان فقط از روی امتیاز سرعت به هاست یا افزونه نسبت داد. اول مشخص کنید کدام کار کند است: بازشدن صفحه عمومی، مدیریت وردپرس، جست‌وجوی محصول یا پرداخت. سپس با شرایط یکسان و تغییر یک عامل، شواهد جمع کنید. این راهنما مسیر تشخیص است؛ آزمون روی سایت مشتری یا نتیجه اختصاصی هاستلینو را گزارش نمی‌کند.
پاسخ کوتاه: از چه نشانه‌ای شروع کنیم؟
| نشانه | فرضیه قابل بررسی | شاهد بعدی |
|---|---|---|
| صفحه کش‌شده سریع، مدیریت کند | پردازش PHP، دیتابیس یا منابع هنگام درخواست پویا | زمان درخواست مدیریت و مصرف همان بازه |
| فقط یک صفحه یا قابلیت کند است | قالب صفحه، افزونه یا سرویس وابسته | مقایسه همان قابلیت در محیط آزمایشی |
| همه مسیرها در یک شبکه کندند | مسیر شبکه، DNS یا اتصال | آزمون از شبکه دیگر با ثبت زمان |
| سند HTML زود می‌رسد اما صفحه دیر کامل می‌شود | تصویر، فونت، جاوااسکریپت یا وابستگی مرورگر | آبشار Network و عنصر اصلی صفحه |
این نشانه‌ها حکم قطعی نیستند. برای نمونه، سریع‌بودن صفحه کش‌شده ثابت نمی‌کند هاست برای درخواست‌های بدون کش ظرفیت کافی دارد.
۱. یک سناریوی قابل تکرار تعریف کنید
به‌جای «سایت کند است»، بنویسید «جست‌وجوی محصول برای کاربر خارج‌شده از حساب کند است». URL، ساعت، دستگاه، شبکه، وضعیت ورود و کش را ثبت کنید. صفحه اصلی را با تسویه‌حساب مقایسه مستقیم نکنید؛ این دو کار یکسانی انجام نمی‌دهند.
چند بار همان سناریو را تکرار و پراکندگی نتایج را نگه دارید. یک بار سریع یا کند برای نسبت‌دادن علت کافی نیست. اگر درگاه، پیامک یا API بیرونی دخیل است، زمان انتظار آن را از اجرای خود سایت جدا ثبت کنید.
۲. زمان پاسخ را از کامل‌شدن صفحه جدا کنید
در ابزار Network مرورگر، درخواست سند و درخواست‌های بعدی را ببینید. اگر شروع پاسخ طولانی است، هنوز چند احتمال وجود دارد: اتصال، شبکه، اجرای برنامه یا انتظار برای داده. راهنمای TTFB و زمان پاسخ اولیه کمک می‌کند این زمان را با کل بارگذاری اشتباه نگیرید.
اگر سند سریع است اما تصویر اصلی یا تعامل دیر آماده می‌شود، ارتقای هاست تنها فرضیه ممکن نیست. اندازه رسانه، اجرای اسکریپت و درخواست‌های ثالث را بررسی کنید. نتیجه یک اجرای آزمایشگاهی را معادل تجربه همه کاربران ندانید.
۳. مصرف منابع را با همان زمان درخواست تطبیق دهید
گزارش منابع حساب، لاگ خطا و زمان رخداد را کنار هم بگذارید. رسیدن به محدودیت، نشانه‌ای برای بررسی ظرفیت است؛ اما ممکن است خود یک کار غیرضروری منابع را مصرف کند. نبودن نمودار یا دسترسی به لاگ هم به معنی سالم‌بودن آن بخش نیست.
برای ثبت شواهد، از مسیر تشخیص مصرف بالای CPU وردپرس استفاده کنید. اگر پیام Resource Limit می‌بینید، راهنمای خطای ۵۰۸ و محدودیت منابع موضوع مشخص‌تری دارد. حذف فایل، افزایش کورکورانه محدودیت یا تغییر نسخه PHP را جای تشخیص نگذارید.
۴. سهم افزونه و قالب را در محیط جدا بررسی کنید
یک نسخه آزمایشی با فایل و دیتابیس متناسب، دسترسی محدود و امکان بازگشت آماده کنید. پرداخت، پیامک، ایمیل و اتصال‌های واقعی را پیش از آزمون کنترل کنید. غیرفعال‌کردن گروهی افزونهها روی فروشگاه زنده میتواند مسیر خرید را مختل کند؛ این کار را برای گرفتن یک امتیاز بهتر انجام ندهید.
- از سناریو با ترکیب فعلی، نتیجه پایه بگیرید.
- وابستگی قابلیت مورد آزمون را مشخص کنید؛ مثلاً خاموش‌کردن فروشگاه، آزمون پرداخت را بی‌معنی می‌کند.
- فقط یک افزونه غیرضروری برای همان سناریو یا یک تنظیم را تغییر دهید.
- شرایط کش را در دو اجرا یکسان کنید و همان مسیر را دوباره بسنجید.
- تغییر را برگردانید و ببینید نشانه قابل تکرار است یا خیر؛ نتیجه را ثبت کنید.
سبک‌شدن پس از حذف یک افزونه فقط نشان می‌دهد ترکیب قبلی در آزمون اثر داشته است؛ هنوز باید نقش تنظیمات، حجم داده و ناسازگاری را بررسی کرد. تعداد افزونه به‌تنهایی معیار کافی نیست.
۵. چه زمانی بررسی ارتقای هاست منطقی است؟
وقتی کار ضروری سایت، پس از رفع پردازش‌های غیرضروری و بررسی کش، در بار واقعی مرتب با محدودیت تأییدشده روبه‌رو است، درباره افزایش منابع یا تغییر سرویس گفت‌وگو کنید. از میزبان بپرسید کدام سقف پر شده، تغییر پلن دقیقاً چه چیزی را عوض می‌کند و چگونه نتیجه سنجیده می‌شود. برای انتخاب، راهنمای خرید هاست وردپرس را ببینید؛ VPS صرفاً به‌خاطر نامش درمان کندی نیست.
قالب ثبت نتیجه؛ بدون نتیجه‌سازی
| فیلد | چه بنویسیم؟ |
|---|---|
| سناریو و شرایط | URL، نوع کاربر، شبکه، ساعت و وضعیت کش |
| تغییر واحد | دقیقاً کدام تنظیم یا جزء عوض شد؟ |
| شاهد قبل و بعد | اندازه‌گیری‌های تکراری با شرایط یکسان |
| نتیجه و محدودیت | تکرار شد، نشد یا داده کافی نداریم؟ |
| قدم بعدی | بررسی برنامه، منابع یا سرویس وابسته؛ با مسئول مشخص |
برای شناخت اولیه وضعیت قابل مشاهده سایت، بررسی رایگان سایت نقطه شروع است؛ ابزار عمومی به لاگ، افزونهها و مصرف داخلی دسترسی ندارد. برای بررسی داخلی، محدوده کار را از پشتیبانی وردپرس پیگیری کنید و رمز را در فرم عمومی ننویسید.
منابع و مرز این راهنما
مستند رسمی بهینه‌سازی وردپرس عوامل میزبانی، نرم‌افزار و کش را توضیح می‌دهد. توضیح رسمی PageSpeed Insights تفاوت داده آزمایشگاهی و داده کاربران را روشن می‌کند. ترتیب آزمون و دفتر ثبت بالا، پیشنهاد عملی تحریریه است؛ عدد عملکرد یا نتیجه آزمون مشتری ادعا نشده است.
پیش از ارتقا، نشانه‌ها را بررسی کنیم
بررسی بیرونی نقطه شروع است؛ علت داخلی کندی به شواهد برنامه و منابع نیاز دارد.
پرسش‌های متداول
آیا TTFB بالا یعنی هاست ضعیف است؟
خیر. زمان پاسخ اولیه میتواند از شبکه، کش، اجرای PHP، دیتابیس یا سرویس وابسته اثر بگیرد. آن را با شرایط آزمون و گزارش منابع همان بازه تفسیر کنید.
برای تشخیص کندی همه افزونهها را خاموش کنیم؟
روی سایت زنده، بهویژه فروشگاه، این کار میتواند عملکرد را مختل کند. در محیط جدا، با بکآپ و حفظ وابستگی سناریو، یک عامل را تغییر دهید و همان کار را دوباره بسنجید.
