تاثیر سرعت سایت در سئو چقدر است؟ بررسی تاثیر واقعی روی رتبه

یه سؤال قدیمی هست که هنوز جواب‌های متناقضی بهش داده می‌شه: سرعت سایت واقعاً چقدر روی رتبه‌ی گوگل اثر داره؟

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

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

در این مقاله بخش اول می‌بینیم سرعت دقیقاً چه نقشی در رتبه‌بندی گوگل داره (با تفکیک واقعیت از افسانه)، معیارهای امروزی گوگل چی هستن و چطور سنجیده می‌شن، سرعت چه اثری روی فروش و درآمد داره، و چطور سایتمون رو درست اندازه بگیریم. در بخش دوم سراغ روش‌های عملی افزایش سرعت می‌ریم.

یک مرور کوتاه

برای اینکه بفهمیم امروز کجاییم، بد نیست بدونیم از کجا شروع شد.

در سال ۲۰۱۰ گوگل رسماً اعلام کرد سرعت بارگذاری صفحه رو به‌عنوان یکی از سیگنال‌های رتبه‌بندی در جستجوی دسکتاپ در نظر می‌گیره. این اولین بار بود که سرعت رسماً وارد معادله‌ی سئو شد، هرچند تأثیرش در اون زمان بسیار محدود بود.

اینجا باید یه اشتباه رایج رو تصحیح کنم. در خیلی از مقالات فارسی نوشته شده که در سال ۲۰۱۳ با به‌روزرسانی الگوریتم پنگوئن، اهمیت سرعت سایت بیشتر شد. این درست نیست. الگوریتم پنگوئن اصلاً ربطی به سرعت نداشت؛ هدفش مقابله با لینک‌سازی مصنوعی و هرزنامه بود.

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

سرعت واقعاً چقدر روی رتبه اثر دارد؟

حالا بریم سراغ سؤال اصلی و جواب صادقانه‌ش.

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

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

یعنی چی؟ یعنی:

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

اما اگه محتوای شما خوبه و در یه فضای رقابتی هستید که ده تا سایت دیگه هم محتوای خوبی دارن، سرعت می‌تونه همون تفاوت کوچیکی باشه که شما رو بالاتر می‌بره.

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

سه معیاری که باید بشناسید

گوگل کیفیت تجربه‌ی صفحه رو با سه معیار می‌سنجه که مجموعاً بهشون می‌گن Core Web Vitals. این سه تا رو یاد بگیرید، چون تقریباً هر بحث فنی درباره‌ی سرعت به اون‌ها برمی‌گرده.

LCP؛ کاربر چقدر منتظر می‌ماند تا چیزی ببیند

مخفف Largest Contentful Paint و به فارسی یعنی «زمان نمایش بزرگ‌ترین بخش محتوا». این معیار اندازه می‌گیره چقدر طول می‌کشه تا بزرگ‌ترین عنصر قابل مشاهده‌ی صفحه (معمولاً تصویر اصلی یا بلوک متن اصلی) کامل نمایش داده بشه.

حد مطلوب: زیر ۲.۵ ثانیه. بین ۲.۵ تا ۴ ثانیه یعنی نیاز به بهبود، و بالای ۴ ثانیه یعنی ضعیف.

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

INP؛ سایت چقدر سریع به کاربر جواب می‌دهد

مخفف Interaction to Next Paint. این معیار می‌سنجه از لحظه‌ای که کاربر کاری می‌کنه (کلیک، لمس، فشردن کلید) تا لحظه‌ای که صفحه واکنش بصری نشون می‌ده، چقدر طول می‌کشه.

حد مطلوب: زیر ۲۰۰ میلی‌ثانیه.

این معیار از مارس ۲۰۲۴ جایگزین معیار قدیمی‌تری به نام FID شده و اگه در مقاله‌ای هنوز اسم FID رو دیدید، بدونید اون مطلب قدیمیه. تفاوت مهمشون اینه که معیار قدیمی فقط اولین تعامل کاربر رو می‌سنجید، اما INP همه‌ی تعامل‌ها در طول بازدید رو در نظر می‌گیره. برای همین به‌مراتب سخت‌گیرانه‌تره.

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

CLS؛ آیا صفحه زیر دست کاربر می‌پرد

