چگونه سرعت سایت WordPress را سه برابر افزایش دادیم؟

افزایش سرعت سایت وردپرسی تا سه برابر، در نگاه اول به شعار تبلیغاتی شباهت دارد، اما در عمل یک فرآیند قابل اندازه‌گیری است که با عدد و داده اثبات می‌شود. در یکی از پروژه‌های سال گذشته، یک فروشگاه اینترنتی با نزدیک به دو هزار محصول و ترافیک ماهانه چند صدهزار بازدید را تحویل گرفتم که در موبایل با LCP بیش از هفت ثانیه، عملاً عملیات خرید را برای کاربر غیرممکن کرده بود. این مقاله، گزارش فنی همان پروژه است؛ از تشخیص گلوگاه تا رسیدن به LCP زیر ۲.۴ ثانیه.

پیش‌زمینه پروژه و نقطه شروع

این پروژه، یک فروشگاه اینترنتی در حوزه‌ی لوازم خانگی کوچک بود که در بازه‌ی سه سال گذشته روی وردپرس و ووکامرس ساخته شده بود. در زمان تحویل پروژه به من، سایت حدود دو هزار محصول فعال، یازده دسته‌بندی اصلی و یک بلاگ با کمتر از دویست مقاله داشت. صاحب سایت با یک جمله‌ی مشخص تماس گرفت: مشتریان در موبایل خرید نمی‌کنند. آن جمله، نقطه‌ی شروع یک پروژه‌ی بهینه‌سازی سرعت شد که در نهایت، LCP موبایل را از هفت‌و‌نیم ثانیه به زیر دو‌و‌نیم ثانیه رساند.

نکته‌ی مهمی که از همان روز اول مشخص بود این بود که مسئله، فقط یک لایه‌ی فنی نیست. سایت از چند مرحله‌ی رشد سریع گذشته بود؛ در دو سال اول با یک قالب ساده شروع کرده بود، در سال دوم قالب را عوض کرده و در ماه‌های اخیر چند افزونه‌ی سنگین برای بازاریابی و گزارش‌گیری به آن اضافه شده بود. این الگوی رشد، همان چیزی است که در پروژه‌های ووکامرسی زیاد می‌بینم و معمولاً به انباشت بدهی فنی منجر می‌شود. اگر با ساختار کلی این نوع سایت‌ها آشنایی ندارید، راهنمای آیا وردپرس برای فروشگاه اینترنتی مناسب است مرزهای فنی و پیش‌بینی‌های لازم را باز کرده است.

هرچه عمیق‌تر در پروژه‌های بهینه‌سازی کار می‌کنم، بیشتر مطمئن می‌شوم که مسئله‌ی سرعت، بیشتر از آنکه یک مشکل تکنیکی باشد، یک مشکل انباشت تصمیم‌های کوچک است. هر افزونه، هر اسلایدر، هر تصویر که یک بار با ابعاد اصلی آپلود شده، در نهایت خودش را در عدد LCP نشان می‌دهد.

اندازه‌گیری وضعیت اولیه و ثبت خط پایه

قبل از هر اقدامی، یک خط پایه‌ی دقیق از وضعیت سایت ثبت کردم. تجربه‌ی من این است که در پروژه‌های بهینه‌سازی، خط پایه‌ی نادرست، تمام مراحل بعدی را مخدوش می‌کند. خط پایه‌ی این پروژه شامل پنج اندازه‌گیری اصلی بود.

پنج عدد اولیه‌ای که ثبت شد

عدد اول، زمان TTFB بود که در آن زمان حدود ۹۵۰ میلی‌ثانیه در شرایط سرور خالی و تا ۲.۴ ثانیه در ساعات پرترافیک نوسان داشت. عدد دوم، LCP موبایل در صفحه‌ی محصول اصلی که ۷.۴ ثانیه بود. عدد سوم، مجموع بایت‌های CSS و JavaScript در صفحه‌ی محصول که حدود ۹۶۰ کیلوبایت بود. عدد چهارم، تعداد درخواست‌های استاتیک که در صفحه‌ی خانه به ۸۹ درخواست می‌رسید. عدد پنجم، مصرف CPU در پنل هاست در بازه‌ی ساعات پرترافیک که به‌طور مکرر به سقف پلن می‌خورد.

