این صفحهٔ ستون خوشهٔ «آموزش سایت و وردپرس» است. موضوع را از «چطور سریع‌ترش کنیم» شروع نکرده‌ام چون آن سؤال، بی‌پاسخ می‌ماند تا وقتی بدانیم کجا کند است. کندی یک علامت است، نه یک تشخیص. دو سایت می‌توانند هر دو سه ثانیه بارگذاری شوند و دلیلشان کاملاً متفاوت باشد؛ یکی به کش نیاز دارد و دیگری باید افزونه‌اش حذف شود.
تقریباً همهٔ راهنماهای سرعت، فهرست کار ارائه می‌دهند: فشرده‌سازی، کش، تصویر، به‌روزرسانی. آن فهرست غلط نیست، ولی بی‌ترتیب است. ترتیب، نصف کار تشخیص است. اینجا همان ترتیب را با عدد می‌دهم.
چهار لایه‌ای که زمان در آن‌ها مصرف می‌شود
درخواست از لحظه‌ای که کاربر آدرس را می‌زند تا لحظه‌ای که صفحه کامل می‌شود، از چهار ناحیه رد می‌شود:
لایهٔ شبکه و نام. شامل جستجوی DNS، ساخت اتصال، و دست‌دهی امنیتی. روی اینترنت داخلی ایران، مسیر بین کاربر و دیتاسنتر می‌تواند بخش بزرگی از زمان باشد، بدون اینکه سایت تو هیچ کاری کرده باشد.
لایهٔ وب‌سرور و PHP. پذیرش اتصال، رسیدگی به کش در همان لایه، و اجرای فایل‌های PHP. اگر صفحه کش‌شده باشد، این لایه تقریباً صفر است.
لایهٔ دیتابیس. کوئری‌ها. در وردپرس، شمار کوئری معمولاً با افزونه‌ها بالا می‌رود و با هر ویجت و هر منوی سفارشی بیشتر می‌شود.
لایهٔ مرورگر. دانلود فایل‌های استاتیک، اجرای جاوااسکریپت، چیدمان و نقاشی. این لایه تنها جایی است که کاربر «می‌بیند»، و تنها لایه‌ای که ابزارهای آزمایشگاهیِ معمولی، درست اندازه می‌گیرند.
خطای رایج این است که فقط لایهٔ چهارم دیده می‌شود. در نتیجه، کاربر «سایت کند است» می‌گوید و صاحب سایت افزونهٔ کش می‌خرد؛ در حالی که مشکل در مسیر شبکه بوده است.
ترتیب صحیح عیب‌یابی
این ترتیب را به‌کار ببر؛ چون هر مرحله، هزینهٔ مرحلهٔ بعدی را کم می‌کند:
یک: از بیرون و از داخل سرور اندازه بگیر. اگر از داخل سرور سریع و از بیرون کند است، مسئله در شبکه یا مسیر است، نه در وردپرس. این اولین و مهم‌ترین تفکیک است و اکثر بحث‌ها را در همان اول می‌بندد.
دو: کش صفحه را جدا کن. دو درخواست بفرست؛ یکی ناشناس (احتمالاً کش‌شده) و یکی با کوکی ورود (کشردشده). اختلاف این دو عدد، سهم PHP و دیتابیس است. اگر اختلاف زیاد است، مشکل در کد سمت سرور است و خرید هاست قوی‌تر، کمکی نمی‌کند.
سه: بفهم افزونه‌ای در میان است یا نه. در محیط تست، افزونه‌ها را گروهی غیرفعال کن و عدد را بگیر. اگر با خاموش‌کردن همه، کندی از بین رفت، یکی‌یکی روشن کن تا مقصر پیدا شود.
چهار: دیتابیس را ببین. کوئری‌های کند، جدول‌های متورم و رکوردهای autoloadشده، سه مظنون همیشگی‌اند.
پنج: فایل‌های استاتیک را بشمار. شمار فایل‌ها در لایهٔ مرورگر، بیشتر از حجمشان اثر می‌گذارد؛ ده فایل کوچک از یک فایل بزرگ‌ترِ هم‌حجم، دیرتر تمام می‌شوند.
این ترتیب، «سریع‌ترین» روش نیست؛ «کم‌خطاترین» است. بی‌ترتیب، معمولاً به خرید هاست می‌رسی که مشکل را حل نمی‌کند.
اولین عدد: زمان پاسخ سرور
از خط فرمان، بدون واسطهٔ مرورگر:
curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n' https://example.com/سه بار بزن و خروجی را مقایسه کن. هر بخش چه چیزی را ثابت می‌کند:
dns بالا: دامنه و رکورد نام را بررسی کن؛ مقدار عمر کش DNS پایین، مسیر را کند نمی‌کند ولی سرویس‌دهندهٔ نام ضعیف، بله.
connect بالا: مسیر شبکه یا فاصلهٔ جغرافیایی. اگر دیتاسنتر دور است، همین عدد همیشه بالاست و وردپرس تو بی‌گناه است.
ttfb بالا در حالی که connect پایین است: کار سمت سرور. PHP، دیتابیس، یا صف شدن درخواست پشت یک افزونهٔ سنگین.
total بالا ولی ttfb پایین: مشکل در لایهٔ انتقال یا فایل‌های بزرگ است، نه در پردازش.
عدد سه‌نمونهای را جدی بگیر. یک نمونه، هیچ چیز ثابت نمی‌کند؛ به‌خصوص روی هاست اشتراکی که همسایه‌هایش ترافیک تولید می‌کنند.
سهم واقعی افزونه‌ها
در وردپرس، افزونه به‌تنهایی کند نیست؛ کاری که در هر درخواست انجام می‌دهد، کند است. سه الگوی پرخطر:
تماس بیرونی در مسیر صفحه. افزونه‌ای که برای نمایش یک آیکن، یک لوگو، یا یک سرویس تحلیلی، در زمان رندر به سرور دیگری وصل می‌شود. اگر آن سرور پاسخ ندهد، سایت تو هم منتظر می‌ماند. علامتش: کندیِ متغیر و بی‌دلیل که با هیچ تنظیمی درست نمی‌شود.
کوئری در حلقه. افزونه‌ای که برای هر آیتم منو یا هر محصول، جداگانه کوئری می‌زند. روی صفحهٔ کوچک دیده نمی‌شود؛ روی صفحهٔ دسته‌بندی با ده‌ها عضو، محسوس است.
کران داخلی. وظیفهٔ زمان‌بندی‌شده‌ای که با هر بازدیدکننده اجرا می‌شود. صفحه‌ای که باید سریع پاسخ دهد، بار کارهای پس‌زمینه را هم روی دوش اولین کاربر می‌گذارد.
روش پیدا کردنشان ساده است: شمار کوئری و زمان کل پردازش را در هر صفحه ببین، سپس افزونه‌ها را یکی‌یکی خاموش کن و همان عدد را دوباره بگیر. اگر افزونه‌ای بدون اینکه کاری لازم انجام دهد، زمان را بالا می‌برد، جایش در سایت نیست؛ حتی اگر رایگان باشد و امتیاز بالایی داشته باشد.
دیتابیس؛ سه مظنون همیشگی
جدول گزینه‌های autoload. وردپرس در هر درخواست، گزینه‌هایی را که علامت autoload دارند بار می‌کند. افزونه‌ای که حذف شده، ممکن است داده‌اش را جا گذاشته باشد و آن داده هر بار خوانده شود. حجم این بخش را باید اندازه بگیری، نه حدس.
نسخه‌های ذخیره‌شدهٔ نوشته. هر ویرایش، یک نسخه نگه می‌دارد. در سایتی با چند صد نوشته و ویرایش زیاد، این جدول می‌تواند بزرگ‌تر از خودِ محتوا باشد.
جدول‌های اختصاصی افزونه‌ها. بعضی افزونه‌ها میزهای خودشان را می‌سازند و بعد از حذف، نمی‌شکنند. این میزهای یتیم، هم فضا می‌گیرند هم در بکاپ‌ها حمل می‌شوند.
قبل از هر پاک‌سازی: بکاپ، و تست بازگردانی. حذف رکورد از سایت زنده بدون بکاپِ آزموده‌شده، تنها کاری است که کندی را با فاجعه عوض می‌کند. و بعد از پاک‌سازی، عدد را دوباره بگیر؛ اگر تغییری نکرد، مشکل از دیتابیس نبوده است و باید به لایهٔ قبلی برگردی.
تصاویر، فونت و لایهٔ مرورگر
در سایت‌های فارسی، این بخش اغلب بزرگ‌ترین مقصر است و کمترین توجه را می‌گیرد.
تصویر. اندازهٔ واقعی فایل، نه ابعادی که در HTML نوشته شده. تصویری که در صفحه ۳۰۰ پیکسل جا می‌گیرد ولی ۲۴۰۰ پیکسل عرضه می‌شود، هم حجم بیهوده دارد هم زمانرمزگشای. فرمت مدرن، بریدن اندازه، و عرضهٔ اندازهٔ مناسب برای موبایل، سه کاری است که اثرشان در دادهٔ میدان قابل‌اندازه‌گیری است.
لود تنبل و تصویر نخستین. اگر تصویر بالای صفحه هم تنبل بارگذاری شود، دیرتر دیده می‌شود و معیار تجربهٔ بارگذاری بدتر می‌شود. این یکی از آن تنظیماتی است که «بهینه‌سازی» آن را خراب می‌کند. تصویر اول صفحه باید از تنبل‌سازی مستثنا باشد.
فونت فارسی. قلم‌های فارسی بزرگ‌اند. پیش‌بارگذاری قلم اصلی، زیرمجموعه‌سازی، و انتخاب رفتار درست در زمان بارگذاری، سه تصمیمی‌اند که پرش متن و زمان نمایش محتوا را تعیین می‌کنند. اگر سایتت با «متن نامرئی» شروع می‌شود و بعد ظاهر می‌شود، تنظیم بارگذاری فونت مقصر است.
اسکریپت‌ها. ترکیب‌کردن و کوچک‌سازی فایل‌ها شمار درخواست را کم می‌کند؛ ولی هر کاری که تاخیر در اجرای اسکریپت اضافه می‌کند، باید با عددِ واقعی سنجیده شود، نه با فرض. بعضی تنظیمات، شمارندهٔ بازدید یا فرم ورود را می‌کشند و صاحب سایت تا هفته‌ها بعد متوجه نمی‌شود.
هاست قوی‌تر، اولین خرید اشتباه است
وقتی سایت کند است، خرید هاست بهتر وسوسه‌کننده و معمولاً بی‌فایده است. دلیلش ساده: اگر مشکل از افزونه، تصویر، یا نبود کش باشد، روی هاست قوی‌تر همان مشکل با بودجهٔ بیشتر ادامه پیدا می‌کند.
تست تشخیصی: سایت را موقتاً روی یک محیط ساده بالا بیاور (با قالب پیش‌فرض و بدون افزونه). اگر آنجا سریع بود، مسئله در محتوا و افزونه‌های توست، نه در سخت‌افزار. این یک ساعت کار، جلوی یک قرارداد پرهزینه سالانه را می‌گیرد.
و یادآوری: ارتقا نسخهٔ PHP، روی همان هاست فعلی، در خیلی از موارد جهش اندازه‌گیری‌شدنی می‌دهد. آن را قبل از مهاجرت امتحان کن.
چه عددی «خوب» است
پاسخ صادقانه: بستگی به نوع سایت دارد وبستگی به اینکه رقبا چه می‌دهند. اما سه کفِ عملی که در پروژه‌های خودم استفاده می‌کنم:
زمان پاسخ سرور برای صفحهٔ کش‌شده، زیر چند صد میلی‌ثانیه. اگر بالاتر است، لایهٔ کش یا وب‌سرور را بررسی کن.
زمان پاسخ برای صفحهٔ کشردشده، هرچه کمتر؛ چون این عدد، هزینهٔ واقعی PHP و دیتابیس توست و با افزونه به‌سرعت بالا می‌رود.
معیارهای تجربهٔ کاربر بر پایهٔ دادهٔ میدان، در سبز. عدد آزمایشگاهی را برای بازتولید مشکل استفاده کن، نه برای تصمیم.
اگر هر سه سبز است و کاربر هنوز می‌گوید سایت کند است، مشکل احتمالاً درک‌شدنی‌تر است: محتوای زیاد در صفحهٔ اول، یا انتظاری که با سرعت واقعی اینترنت منطقه نمی‌خواند.
ردیابی در مرورگر: کدام درخواست، صفحه را دیر تمام می‌کند
وقتی لایهٔ سرور سالم بود و کاربر هنوز کندی می‌بیند، سراغ لایهٔ مرورگر برو. در ابزار توسعه‌دهنده، تب شبکه را باز کن و صفحه را بدون کش بارگذاری کن. سه ستون را نگاه کن: زمان شروع، زمان کل، و اندازه.
درخواستی که صف طولانی دارد. اگر چند ده درخواست به سرور داری، بعضی‌شان منتظر می‌مانند چون مرورگر به‌طور همزمان تعداد محدودی اتصال باز می‌کند. راه‌حل، کم‌کردن شمار فایل است، نه سریع‌تر کردن تک‌تک فایل‌ها.
درخواستی که به سرور بیرونی می‌رود. اسکریپت یا فونت میزبان‌شده در سرویس دیگر. هم زمان اتصال اضافه می‌کند هم نقطهٔ شکست: اگر آن سرویس در دسترس نباشد، بخشی از صفحهٔ تو معلّق می‌ماند. میزبان‌کردن فایل‌های شخص ثالث، معمولاً هم سریع‌تر است هم قابل‌اتکاتر.
درخواستی که بعد از بقیه ظاهر می‌شود. یعنی زنجیرهٔ وابستگی: اسکریپتی که منتظر دیگری است. در وردپرس این زنجیره را با ترتیب بارگذاری و با بارگذاری تنبل می‌سازند، و همان‌جا هم خراب می‌شود.
عصری که متن ناپدید و بعد ظاهر می‌شود. علامت تنظیم بارگذاری قلم است. این در سایت فارسی‌زبان شایع است چون قلم‌های عددگذار فارسی سنگین‌اند.
این نگاه، بیست دقیقه وقت می‌گیرد و معمولاً سه اقدام مشخص بیرون می‌دهد: حذف چند اسکریپت میزبانی‌شده بیرون، ترکیب یا حذف فایل‌های غیرلازم، و استثنای تصویر اول از بارگذاری تنبل.
کش صفحه چه زمانی جواب نمی‌دهد
کش صفحه، قدرتمندترین ابزار سرعت در وردپرس است و در چهار حالت، بی‌اثر یا خطرناک می‌شود:
یک: صفحهٔ شخصی‌سازی‌شده. پنل کاربر، سبد خرید، صفحهٔ تسویه، و هر جایی که نام کاربر یا وضعیت سفارش نمایش داده می‌شود. اگر این مسیرها کش شوند، کاربر اطلاعات اشتباه یا حتی اطلاعات کاربر دیگر را می‌بیند. پس این صفحه‌ها باید از کش مستثنا شوند؛ و آن‌وقت همان کندی PHP را خواهند داشت، چون واقعاً باید محاسبه شوند.
دو: فرم‌ها و ورود. صفحه‌ای که فرم دارد و توکن امنیتی در آن تولید می‌شود، با کش ساده خراب می‌شود. اینجا باید یا کش را رد کنی یا توکن را داینامیک بارگذاری کنی.
سه: محتوای تازه با تأخیر. اگر پس از ویرایش، صفحهٔ کهنه سرو شود، کاربر به‌اشتباه فکر می‌کند ویرایش ذخیره نشده. تنظیم پاک‌شدن خودکار کش هنگام انتشار، این مسئله را حل می‌کند؛ و اگر این تنظیم کار نکند، مشکل از اتصال افزونه به وب‌سرور است نه از خودِ کش.
چهار: CSS بحرانی قدیمی. این یکی علامت مشخصی دارد: ظاهر به‌هم‌ریخته بعد از یک تغییر، بدون هیچ خطا. فایل CSS بحرانی که در دورهٔ قبل تولید شده، در دورهٔ جدید هم سرو می‌شود. پاک‌کردنش، نه تغییر قالب، جواب مسئله است.
نکتهٔ تشخیصی مهم: کش صفحه را با کش PHP و با کش مرورگر و با کش CDN اشتباه نگیر. چهار لایه‌اند، چهار روش پاک‌کردن دارند، و چهار نشانهٔ متفاوت. وقتی با «کش را زدم» چیزی درست نشود، یعنی کش اشتباهی را زده‌ای.
اثر هر تغییر را اثبات کن، نه فرض
قاعده‌ای که در همهٔ این مسیر رعایت می‌کنم: یک تغییر، یک عدد، یک ثبت.
اگر سه کار را همزمان انجام دهی و سرعت بهتر شود، نمی‌فهمی کدام‌یک مؤثر بوده؛ و بدتر: اگر یکی‌شان مضر بوده، در مجموعه گم می‌شود. پس:
۱. پیش از تغییر، پنج بار اندازه بگیر و میانه‌شان را بنویس. ۲. فقط یک تغییر بده. ۳. دوباره پنج بار اندازه بگیر. ۴. نتیجه را ثبت کن: تاریخ، تغییر، عدد قبل، عدد بعد.
این ثبت، بعداً دو کار می‌کند: جلوی تکرار تغییرات بی‌اثر را می‌گیرد، و وقتی مدیر یا کارفرما می‌پرسد «چقدر کار کردی؟»، جواب قابل‌اندازه‌گیری داری نه توصیفی.
و یک هشدار صادقانه: بعضی تغییرات، عدد آزمایشگاهی را بهتر می‌کنند و تجربهٔ واقعی را بدتر. تاخیر در اجرای اسکریپت، نمونهٔ کلاسیک این است: نمره بالا می‌رود ولی کلید یا فرمی که کاربر لازم دارد، دیرتر کار می‌کند. همیشه با دادهٔ میدان تأیید کن، نه فقط با نمره.
جمع‌بندی
کندی وردپرس، یک علامت است با چهار منشأ: شبکه، پردازش سمت سرور، دیتابیس، و لایهٔ مرورگر. ترتیب درست، اول تفکیک بیرون و داخل سرور، بعد جداسازی کش‌شده از کشردشده، بعد افزونه‌ها، بعد دیتابیس، و در آخر فایل‌های استاتیک.
هیچ‌کدام از این‌ها با خرید هاست بهتر حل نمی‌شوند؛ و بیشترِ اوقات، دو حرکت ارزان و بی‌زحمت بیش از یک ارتقای سخت‌افزاری نتیجه می‌دهند: کش صفحهٔ درست تنظیم‌شده و تصویرهای سبک و هم‌اندازه.
جمع‌بندی
کندی را با ترتیب اندازه بگیر: بیرون و داخل سرور، با کش و بدون کش، افزونه‌ها، دیتابیس، بعد فایل‌های استاتیک. این ترتیب، بیشتر مسیرهای اشتباه پرهزینه را در همان دو مرحلهٔ اول می‌بندد.
اعضای این خوشه هر کدام یک لایه را کامل می‌کنند: تفاوت وب‌سرورها و کش در لایهٔ سرور، کش PHP و تله‌ای که دیپلوی را بی‌اثر نشان می‌دهد، انواع کش و کاربردی که هر کدام دارند، تصویر مدرن و تزاحم بارگذاری تنبل، فونت فارسی و زمان نمایش متن، کران وردپرس و هزینه‌ای که اولین بازدیدکننده می‌پردازد، و تورم دیتابیس با روش پاک‌سازی امن.
مقالبی بخوانی
- google-core-web-vitals
- types-of-website-caching
- does-a-server-make-website-faster
- تفاوت LiteSpeed با Nginx و Apache برای وردپرس؛ کدام وب‌سرور واقعیت را سریع می‌کند؟
- اعتبار موضوعی و لینک‌دهی خوشه‌ای؛ ساختار ستون و خوشه در عمل
- محتوای انبوه یا Scaled Content Abuse؛ سیاستی که سایت‌های پُرمقاله را تنبیه می‌کند
- شصت روز اول یک پروژهٔ سئو؛ ترتیب واقعی کار
- امن‌سازی وردپرس روی هاست سی‌پنل؛ پانزده کاری که واقعاً مانع می‌شوند
- MySQL یا MariaDB برای وردپرس؛ تفاوت عملی روی هاست سی‌پنل
امید بداق
من متخصص سئو که عاشق اینه به کسب‌وکارها کمک کنه تو گوگل دیده بشن!از وردپرس گرفته تا سئو، هرچیزی که برای رشد آنلاین نیاز داری میتونم کمکت کنم.