مخفف Cumulative Layout Shift. این یکی سرعت رو نمی‌سنجه، ثبات بصری رو می‌سنجه. حتماً براتون پیش اومده که خواستید روی یه دکمه کلیک کنید و درست در همون لحظه یه بنر لود شده و کل صفحه جابه‌جا شده و شما روی چیز دیگه‌ای کلیک کردید. CLS دقیقاً همینه.

حد مطلوب: زیر ۰.۱.

خبر خوب اینه که این معیار معمولاً ساده‌ترین برای رفعه؛ اصلی‌ترین علتش تصاویری هستن که ابعادشون در کد مشخص نشده و فضایی که برای عناصر دیرلودشونده رزرو نشده.

نکته‌ای که همه‌چیز را عوض می‌کند: داده‌ی میدانی

اینجا مهم‌ترین بخش این مقاله‌ست و متأسفانه جایی بهش پرداخته نشده. خیلی‌ها آدرس سایتشون رو در یه ابزار تست می‌زنن، نمره‌ی ۹۵ می‌گیرن و خیالشون راحت می‌شه. بعد در سرچ کنسول می‌بینن گوگل می‌گه سایتشون مشکل داره و گیج می‌شن. دلیلش اینه که دو نوع داده وجود داره:

• داده‌ی آزمایشگاهی (Lab). وقتی شما سایت رو تست می‌کنید، یه شبیه‌سازی در شرایط کنترل‌شده انجام می‌شه. مفیده برای عیب‌یابی، اما نماینده‌ی واقعیت نیست.
• داده‌ی میدانی (Field). این داده از مرورگر کاربران واقعی شما جمع‌آوری می‌شه؛ کاربرانی با گوشی‌های متفاوت، اینترنت‌های متفاوت و در نقاط جغرافیایی مختلف. گوگل برای رتبه‌بندی فقط از همین داده استفاده می‌کنه.

و دو تا جزئیات مهم درباره‌ی نحوه‌ی سنجش:

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

دوم، بازه‌ی سنجش ۲۸ روز متحرکه. یعنی وقتی امروز یه بهبود اعمال می‌کنید، اثرش بلافاصله در گزارش دیده نمی‌شه و باید چند هفته صبر کنید. خیلی‌ها بعد از یه روز نتیجه نمی‌بینن و فکر می‌کنن کارشون بی‌فایده بوده.

نتیجه‌ی عملی این دو تا نکته اینه: نمره‌ی تست سرعت، هدف شما نیست. نمره ابزار عیب‌یابیه. هدف واقعی، سبز شدن سه معیار در داده‌ی میدانیه.

سرعت و پول: آنچه داده‌ها می‌گویند

معتبرترین مطالعه‌ی این حوزه پژوهشیه که دیلویت و گوگل در سال ۲۰۲۰ با عنوان «میلی‌ثانیه‌ها میلیون‌ها می‌سازند» منتشر کردن. در این مطالعه داده‌ی ۳۷ برند در حوزه‌های خرده‌فروشی، گردشگری، لوکس و جذب سرنخ بررسی شد. نتیجه:

فقط یک‌دهم ثانیه بهبود در سرعت سایت موبایل، با افزایش ۸.۴ درصدی نرخ تبدیل در خرده‌فروشی و ۹.۲ درصدی میانگین ارزش سفارش همراه بود. در حوزه‌ی گردشگری، نرخ تبدیل ۱۰.۱ درصد بالا رفت. و در سایت‌های جذب سرنخ، نرخ خروج ۸.۳ درصد کاهش پیدا کرد.

یک‌دهم ثانیه؛ یعنی کمتر از یه پلک زدن.

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

و چند نمونه‌ی موردی که خود گوگل منتشر کرده هم جالبن: یه اپراتور مخابراتی بزرگ در ایتالیا با ۳۱ درصد بهبود در معیار LCP، هشت درصد فروش بیشتر ثبت کرد. یه فروشگاه اینترنتی ژاپنی بعد از سبز کردن معیارها، درآمد به ازای هر بازدیدکننده‌ش بیش از ۵۰ درصد رشد کرد. و یه سرویس فروش بلیت با بهبود معیار INP، هفت درصد فروش بیشتر داشت.

در سمت مقابل هم داده هست! احتمال خروج کاربر موبایل، وقتی زمان بارگذاری از یک ثانیه به سه ثانیه می‌ره، حدود ۳۲ درصد افزایش پیدا می‌کنه.