این پنج عدد، دقیقاً همان چیزی است که در راهنمای بهترین ابزارهای تست سرعت سایت به‌عنوان ستون‌های ارزیابی معرفی کرده‌ام. تجربه‌ی من این است که بدون این پنج عدد، تصمیم‌های بهینه‌سازی به حدس تبدیل می‌شوند. در این پروژه، ثبت این پنج عدد در قالب یک جدول ساده، خط سیر تمام پروژه را مشخص کرد.

ثبت اسکرین‌شات و سربرگ Network

علاوه بر اعداد، از سه صفحه‌ی کلیدی (خانه، محصول، دسته‌بندی) اسکرین‌شات از سربرگ Network مرورگر ثبت کردم. این اسکرین‌شات‌ها، در مراحل بعدی نقشه‌ی راهی برای شناسایی فایل‌های اضافه و ترتیب بارگذاری بودند. در پروژه‌های پیچیده، تصویر بصری از Network اغلب جایی است که اولین مظنون‌ها خودشان را نشان می‌دهند.

تشخیص گلوگاه‌های اصلی در چهار لایه

پس از ثبت خط پایه، مرحله‌ی تشخیص آغاز شد. تجربه‌ی من این است که در پروژه‌های بهینه‌سازی، تشخیص درست، نیمی از پروژه است. در این پروژه، گلوگاه‌ها در چهار لایه‌ی متفاوت توزیع شده بودند و ترتیب رفع، از پایین به بالا بود؛ یعنی ابتدا لایه‌ی هاست، سپس قالب، سپس افزونه‌ها و در آخر کش.

لایه اول: گلوگاه هاست

در همان روزهای اول، مشخص شد که هاست فعلی سایت، یک پلن اشتراکی با منابع محدود است که برای سایت محتوایی طراحی شده، نه برای فروشگاه ووکامرسی با دو هزار محصول. TTFB نوسانی، سیگنال اصلی این مسئله بود. علت فنی این نوسان، صف‌بندی منابع CPU بین سایت‌های همسایه روی همان سرور بود که در ساعات پرترافیک، زمان پاسخ‌دهی سایت را چند برابر می‌کرد.

لایه دوم: قالب و ساختار رندر

قالب سایت، یک قالب چندمنظوره‌ی سنگین بود که از سه سال پیش بدون آپدیت جدی استفاده می‌شد. این قالب، در هر صفحه، فایل‌های CSS و JavaScript اضافه‌ای بار می‌کرد که بخش بزرگی از آن‌ها در صفحه‌ی محصول استفاده نمی‌شدند. به‌علاوه، ساختار DOM صفحه به‌دلیل استفاده از اسلایدر و چند لایه ستون تودرتو، عمیق‌تر از حد معمول بود.

لایه سوم: افزونه‌ها و بدهی فنی

در بررسی افزونه‌ها، بیست‌و‌چهار افزونه‌ی فعال پیدا کردم که از این تعداد، هفت افزونه در ۹۰ روز گذشته هیچ تنظیمی روی آن‌ها اعمال نشده بود و سه افزونه، از دو نسخه‌ی قبل به‌روز نشده بودند. این پدیده، همان بدهی فنی است که در مقاله‌ی تأثیر افزونه‌ها بر سرعت سایت به‌تفصیل مکانیزم آن را توضیح داده‌ام. در این پروژه، سه افزونه‌ی گزارش‌گیری و یک افزونه‌ی بازاریابی، بیشترین سهم را در مصرف منابع داشتند.

لایه چهارم: کش و لایه تحویل

سایت از هیچ سیستم کش سروری استفاده نمی‌کرد. تنها لایه‌ی کش موجود، یک افزونه‌ی کش ناقص بود که فقط بخشی از صفحات را کش می‌کرد و در جریان کمپین‌ها به‌طور مرتب پاک می‌شد. نتیجه این بود که هر بازدید، یک رندر کامل PHP و مجموعه‌ای از کوئری‌های دیتابیس را تحمیل می‌کرد. اهمیت این لایه را در راهنمای بهترین افزونه‌های کش وردپرس به‌تفصیل باز کرده‌ام و در ادامه‌ی همین گزارش، به راه‌حل مشخص این پروژه می‌رسم.

لایه اول: بازنگری هاست و پیکربندی سرور

