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

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

## ۱. قبل از تغییر، وضعیت را اندازه بگیرید

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

در PageSpeed Insights دو نوع داده می‌بینید: داده میدانی که تجربه کاربران واقعی را در یک بازه زمانی نشان می‌دهد و داده آزمایشگاهی Lighthouse که صفحه را در شرایط شبیه‌سازی‌شده بررسی می‌کند. این دو همیشه یک عدد نمی‌دهند؛ داده آزمایشگاهی برای پیدا کردن ایراد مفید است و داده میدانی به فهم تجربه واقعی کمک می‌کند. اگر داده میدانی نمایش داده نشد، معنی‌اش این نیست که صفحه حتماً سریع است؛ ممکن است نمونه کافی در گزارش وجود نداشته باشد.

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

## ۲. اول سراغ بخش بزرگ و قابل‌مشاهده صفحه بروید

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

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

## ۳. درخواست‌های غیرضروری را کم کنید

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

بعد از هر حذف یا تغییر، صفحه را از نظر فرم، منو، پرداخت و رهگیری رویدادها بررسی کنید. بعضی اسکریپت‌ها برای کارکرد ضروری‌اند و حذف بی‌آزمایش می‌تواند سرعت را بهتر کند اما مسیر مشتری را خراب کند.

## ۴. کش، پاسخ سرور و فایل‌های ثابت را جداگانه بررسی کنید

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

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

## ۵. جابه‌جایی صفحه و کندی تعامل را نادیده نگیرید

برای کاهش CLS، فضای تصویر، ویدئو و بنر را از قبل مشخص کنید تا با بارگیری آن‌ها متن ناگهان پایین نرود. فونت‌ها را محدود و فایل‌های لازم را بهینه کنید؛ بارگذاری چند وزن و چند خانواده فونت می‌تواند هم انتقال داده را زیاد کند و هم ظاهر متن را دیرتر تثبیت کند.

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

## ۶. یک مثال عملی: صفحه خدمت یک کلینیک

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

## ۷. نتیجه را با یک نمره نسنجید

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

### چک‌لیست کوتاه

- صفحه‌های مهم را جداگانه و روی موبایل و دسکتاپ بسنجید.

- تفاوت داده آزمایشگاهی و داده کاربران واقعی را در نظر بگیرید.

- ابتدا تصویر و فایل‌های بزرگ بالای صفحه را بررسی کنید.

- افزونه‌ها و اسکریپت‌های بلااستفاده را حذف یا محدود کنید.

- کش را طوری تنظیم کنید که اطلاعات شخصی و سبد خرید اشتباه ذخیره نشوند.

- پس از هر تغییر، فرم‌ها، منوها و مسیر خرید یا تماس را امتحان کنید.

- تغییر، تاریخ و نتیجه را ثبت کنید تا علت بهبود یا افت مشخص باشد.

منابع: راهنمای Core Web Vitals در Google Search Central: https://developers.google.com/search/docs/appearance/core-web-vitals ؛ راهنمای داده آزمایشگاهی و میدانی PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about

نویسنده: نسل ایکس | مصطفی یوسفی، پروفایل نویسنده: https://naslx.ir/mostafa-yousefi/