یک هشدار روش‌شناختی

حالا که این اعداد رو دیدید، یه نکته‌ی مهم رو هم بگم! بیشتر این داده‌ها از مطالعات موردی و مقایسه‌های قبل و بعد میان، نه از آزمایش‌های کاملاً کنترل‌شده. یعنی همبستگی رو نشون می‌دن، نه لزوماً رابطه‌ی علت و معلولی دقیق.

پس این اعداد رو به‌عنوان راهنمای جهت‌دهنده ببینید، نه فرمول قطعی. اینکه «اگه سایتم رو ۰.۱ ثانیه سریع‌تر کنم دقیقاً ۸.۴ درصد بیشتر می‌فروشم» برداشت درستی نیست. برداشت درست اینه که رابطه‌ی بین سرعت و درآمد واقعی و قابل توجهه، و اندازه‌ش برای سایت شما باید با تست خودتون مشخص بشه.

یک اثر پنهان: بودجه‌ی خزش

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

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

پس اگه سایت کوچیکی دارید، نگران بودجه‌ی خزش نباشید؛ این مسئله‌ی شما نیست. اما اگه سایت بزرگی دارید، این یکی از دلایل جدی برای سرمایه‌گذاری روی زیرساخته.

چطور سرعت سایتمان را درست بسنجیم؟

حالا که فهمیدیم چی مهمه، بریم سراغ اندازه‌گیری. چند تا ابزار هست و هر کدوم کار متفاوتی می‌کنن.

سرچ کنسول؛ نقطه‌ی شروع

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

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

PageSpeed Insights؛ برای عیب‌یابی

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

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

بقیه‌ی ابزارها

GTmetrix برای دیدن آبشار بارگذاری فایل‌ها مفیده؛ یعنی می‌بینید کدوم فایل چقدر طول کشیده و ترتیب لود شدن چطور بوده.

WebPageTest امکانات پیشرفته‌تری داره و اجازه می‌ده از موقعیت‌های جغرافیایی و سرعت‌های اینترنت مختلف تست کنید.

و اگه توسعه‌دهنده هستید، افزونه‌ی Web Vitals برای کروم و بخش Performance ابزار توسعه‌دهندگان مرورگر، امکان دیدن این معیارها در لحظه رو می‌دن.

چند اشتباه رایج در تست کردن

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

چطور سرعت سایت را بالا ببریم؟

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

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

هاست

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

معیاری که اینجا مهمه TTFB یا زمان دریافت اولین بایته. اگه این عدد بالا باشه، هر کاری با تصاویر و جاوااسکریپت بکنید، LCP شما همچنان بد می‌مونه؛ چون کاربر اصلاً هنوز چیزی دریافت نکرده که رندر بشه.

چند تا چیز که مستقیماً روی این عدد اثر می‌ذارن:

• نسخه‌ی PHP. ساده‌ترین و کم‌هزینه‌ترین بهبود ممکن. نسخه‌های جدید PHP به‌شکل محسوسی از نسخه‌های قدیمی سریع‌ترن و ارتقاش معمولاً از پنل هاست و در کمتر از دو دقیقه انجام می‌شه. فقط قبلش بک‌آپ بگیرید و بعدش سایت رو تست کنید.
• منابع پردازشی. در هاست اشتراکی ارزون، ده‌ها سایت روی یه سرور نشستن و در ساعات شلوغی برای منابع رقابت می‌کنن. نتیجه‌ش نوسان شدید سرعته؛ سایتی که صبح سریعه و عصر کند. این نوسان دقیقاً همون چیزیه که در داده‌ی میدانی گوگل خودش رو نشون می‌ده.
• کش آبجکت. اگه هاستتون Redis ارائه می‌ده، فعال کردنش برای سایت‌های پویا (مخصوصاً فروشگاه‌ها) تفاوت واقعی ایجاد می‌کنه، چون نتایج کوئری‌های تکراری دیتابیس در حافظه نگه داشته می‌شن.
• پروتکل ارتباطی. از هاستتون بپرسید HTTP/2 یا HTTP/3 پشتیبانی می‌شه یا نه. این پروتکل‌ها اجازه می‌دن فایل‌ها موازی و کارآمدتر منتقل بشن.

توی مقاله بهترین هاست وردپرسی ایران میتونید سرویس تمام شرکت‌های هاستینگ رو ببینید و با هم مقایسه کنید تا بهترین انتخاب رو داشته باشید.