بازنگری هاست، اولین لایه‌ای بود که روی آن کار کردم. تجربه‌ی من این است که اگر این لایه نادرست باشد، هیچ بهینه‌سازی نرم‌افزاری در لایه‌های بالاتر، به نتیجه‌ی مطلوب نمی‌رسد. همان‌طور که در راهنمای تأثیر هاست بر سرعت سایت به‌تفصیل توضیح داده‌ام، هاست، سقف سرعت را تعیین می‌کند.

مهاجرت به هاست با LiteSpeed و NVMe

پس از بررسی چند گزینه، تصمیم گرفتیم سایت را به یک هاست با پردازنده‌ی سریع‌تر، دیسک NVMe و پشتیبانی از سرور LiteSpeed منتقل کنیم. این ترکیب، دو مزیت مستقیم داشت. اول، سرعت خواندن و نوشتن روی دیسک، چند برابر دیسک SATA قدیمی بود که مستقیماً روی زمان کوئری‌های دیتابیس اثر گذاشت. دوم، LiteSpeed، امکان استفاده از کش سروری را فراهم می‌کرد که در لایه‌ی چهارم پروژه، نقش کلیدی داشت. معیارهای کامل این انتخاب را در راهنمای انتخاب هاست برای فروشگاه اینترنتی آورده‌ام.

افزایش منابع و پیکربندی PHP

در پلن جدید، منابع CPU و RAM چند برابر پلن قبلی بود. علاوه بر آن، نسخه‌ی PHP را به آخرین نسخه‌ی پایدار به‌روزرسانی کردیم که به‌تنهایی، در تست‌های خودم حدود هشت درصد بهبود در TTFB ایجاد کرد. پارامترهای memory_limit و max_execution_time نیز به سطح مناسب یک فروشگاه ووکامرسی ارتقا یافتند. اگر با این پارامترها آشنا نیستید، راهنمای رفع خطای Memory Limit در وردپرس مبانی آن‌ها را باز می‌کند.

نتیجه‌ی لایه هاست

پس از مهاجرت و پیکربندی مجدد، TTFB از نوسان بین ۹۵۰ میلی‌ثانیه تا ۲.۴ ثانیه، به بازه‌ی پایدار ۲۸۰ تا ۴۲۰ میلی‌ثانیه رسید. این بهبود، پیش از هر اقدام دیگری در لایه‌های بالاتر، پایه‌ی محکمی برای مراحل بعد ساخت. تجربه‌ی من این است که در پروژه‌های فروشگاهی، اگر لایه‌ی هاست به‌درستی انتخاب نشود، نیمی از بودجه‌ی بهینه‌سازی در لایه‌های بالاتر هدر می‌رود. برای درک چرایی این نکته، مقایسه‌ی جامع مقایسه هاست‌های وردپرس از نظر سرعت نقطه‌ی شروع مناسبی است.

در بهینه‌سازی سرعت، ابتدا لایه‌ی زیرین را تقویت کنید. اصلاح قالب روی هاست ضعیف، مثل تیون کردن موتور ماشینی است که بنزین آن تمام شده.

لایه دوم: قالب و سقف رندر

پس از تثبیت لایه‌ی هاست، مرحله‌ی دوم روی قالب متمرکز شد. قالب فعلی، سه سال پیش انتخاب شده بود و در همان زمان یک قالب چندمنظوره‌ی پرافتخار محسوب می‌شد؛ اما در سال جاری، با حجم بالای داده‌ای که سایت حمل می‌کرد، سقف رندر آن مشخص شده بود.

تحلیل دقیق فایل‌های بارگذاری‌شده

در بررسی دقیق Network، متوجه شدم قالب در هر صفحه، بیست‌و‌دو فایل CSS و شانزده فایل JavaScript بار می‌کند. از این تعداد، بیش از نیمی از فایل‌ها به ماژول‌هایی مربوط می‌شدند که در آن صفحه استفاده نمی‌شدند. این الگو، یکی از شایع‌ترین مظنون‌های کندی در قالب‌های چندمنظوره است که در راهنمای چرا بعضی قالب‌های وردپرس سایت را کند می‌کنند به‌تفصیل مکانیزم آن را باز کرده‌ام.

تصمیم به تغییر قالب

