آزمایش مقایسه قالب‌های وردپرس از نظر سرعت
چرا مقایسه سرعت قالب‌های وردپرس بدون روش آزمایشگاهی معنادار نیست و چطور با معیارهای قابل‌اندازه‌گیری مثل TTFB، بایت‌های CSS/JS و عمق DOM، تفاوت واقعی قالب‌ها را در چند ساعت بسنجیم؟
هر بار در جمعی از صاحبان سایت می‌شنوم که «این قالب سریع‌تر از آن یکی است»، می‌دانم صحبت از تجربهٔ شخصی است، نه از داده. سال‌ها پیش در پروژه‌ای مجبور شدم بین دو قالب محبوب تصمیم بگیرم و برای اولین بار واقعاً معیار گذاشتم: یک نصب تمیز وردپرس، داده‌های یکسان، همان افزونه‌ها، همان سرور. نتیجه بسیار متفاوت از تبلیغات بود. آن آزمایش برایم تبدیل شد به یک عادت ثابت؛ هر بار بین چند قالب مردد می‌شوم، پیش از هر اظهار نظری، این آزمایش کوچک را انجام می‌دهم.
چرا مقایسهٔ سرعت قالب‌ها این‌قدر گمراه‌کننده است؟
سه دلیل، باعث می‌شود گفت‌وگو دربارهٔ سرعت قالب‌ها شبیه بحث سلیقه‌ای شود:
- دموی سازنده، ویترین است نه واقعیت: روی سرورِ خودِ سازنده، با تصاویر بهینه، بدون افزونه‌های شما اجرا می‌شود و LCP آن معمولاً با سایت واقعی شما یکی نیست. کالبد این تفاوت را در چرا بعضی قالب‌ها سایت را کند می‌کنند باز کرده‌ام.
- سبک و سنگین، مفاهیم مطلق نیستند: یک قالب ممکن است بدون صفحه‌ساز سبک باشد ولی با المنتور سنگین شود. معیار باید روی رفتار قالب در شرایط مشترک باشد، نه مشخصات تبلیغاتی.
- عدد PageSpeed آزمایشگاهی، دادگاه نیست: این عدد (Lighthouse) در یک اجرا ساخته می‌شود و نوسان دارد. قاضی واقعی، دادهٔ میدانی و رفتار قالب در چند سناریوی تکرارپذیر است. توضیح کامل تفاوت این دو را در Core Web Vitals چیست آورده‌ام.
«کدام قالب سریع‌تر است؟» سوال خوبی نیست؛ سوال درست این است که «در چه شرایط و با چه محتوایی، کدام قالب سنگین‌تر می‌شود؟»
چارچوب آزمایش: چه چیزی را مقایسه می‌کنیم؟
پیش از هر آزمایشی، سه چیز را مشخص می‌کنم:
- چه قالب‌هایی؟ سه تا چهار قالب که واقعاً در پروژه‌ها به آن‌ها فکر می‌کنم.
- با چه داده‌ای؟ داده‌ها باید مشترک باشند: یک نوشتهٔ بلند با تصویر، یک برگهٔ ساده، یک صفحهٔ آرشیو.
- روی چه بستری؟ همان سرور، همان نسخهٔ PHP، همان کش.
تجربه‌ام می‌گوید اگر فقط یکی از این سه متغیر تغییر کند، نتیجه قابل‌اعتماد نیست. قانون کلی‌ام این است: یک تغییر، یک اندازه‌گیری، یک نتیجه‌گیری.
پنج معیار قابل‌اندازه‌گیری
پنج عددی که در هر آزمایش قالب ثبت می‌کنم:
| معیار | واحد | ابزار |
|---|---|---|
| TTFB | میلی‌ثانیه | Network tab یا curl |
| LCP | ثانیه | PageSpeed Insights |
| مجموع بایت CSS/JS | کیلوبایت | Network tab |
| تعداد درخواست استاتیک | عدد | Network tab |
| عمق و تعداد نود DOM | عدد | Console |
این پنج عدد، تفاوت‌ها را بی‌رحمانه آشکار می‌کنند. یک نمونهٔ عملی: در یکی از آزمایش‌هایم، دو قالب با ظاهر بسیار متفاوت، TTFB نزدیک داشتند ولی در بایت‌های CSS فاصلهٔ دو برابری؛ و همین فاصله، LCP را روی اینترنت سلفون به شکلی متفاوت رقم می‌زد.
چیدمان آزمایش: سرور، داده، افزونه
روش من در آزمایش‌های اخیر:
- محیط: یک VPS کوچک با همان مشخصات برای همهٔ قالب‌ها؛ نه هاست اشتراکی که نوسان داشته باشد.
- وردپرس تازه: بدون دادهٔ قبلی، بدون افزونهٔ اضافه. فقط با یک افزونهٔ سئو و یک افزونهٔ فرم.
- دادهٔ مشترک: سه نوشتهٔ ۸۰۰ کلمه‌ای با یک تصویر ۸۰۰×۶۰۰ فشرده، یک برگهٔ ساده، یک برگهٔ تماس با فرم.
- روش تست: هر صفحه، سه بار پشت سر هم در پروفایل Fast 3G روی موبایل شبیه‌سازی‌شده. میانه را ثبت می‌کنم، نه میانگین را.
- کش خاموش: قالب را بدون هیچ افزونهٔ کش می‌سنجم؛ اثر کش را جداگانه در لایهٔ بعد بررسی می‌کنم.
اگر می‌خواهید همین آزمایش را برای سایت خودتان اجرا کنید، یک محیط هاست مناسب کافی است. جزئیات ابزارها را در بهترین ابزارهای تست سرعت سایت آورده‌ام.
در آزمایش قالب، عادلانه بودن مهم‌تر از دقیق بودن است؛ عدد اشتباهِ آزمایش ناعادلانه، بدتر از نبود عدد است.
خواندن نتایج: کدام عدد واقعاً مهم است؟
در نتایج، به ترتیب زیر تصمیم می‌گیرم:
- TTFB: تفاوت زیر ۱۰۰ میلی‌ثانیه را نادیده می‌گیرم؛ بالای ۳۰۰ میلی‌ثانیه، هشدار جدی است.
- مجموع بایت CSS/JS: تفاوت زیر ۵۰ کیلوبایت قابل‌چشم‌پوشی، بالای ۱۵۰ کیلوبایت یعنی قالب بهینه‌نشده.
- عمق DOM: قالب‌هایی که صفحهٔ ساده را بالای ۱۰۰۰ نود می‌سازند، روی موبایل‌های میان‌رده لگ محسوس خواهند داشت.
- LCP: تفاوت زیر نیم‌ثانیه را در حد نوسان می‌بینم؛ تفاوت یک ثانیه‌ای یعنی تصمیم جدی.
این روش به من کمک کرده تا در پروژه‌ها بین دو قالب محبوب، بدون تعصب برند تصمیم بگیرم. اگر می‌خواهید در سطح دقیق‌تر تصمیم بگیرید، پست‌های جداگانه‌ای که نوشته‌ام را ببینید: آسترا در برابر جنریت‌پرس، Hello در برابر Neve و مقایسهٔ سرعت قالب‌های محبوب.
الگوهای تکرارشونده در قالب‌های محبوب
بعد از چند سال آزمایش تکرارشده، چند الگو همیشه تکرار می‌شوند:
- قالب‌های مینیمال (Hello، GeneratePress، Neve): بایت پایین، DOM تخت، TTFB خوب. مشکلشان این است که هر چیزی را باید خودتان بسازید.
- قالب‌های فیچر-محور (Astra با ماژول‌ها، OceanWP، Blocksy): تعادل خوب تا وقتی ماژول‌های اضافه خاموش بمانند. روشن کردن همه‌چیز، آن‌ها را سنگین می‌کند.
- قالب‌های صفحه‌ساز-محور (Divi، قالب‌های با المنتور): بسته به نوع استفاده، سبک تا سنگین. مسئله اینجا خودِ قالب نیست، نحوهٔ استفاده از صفحه‌ساز است.
یک نکته که در آزمایش‌ها همیشه شگفت‌زده‌ام می‌کند: تفاوت بین دو قالب مینیمال، در عمل کم‌تر از تفاوت بین دو حالت استفاده از یک قالب است. یعنی «چطور استفاده می‌کنید» از «چه استفاده می‌کنید» مهم‌تر است.
تصمیم نهایی بر اساس داده
پس از آزمایش، سه معیار تصمیم من است:
- آیا تفاوت‌ها پایدارند؟ اگر دو بار آزمایش را اجرا کردم و نتایج متفاوت شدند، آن تفاوت‌ها را نادیده می‌گیرم.
- آیا تفاوت‌ها به آستانه‌های کاربری می‌رسند؟ تفاوت ۵۰ کیلوبایتی در بایت‌ها، روی ۴G واقعاً حس نمی‌شود؛ تفاوت ۳۰۰ کیلوبایتی، بله.
- آیا قالب برنده در معیار سرعت، در معیارهای دیگر (سازگاری، پشتیبانی، انعطاف) هم قابل‌قبول است؟ سرعت تنها معیار نیست؛ اگر با بررسی سازگاری قالب با افزونه‌ها مشکل داشته باشد، همان برندهٔ سرعت، تصمیم اشتباهی است.
و یک قاعدهٔ شخصی که در پروژه‌ها همیشه رعایت می‌کنم: اگر تفاوت زیر ۱۰٪ بود، تصمیم را به معیارهای دیگر واگذار می‌کنم. تفاوت‌های کوچک سرعت را با استفادهٔ بهتر از قالب می‌توان جبران کرد، ولی پشتیبانی ضعیف یا سازگاری ناقص را نه.
خط پایان
مقایسهٔ سرعت قالب‌های وردپرس اگر با روش درست انجام شود، یک آزمایش چندساعته است نه یک بحث بی‌پایان. پنج عدد، یک محیط مشترک، و یک دادهٔ مشترک، به شما امکان می‌دهد بدون تعصب برند تصمیم بگیرید. مهم‌تر از خودِ نتیجهٔ آزمایش، خودِ عادت آزمایش است: قالب‌ها عوض می‌شوند، نسخه‌ها ارتقا می‌یابند، و آن‌چه امروز سریع است فردا ممکن است نباشد. اگر تجربه‌ای از مقایسهٔ سرعت قالب‌ها در پروژهٔ خودتان دارید — مخصوصاً اگر نتیجه‌اش با انتظار عمومی فرق داشت — در دیدگاه‌ها بنویسید. فهرست الگوهای تکرارشونده را با داده‌های شما دقیق‌تر می‌کنم. 🧪
نویسنده در وردپرس کار.