قالب

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

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

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

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

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

کش؛ بزرگ‌ترین جهش با کمترین زحمت

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

انواع کش که باید بشناسید

• کش صفحه. مهم‌ترین نوع. کل خروجی HTML صفحه ذخیره می‌شه.
• کش آبجکت. نتایج کوئری‌های دیتابیس در حافظه نگه داشته می‌شن. برای صفحاتی که نمی‌شه کامل کششون کرد (مثل سبد خرید) حیاتیه.
• OPcache. کد کامپایل‌شده‌ی PHP در حافظه می‌مونه تا هر بار از نو تفسیر نشه. معمولاً سمت سرور فعاله.
• کش مرورگر. به مرورگر کاربر می‌گه فایل‌های ثابت رو ذخیره کنه تا در بازدید بعدی دوباره دانلود نشن.

نکته‌ی حیاتی برای فروشگاه‌ها

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

همین‌طور کاربران واردشده باید نسخه‌ی غیرکش‌شده ببینن، وگرنه نام کاربری اشتباه نمایش داده می‌شه.

افزونه‌ی رخش رو ما دقیقاً با همین نگاه ساختیم و روی سایت‌های خودمون هم ازش استفاده می‌کنیم. کش کامل صفحه به‌صورت HTML استاتیک و کش PHP (که از کش دیسک سریع‌تره)، کش آبجکت با Redis، گرم کردن OPcache و کش مرورگر، همگی داخلشن. عبور خودکار سبد خرید، تسویه حساب، صفحه‌ی ورود و کاربران واردشده از کش هم به‌صورت پیش‌فرض انجام می‌شه، پس اون خطر بالا رو ندارید.

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

یک هشدار مهم

هیچ‌وقت دو تا افزونه‌ی کش صفحه رو هم‌زمان فعال نکنید. این یکی از رایج‌ترین دلایل خرابی‌های عجیب در وردپرسه؛ از صفحه‌ی سفید گرفته تا محتوایی که به‌روز نمی‌شه. اگه افزونه‌ی کش عوض می‌کنید، قبلیه رو کامل حذف کنید و مطمئن بشید فایل‌های باقی‌مونده‌ش (مثل تنظیمات داخل .htaccess یا فایل advanced-cache.php) هم پاک شدن.

تصاویر

در اکثر سایت‌ها، تصاویر بیش از نصف حجم صفحه رو تشکیل می‌دن. خبر خوب اینه که بهینه‌سازیشون هم از همه ساده‌تره.

فرمت مدرن. تبدیل تصاویر به WebP یا AVIF معمولاً حجم رو به‌شکل قابل توجهی کم می‌کنه بدون افت کیفیت محسوس. این کار رو دستی نکنید؛ افزونه‌های بهینه‌سازی این تبدیل رو خودکار انجام می‌دن و نسخه‌ی مناسب رو به هر مرورگر تحویل می‌دن.

ابعاد درست. یه اشتباه رایج اینه که تصویر ۳۰۰۰ پیکسلی آپلود می‌شه و بعد با CSS به ۶۰۰ پیکسل کوچیک می‌شه. کاربر همچنان کل حجم رو دانلود می‌کنه. تصاویر رو در ابعاد واقعی مورد نیازشون آپلود کنید.

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

بارگذاری تنبل (Lazy Load). تصاویری که پایین صفحه هستن و کاربر هنوز نمی‌بینتشون، فقط موقع رسیدن به اون‌ها لود بشن.

یک استثنای مهم

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

منطقش هم ساده‌ست! چون معمولاً همون تصویر بزرگ بالای صفحه، عنصر LCP شماست. اگه بهش بگید «تنبل باش و دیرتر لود شو»، عملاً دارید به مرورگر می‌گید مهم‌ترین عنصر صفحه رو با تأخیر نشون بده.

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

جاوااسکریپت و CSS

یادتون هست گفتم INP سخت‌ترین معیار برای پاس کردنه؟ دلیلش همین بخشه.

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

فشرده‌سازی (Minify). حذف فاصله‌ها و کامنت‌های اضافی از فایل‌های CSS و JS. کم‌ریسک‌ترین کار این بخشه، هرچند اثرش هم متوسطه.

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

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

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