با توجه به حجم تغییرات لازم و ریسک اصلاحات روی قالبی که پشتیبانی فعال نداشت، تصمیم گرفتیم قالب را به یک قالب سبک با تمرکز روی سرعت و سازگاری رسمی با ووکامرس منتقل کنیم. این تصمیم، ریسکی بود؛ چون تغییر قالب در یک سایت فروشگاهی فعال، به‌خودی‌خود یک پروژه‌ی حساس است. مسیر امن این کار را در راهنمای تغییر قالب وردپرس بدون آسیب به‌تفصیل باز کرده‌ام و همان پروتکل را در این پروژه اجرا کردیم.

نتایج لایه قالب

پس از انتقال به قالب جدید، تعداد درخواست‌های استاتیک در صفحه‌ی محصول از ۸۹ به ۳۸ کاهش یافت. مجموع بایت‌های CSS و JavaScript نیز از ۹۶۰ کیلوبایت به ۳۴۰ کیلوبایت رسید. اثر این تغییر روی LCP موبایل، در همان هفته‌ی اول، کاهش حدود دو ثانیه‌ای بود. تجربه‌ی من این است که در پروژه‌های بهینه‌سازی، تغییر قالب یکی از مؤثرترین اقدامات است، به شرطی که با قالب سبک و سازگار انجام شود. فهرستی از قالب‌های سازگار با ووکامرس را در راهنمای بهترین قالب‌های سازگار با ووکامرس آورده‌ام.

لایه سوم: افزونه‌ها و بدهی فنی

پس از تغییر قالب، مرحله‌ی سوم روی افزونه‌ها متمرکز شد. تجربه‌ی من این است که افزونه‌ها، برخلاف قالب، ذاتاً سنگین نیستند؛ اما ترکیب آن‌ها در یک پروژه‌ی بلندمدت، معمولاً به یک بدهی فنی انباشته تبدیل می‌شود.

حذف افزونه‌های بی‌مصرف

در این مرحله، سه افزونه‌ی گزارش‌گیری که در ۹۰ روز گذشته هیچ استفاده‌ای نشده بود حذف شد. علاوه بر آن، دو افزونه‌ی امنیتی که هم‌زمان روی سایت فعال بودند، در یک افزونه ادغام شدند. این ترکیب، به‌جای هم‌افزایی، به‌دلیل هم‌پوشانی اسکن‌ها و بار مضاعف روی سرور، عملاً ضرر می‌رساند. تجربه‌ی من این است که در سایت‌های فروشگاهی، ترکیب افزونه‌های امنیتی چندگانه یکی از شایع‌ترین دلایل کندی است که معمولاً به‌عنوان مقصر نادیده گرفته می‌شود.

جایگزینی افزونه‌های سنگین

افزونه‌ی خبرنامه‌ای که در سایت فعال بود، در هر بازدید یک اسکریپت بزرگ اضافه بار می‌کرد. این افزونه با یک گزینه‌ی سبک‌تر جایگزین شد که تنها در صفحات مشخص بار می‌شد. به‌همین ترتیب، افزونه‌ی اسلایدر صفحه‌ی خانه، که در صفحه‌ی محصول هم فایل‌هایش بار می‌شد، با یک گزینه‌ی مبتنی بر CSS جایگزین شد. تجربه‌ی من این است که هر افزونه‌ای که در تمام صفحات بار می‌کند، باید حداقل یک‌بار با دقت بررسی شود؛ چون معمولاً بخش بزرگی از فایل‌هایش در صفحه‌های دیگر ضروری نیست.

خاموش کردن ماژول‌های بی‌استفاده

در چند افزونه‌ی باقی‌مانده، ماژول‌هایی فعال بودند که در پروژه‌ی فعلی کاربرد نداشتند. تجربه‌ی من این است که در افزونه‌های چندمنظوره، نیمی از ماژول‌ها معمولاً غیرضروری‌اند. خاموش کردن این ماژول‌ها، به‌تنهایی حدود ده درصد کاهش در بار پردازشی ایجاد کرد. اگر با پروتکل پیدا کردن افزونه‌ی مشکل‌ساز آشنا نیستید، راهنمای پیدا کردن و رفع خطای افزونه وردپرس مسیر نظام‌مند را نشان می‌دهد.

لایه چهارم: کش و لایه تحویل

کش، آخرین لایه‌ای بود که در این پروژه روی آن کار شد، اما اثر آن از بسیاری از لایه‌های بالاتر بیشتر بود. تجربه‌ی من این است که کش سروری در سایت‌های فروشگاهی، تعیین‌کننده‌ترین لایه‌ی بهینه‌سازی است، به شرطی که به‌درستی پیکربندی شود.