هر چند وقت یه بار فهرست ابزارهای جانبی سایتتون رو مرور کنید و هر چیزی که واقعاً استفاده نمی‌شه رو حذف کنید. قابلیت کنترل ارتباطات خروجی در رخش دقیقاً همین رو نشون می‌ده: سایت شما به چه سرورهایی درخواست می‌فرسته و کدومشون کند هستن. امکان مسدودسازی هاست‌های کند و تعیین تایم‌اوت هم هست.

فونت

این بخش برای ما اهمیت بیشتری داره، چون فونت‌های فارسی به‌طور طبیعی سنگین‌ترن؛ تعداد حروف و حالت‌های اتصالشون بیشتره.

فونت رو از سرور خودتون سرو کنید. بارگذاری فونت از سرویس‌های خارجی هم یه درخواست اضافه به سرور دیگه‌ست و هم در شرایط ایران ممکنه کند یا در دسترس نباشه.

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

حتماً font-display: swap رو فعال کنید. بدون این تنظیم، مرورگر تا لود شدن کامل فونت، متن رو نامرئی نگه می‌داره. یعنی کاربر چند لحظه یه صفحه‌ی تقریباً خالی می‌بینه و این مستقیماً معیار LCP رو خراب می‌کنه. با این تنظیم، متن اول با فونت پیش‌فرض نمایش داده می‌شه و بعد فونت اصلی جایگزین می‌شه.

پیش‌بارگذاری فونت اصلی. به مرورگر بگید فونت اصلی صفحه رو زودتر شروع به دانلود کنه.

دیتابیس و افزونه‌ها

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

پاکسازی این‌ها کم‌ریسکه و بیشتر افزونه‌های بهینه‌سازی به‌صورت زمان‌بندی‌شده انجامش می‌دن.

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

و در نهایت، فهرست افزونه‌ها رو مرور کنید. هر افزونه‌ای که واقعاً استفاده نمی‌شه رو حذف کنید، نه فقط غیرفعال. افزونه‌ی غیرفعال جای کمتری اشغال می‌کنه اما همچنان یه سطح حمله‌ی امنیتیه.

CDN

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

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

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

اشتباهاتی که به‌جای تسریع، سایت را خراب می‌کنند

این بخش رو اضافه کردم چون در عمل، بهینه‌سازی بد از بهینه‌سازی نکردن بدتره.

• فعال کردن همه‌ی گزینه‌ها یکجا. رایج‌ترین اشتباه. کاربر افزونه‌ی کش رو نصب می‌کنه و همه‌ی تیک‌ها رو می‌زنه. بعد سایت به‌هم می‌ریزه و چون ده تا تغییر هم‌زمان داده، نمی‌فهمه کدومش مقصر بوده. گزینه‌ها رو یکی‌یکی فعال کنید و بعد از هر کدوم سایت رو تست کنید.
• فشرده‌سازی و ترکیب بی‌محابای فایل‌ها. فشرده‌سازی JS گاهی اسکریپت‌های حساس رو خراب می‌کنه و علامتش هم معمولاً از کار افتادن یه دکمه یا اسلایدره، نه یه خطای واضح. بعد از فعال کردن این گزینه‌ها، حتماً فرم‌ها، سبد خرید و بخش‌های تعاملی رو تست کنید.
• بارگذاری تنبل روی تصویر اصلی. که بالاتر مفصل توضیح دادم.
• تست کردن بدون پاک کردن کش. تغییر می‌دید، تست می‌کنید، فرقی نمی‌بینید و ناامید می‌شید؛ در حالی که فقط دارید نسخه‌ی قدیمی کش‌شده رو می‌بینید. بعد از هر تغییر، کش سایت و مرورگر رو پاک کنید و در حالت ناشناس تست کنید.
• انتظار نتیجه‌ی فوری در گزارش گوگل. یادتون باشه داده‌ی میدانی در بازه‌ی ۲۸ روزه جمع می‌شه. بهبود امروز، چند هفته بعد در سرچ کنسول دیده می‌شه.
• تعقیب نمره‌ی صد. رسیدن از ۸۵ به ۱۰۰ معمولاً روزها وقت می‌گیره و هیچ اثر محسوسی روی تجربه‌ی واقعی کاربر یا رتبه نداره. اگه سه معیار اصلی در داده‌ی میدانی سبزن، کارتون تمومه؛ برید سراغ محتوا.