کش سروری با LiteSpeed

در هاست جدید، LiteSpeed Cache در دسترس بود. با پیکربندی این افزونه، صفحه‌های استاتیک مثل خانه، دسته‌بندی و محصولات، به‌صورت کش‌شده تحویل داده می‌شدند. نتیجه، کاهش TTFB از بازه‌ی ۲۸۰ تا ۴۲۰ میلی‌ثانیه به بازه‌ی ۸۰ تا ۱۴۰ میلی‌ثانیه بود. این کاهش، اثر مستقیمی روی LCP موبایل داشت. جزئیات پیکربندی این لایه را در راهنمای بهترین افزونه‌های کش وردپرس باز کرده‌ام.

پیکربندی استثناها

در سایت‌های فروشگاهی، صفحاتی مثل سبد خرید، تسویه‌حساب و صفحه‌ی کاربری هرگز نباید کش شوند. تجربه‌ی من این است که اگر این استثناها به‌درستی تعریف نشوند، ممکن است رفتار سبد خرید به‌شکل عجیبی مختل شود. در این پروژه، فهرست استثناها را با دقت تنظیم کردیم و پس از هر تغییر، سه صفحه‌ی کلیدی (سبد، تسویه، پرداخت) را تست کردیم.

CDN و لایه تحویل

برای پخش بهتر فایل‌های استاتیک و کاهش بار روی سرور اصلی، یک لایه‌ی CDN به پروژه اضافه شد. این لایه، در سایت‌های فروشگاهی با مخاطب جغرافیایی پراکنده، اثر مستقیم روی زمان تحویل فایل‌ها دارد. نقش دقیق این لایه و پیکربندی درست آن را در راهنمای نقش CDN در سرعت سایت توضیح داده‌ام.

تصویر: پرتکرارترین اما نادیده‌گرفته‌شده‌ترین بخش

در بازه‌ی کار روی این پروژه، یکی از مؤثرترین اقدامات، در لایه‌ی تصویر انجام شد. تجربه‌ی من در پروژه‌های فروشگاهی نشان می‌دهد که تصاویر محصول، بزرگ‌ترین سهم را در بایت‌های صفحه دارند و در عین حال، کمترین توجه را می‌گیرند.

حجم کتابخانه‌ی تصاویر

در بررسی اولیه، کتابخانه‌ی تصاویر سایت حدود ۸.۵ گیگابایت حجم داشت که از این میان، نزدیک به شش گیگابایت به تصاویری اختصاص داشت که در صفحات فعال استفاده نمی‌شدند. علاوه بر آن، بسیاری از تصاویر محصول، در ابعاد اصلی دوربین (چهار تا شش مگاپیکسل) آپلود شده بودند و به‌صورت خودکار توسط CSS کوچک می‌شدند. این الگو، دقیقاً همان چیزی است که در راهنمای فشرده‌سازی تصاویر سایت به‌عنوان شایع‌ترین اشتباه تصویری معرفی کرده‌ام.

تبدیل به WebP و سایزبندی مجدد

تمام تصاویر محصول در سه دسته‌ی مشخص به WebP تبدیل شدند: تصاویر شاخص، تصاویر گالری و تصاویر بند انگشتی. این تبدیل، به‌تنهایی حجم تصاویر فعال را حدود ۵۵ درصد کاهش داد. علاوه بر آن، سایزبندی مجدد بر اساس قالب جدید انجام شد تا تصاویر با ابعادی که در واقع نمایش داده می‌شوند، تولید شوند. تجربه‌ی من این است که در فروشگاه‌های ووکامرسی، این ترکیب دو گانه، مؤثرترین اقدام تصویری است.

lazy-load هوشمند

در قالب جدید، lazy-load به‌طور پیش‌فرض برای همه‌ی تصاویر پایین صفحه فعال بود. اما نکته‌ی مهم این بود که تصاویر شاخص در بالای صفحه، از lazy-load معاف شوند. این تنظیم، LCP را در محصولات پرفروش به‌طور مستقیم بهبود داد. اگر با مبانی Core Web Vitals آشنا نیستید، راهنمای Core Web Vitals چیست و چرا گوگل بر آن تأکید دارد این مفهوم را با اعداد دقیق توضیح می‌دهد.

در بهینه‌سازی تصویر، دو تصمیم کلیدی وجود دارد: کاهش حجم و تنظیم رفتار لود. مورد اول، روی همه‌ی بازدیدکنندگان اثر دارد؛ مورد دوم، به‌طور مستقیم روی LCP و به‌طور غیرمستقیم روی نرخ تبدیل.

شاخص‌های Core Web Vitals و اثر هر اقدام

در طول پروژه، اثر هر اقدام روی شاخص‌های Core Web Vitals به‌طور جداگانه اندازه‌گیری شد. تجربه‌ی من این است که بدون اندازه‌گیری مستقل، ممکن است برخی اقدامات، اثرشان با هم قاطی شود و نتوان درک درستی از اولویت‌ها داشت.

LCP و سهم هر لایه

LCP (Largest Contentful Paint) در این پروژه، به‌طور مستقیم از چهار لایه تأثیر گرفت. از ۷.۴ ثانیه‌ی اولیه، حدود ۱.۵ ثانیه بهبود از لایه‌ی هاست، ۲.۲ ثانیه از لایه‌ی قالب، ۰.۷ ثانیه از لایه‌ی کش و ۰.۹ ثانیه از لایه‌ی تصویر به‌دست آمد. مجموع این چهار لایه، LCP موبایل را به زیر ۲.۴ ثانیه رساند. اگر با مفهوم LCP و آستانه‌های آن آشنا نیستید، راهنمای LCP چیست و چگونه بهینه می‌شود مسیر کامل این مفهوم را نشان می‌دهد.

CLS و تثبیت چیدمان

CLS در این پروژه با چالش کمتری روبه‌رو شد، اما دو مسئله‌ی مشخص وجود داشت. اول، برخی تصاویر بدون ابعاد مشخص در کد HTML بودند که پس از بارگذاری، چیدمان را جابه‌جا می‌کردند. دوم، فونت‌های فارسی بدون font-display مناسب، در لحظه‌ی بارگذاری، باعث پرش متن می‌شدند. هر دو مسئله در لایه‌ی قالب حل شدند. برای درک عمیق‌تر این شاخص، راهنمای CLS چیست و چگونه کاهش می‌یابد تمام مراحل را باز کرده است.

INP و پاسخ‌گویی به تعامل

INP (Interaction to Next Paint) در این پروژه، به‌دلیل حذف افزونه‌های سنگین و کاهش JS صفحه، به‌طور محسوسی بهبود یافت. تجربه‌ی من این است که در سایت‌های فروشگاهی، INP به‌طور مستقیم از تعداد و حجم جاوااسکریپت‌های انباشته تأثیر می‌گیرد. کاهش ۶۲۰ کیلوبایت JS از این پروژه، اثر مستقیم روی این شاخص داشت.

جدول قبل و بعد: نتیجه عددی پس از ۹ هفته

پس از نه هفته کار مستمر، وضعیت نهایی سایت به‌طور دقیق اندازه‌گیری شد. تجربه‌ی من این است که ارائه‌ی نتیجه در قالب جدول، هم برای تیم فنی روشن‌گر است و هم برای صاحب کسب‌وکار ملموس.

اثر تجاری بهبود سرعت

علاوه بر شاخص‌های فنی، اثر تجاری این تغییرات نیز اندازه‌گیری شد. نرخ تبدیل موبایل، در بازه‌ی سه ماهه‌ی پس از بهینه‌سازی، حدود ۴۲ درصد افزایش یافت. نرخ پریدَن (Bounce Rate) موبایل، حدود ۲۵ درصد کاهش پیدا کرد. تجربه‌ی من این است که در فروشگاه‌های ووکامرسی، بهبود LCP موبایل، به‌طور مستقیم روی نرخ تبدیل اثر می‌گذارد. پیوند بین سرعت و سئو را نیز در راهنمای چگونه سرعت سایت بر سئو اثر می‌گذارد به‌تفصیل باز کرده‌ام و همان منطق، در این پروژه نیز برقرار بود.

درس‌های این پروژه برای پروژه‌های مشابه