یک برنامه‌ی عملی

اگه نمی‌دونید از کجا شروع کنید، این ترتیب رو پیشنهاد می‌کنم.

روز اول:بک‌آپ بگیرید. نسخه‌ی PHP رو به‌روز کنید. وضعیت فعلی رو در سرچ کنسول و PageSpeed یادداشت کنید تا بعداً بتونید مقایسه کنید.

هفته‌ی اول: افزونه‌ی کش نصب و تنظیم کنید (فقط یکی). بهینه‌سازی و تبدیل تصاویر رو فعال کنید. افزونه‌های غیرضروری رو حذف کنید.

هفته‌ی دوم: سراغ CSS و جاوااسکریپت برید. فشرده‌سازی، تأخیر اجرای اسکریپت‌ها و حذف CSS بلااستفاده. بعد از هر تغییر تست کنید.

هفته‌ی سوم: فونت‌ها رو مرتب کنید و اسکریپت‌های شخص ثالث رو مرور و پاکسازی کنید.

یک ماه بعد: سرچ کنسول رو دوباره نگاه کنید و با عدد اولیه مقایسه کنید. حالا داده‌ی میدانی کافی جمع شده که بفهمید چقدر جلو رفتید.

چک‌لیست سرعت

• هاست منابع پردازشی کافی دارد و TTFB قابل قبول است
• نسخه PHP روی یکی از نسخه‌های پشتیبانی‌شده و جدید است
• فقط یک افزونه کش فعال است
• کش صفحه فعال است و سبد خرید، تسویه و کاربران واردشده از آن مستثنا هستند
• کش آبجکت (Redis) در صورت وجود فعال است
• تصاویر به WebP یا AVIF تبدیل می‌شوند
• تصاویر در ابعاد واقعی موردنیاز آپلود می‌شوند
• عرض و ارتفاع تصاویر در کد مشخص است
• بارگذاری تنبل فعال است اما تصویر اصلی صفحه مستثنا شده
• فایل‌های CSS و JS فشرده می‌شوند
• اجرای اسکریپت‌های غیرضروری تا تعامل کاربر به تعویق می‌افتد
• فونت‌ها از سرور خودم سرو می‌شوند و font-display روی swap است
• فقط وزن‌های موردنیاز فونت لود می‌شوند
• اسکریپت‌های شخص ثالث مرور و پاکسازی شده‌اند
• افزونه‌های بلااستفاده حذف (نه فقط غیرفعال) شده‌اند
• دیتابیس به‌صورت دوره‌ای پاکسازی می‌شود
• سرعت صفحه محصول و مقاله هم تست شده، نه فقط صفحه اصلی
• سه معیار اصلی در سرچ کنسول سبز هستند

سوالات متداول

جمع‌بندی

سرعت سایت نه اون چیزیه که بعضی می‌گن (مهم‌ترین فاکتور سئو) و نه اون چیزی که بعضی دیگه می‌گن (بی‌اهمیت). یه سیگنال رتبه‌بندی واقعی اما فرعیه که وقتی رقابت نزدیک باشه تعیین‌کننده می‌شه، و در کنارش یه عامل مستقیم و اثبات‌شده‌ی فروشه.

اگه بخوام کل دو بخش این مقاله رو در چند جمله خلاصه کنم:

سه عدد رو بشناسید: LCP زیر ۲.۵ ثانیه، INP زیر ۲۰۰ میلی‌ثانیه، CLS زیر ۰.۱. اون‌ها رو در سرچ کنسول دنبال کنید نه در نمره‌ی تست. کارها رو به ترتیب اثر انجام بدید: اول هاست و کش، بعد تصاویر، بعد جاوااسکریپت و فونت. تغییرات رو یکی‌یکی اعمال و تست کنید. و وقتی سه معیار سبز شدن، دست نگه دارید و برید سراغ محتوا.

چون در نهایت، سریع‌ترین سایت دنیا هم اگه چیزی برای گفتن نداشته باشه، کسی سراغش نمیاد. موفق و پیروز باشید. 🙂

تیم تولید محتوا

ما در تیم تولید محتوای میهن وردپرس در تلاش هستیم تا بهترین مقالات آموزشی در زمینه وردپرس و کسب‌و‌کارهای اینترنتی را تهیه کنیم. صحت محتوای این صفحه توسط رضا راد بررسی خواهد شد.