پس از اتمام این پروژه، الگویی که در آن شکل گرفته بود را در چندین پروژه‌ی بعدی تکرار کردم و نتیجه تقریباً مشابه بود. تجربه‌ی من این است که در پروژه‌های بهینه‌سازی ووکامرس، چند درس کلیدی به‌طور مکرر تکرار می‌شوند.

ترتیب اهمیت دارد

در این پروژه، اگر ابتدا کش را پیکربندی می‌کردیم و بعد هاست را عوض می‌کردیم، نصف اثر کش از دست می‌رفت. ترتیب از پایین به بالا، یعنی هاست، قالب، افزونه، کش و تصویر، بهترین نتیجه را می‌دهد. تجربه‌ی من این است که در پروژه‌های بعدی، همیشه این ترتیب را رعایت می‌کنم و نتیجه‌اش قابل‌پیش‌بینی‌تر است.

تصویر، آسان‌ترین برد است

بهینه‌سازی تصویر، ساده‌ترین بخش پروژه بود که با یک افزونه‌ی بهینه‌ساز و اندکی پیکربندی انجام شد، اما اثر آن روی LCP موبایل، به‌تنهایی حدود یک ثانیه بود. تجربه‌ی من این است که در اکثر پروژه‌های ووکامرسی، تصویر پرتکرارترین و مؤثرترین برد سریع است. اگر با ابزارهای این کار آشنا نیستید، راهنمای بهترین افزونه‌های بهینه‌سازی تصاویر وردپرس نقطه‌ی شروع مناسبی است.

اندازه‌گیری مستمر، نه مقطعی

در طول پروژه، هر هفته اعداد را ثبت کردم. این کار، هم روند بهبود را نشان می‌داد و هم در جریان پروژه مشخص کرد که کدام اقدام مؤثرتر بوده است. تجربه‌ی من این است که بهینه‌سازی سرعت، بدون اندازه‌گیری مستمر، به آزمون‌وخطا تبدیل می‌شود. برای تکمیل این بخش، پیشنهاد می‌کنم راهنمای افزایش سرعت وردپرس را نیز مرور کنید تا درک کلی از ترتیب لایه‌ها داشته باشید.

پرسش‌های پرتکرار درباره افزایش سرعت سایت وردپرسی

در این بخش، به پرتکرارترین پرسش‌هایی که در جلسه‌های مشاوره با آن روبه‌رو می‌شوم پاسخ کوتاه و فنی داده‌ام؛ ساختاری که برای هر دو مخاطب انسانی و موتورهای پاسخ‌ده مفید است.

آیا کش به‌تنهایی می‌تواند سایت را سه برابر سریع‌تر کند؟

در بعضی سایت‌ها بله، ولی در سایت‌های فروشگاهی با TTFB بالا و LCP بد، کش به‌تنهایی کافی نیست. تجربه‌ی من این است که در فروشگاه‌های ووکامرس، بهبود سه‌برابری معمولاً نتیجه‌ی ترکیب چند لایه است: هاست، قالب، کش و تصویر. اگر فقط یک لایه را بهینه کنید، احتمالاً بهبود قابل‌توجهی می‌بینید، ولی سه‌برابر شدن نیاز به نگاه سیستمی دارد.

تغییر قالب در یک فروشگاه فعال ریسک‌پذیر است؟

تغییر قالب، به‌خودی‌خود یک عملیات حساس است، اما اگر با یک پروتکل مشخص انجام شود، ریسک آن قابل‌کنترل است. کلید ماجرا، تست کامل در محیط staging پیش از اعمال روی سایت زنده، و پایش دقیق دو هفته‌ی اول است. تجربه‌ی من این است که در پروژه‌های فروشگاهی، این ریسک زمانی قابل‌پذیرش است که بهبود سرعت، مستقیماً به نرخ تبدیل گره خورده باشد.

چه مدت طول می‌کشد تا سایت وردپرسی سه برابر سریع‌تر شود؟

در این پروژه، بازه‌ی زمانی نه هفته بود. تجربه‌ی من این است که بازه‌ی زمانی به سه عامل بستگی دارد: حجم سایت، میزان بدهی فنی انباشته و آزادی عمل تیم در تغییرات. در سایت‌های کوچک‌تر، این بازه می‌تواند به سه تا چهار هفته کاهش یابد و در سایت‌های بزرگ‌تر، ممکن است تا سه ماه هم طول بکشد.

آیا بهبود سرعت، روی سئو اثر مستقیم دارد؟

بله، به‌طور غیرمستقیم. گوگل از سال ۲۰۲۱، Core Web Vitals را به‌عنوان یکی از سیگنال‌های رتبه‌بندی معرفی کرده است. تجربه‌ی من این است که در پروژه‌های بهینه‌سازی، بهبود سرعت به‌تنهایی رتبه را چند پله بالا نمی‌برد، اما در ترکیب با محتوای باکیفیت، تفاوت محسوسی ایجاد می‌کند. راهنمای تخصصی‌تر این موضوع در سئو تکنیکال از خزش تا ایندکس آمده است.

آیا هاست اشتراکی برای فروشگاه ووکامرس کافی است؟

برای فروشگاه‌های کوچک، هاست اشتراکی باکیفیت ممکن است کافی باشد. اما در فروشگاه‌هایی با بیش از هزار محصول و ترافیک قابل‌توجه، هاست اشتراکی معمولاً به سقف منابع می‌خورد و کندی به‌سرعت ظاهر می‌شود. تجربه‌ی من این است که در پروژه‌های این حجم، انتقال به هاست اختصاصی‌تر یا VPS یک ضرورت است، نه یک انتخاب.

آیا بهینه‌سازی تصویر، اثر مستقیم روی نرخ تبدیل دارد؟

به‌طور غیرمستقیم بله. تصویر سنگین، زمان LCP را افزایش می‌دهد و LCP بالاتر، نرخ پریدَن را بالا می‌برد. تجربه‌ی من این است که در پروژه‌های فروشگاهی، بهینه‌سازی تصویر مؤثرترین اقدام سریع برای کاهش LCP است و LCP پایین‌تر، در ماه‌های بعد به‌شکل افزایش نرخ تبدیل دیده می‌شود.

آیا استفاده از CDN برای فروشگاه ضروری است؟

اگر مخاطب شما در یک منطقه‌ی جغرافیایی متمرکز است، CDN ممکن است اثر محسوسی نداشته باشد. اما اگر مخاطب شما پراکنده است یا از چند منطقه‌ی جغرافیایی وارد می‌شود، CDN اثر مستقیم روی زمان تحویل فایل‌ها دارد. تجربه‌ی من این است که در سایت‌های فروشگاهی، CDN در ترکیب با کش سروری، بهترین نتیجه را می‌دهد.

چه چیزی این پروژه را به الگوی تکرارپذیر تبدیل می‌کند

افزایش سرعت سایت وردپرسی تا سه برابر، نتیجه‌ی یک عملیات جادویی نبود؛ نتیجه‌ی یک فرآیند نظام‌مند بود که در آن، هر لایه با ترتیب مشخص و بر اساس اندازه‌گیری دقیق، بهینه شد. اگر بخواهم این پروژه را در سه ویژگی خلاصه کنم، آن‌ها عبارتند از: تشخیص درست گلوگاه در لایه‌ی پایین‌تر، رعایت ترتیب از هاست به کش، و اندازه‌گیری مستمر و هفتگی که اجازه نداد هیچ اقدام بی‌اثر، وقت پروژه را هدر دهد.

تجربه‌ی من این است که این الگو، در هر پروژه‌ی بهینه‌سازی ووکامرسی قابل بازتولید است، به شرطی که با صبر و نظم اجرا شود. اگر امروز با فروشگاهی روبه‌رو هستید که در موبایل سرعت پایین دارد، توصیه‌ی عملی من این است: ابتدا پنج عدد کلیدی را ثبت کنید، سپس با ترتیب هاست، قالب، افزونه، کش و تصویر، هر لایه را جداگانه بهینه کنید و پس از هر اقدام، اعداد را دوباره اندازه بگیرید. این انضباط، شما را از پروژه‌های بهینه‌سازی سرگردان نجات می‌دهد. ⚡

اگر در پروژه‌ی بهینه‌سازی خودتان به چالش خاصی برخوردید — مثلاً قالبی که با ووکامرس تعارض داشت، هاستی که با وجود کیفیت خوب منابع کم می‌آورد، یا افزونه‌ای که رفتار غیرمنتظره نشان می‌داد — تجربه‌تان را در دیدگاه‌ها بنویسید. پرونده‌های واقعی این‌گونه، همیشه ارزشمندتر از توصیه‌های کلی برای خواننده‌ی بعدی هستند. 🛠️