چگونه وب‌سایت را سریع‌تر کنیم: چک‌لیست عملی
برای سریع‌تر کردن یک وب‌سایت، اول با PageSpeed Insights اندازه بگیرید، سپس بزرگ‌ترین علتی را که نشان می‌دهد درست کنید — معمولاً تصاویر بیش‌ازحد بزرگ، جاوااسکریپت زیاد، فونت‌های سنگین یا اسکریپت‌های شخص ثالث. هدف، معیارهای «خوب» Core Web Vitals گوگل است: محتوای اصلی ظرف ۲٫۵ ثانیه دیده شود، پاسخ به تَپ‌ها ظرف ۲۰۰ میلی‌ثانیه باشد، و تقریباً هیچ پرش چیدمانی نباشد. بیشتر سایت‌ها با چند تغییر به آنجا می‌رسند، نه با بازنویسی کامل.
پیش از تغییر، اندازه بگیرید
حدس زدن وقت را هدر می‌دهد. دو ابزار رایگان تقریباً همه چیز را پوشش می‌دهند:
- PageSpeed Insights (pagespeed.web.dev) — یک نشانی زنده را جای‌گذاری کنید. داده‌های میدانی از کاربران واقعی Chrome (اگر سایت ترافیک کافی داشته باشد) و داده‌های آزمایشگاهی از یک بارگذاری شبیه‌سازی‌شده را نشان می‌دهد، به‌همراه فهرستی از مشکلات مشخص.
- Lighthouse در DevTools کروم — همان آزمون آزمایشگاهی، روی هر صفحه‌ای که بتوانید باز کنید، از جمله پیش‌نمایش. حالت موبایل را انتخاب کنید؛ گوشی‌ها روی شبکه‌های کندتر جایی هستند که مشکلات دیده می‌شوند.
عددهایی که مهم هستند، Core Web Vitals گوگل هستند. از سپتامبر ۲۰۲۶، مستندات گوگل در web.dev این آستانه‌های «خوب» را می‌دهد، که در صدک ۷۵ بارگذاری صفحه سنجیده می‌شوند:
| معیار | چه چیزی را اندازه می‌گیرد | خوب |
|---|---|---|
| Largest Contentful Paint (LCP) | چه زودی محتوای اصلی (تصویر بزرگ یا تیتر) ظاهر می‌شود | ۲٫۵ ثانیه یا کمتر |
| Interaction to Next Paint (INP) | صفحه چه سریع به کلیک، لمس و تایپ واکنش نشان می‌دهد | ۲۰۰ میلی‌ثانیه یا کمتر |
| Cumulative Layout Shift (CLS) | چیدمان در حین بارگذاری چقدر می‌پرد | ۰٫۱ یا کمتر |
INP در سال ۲۰۲۴ جای معیار قدیمی First Input Delay را گرفت. اگر ابزاری هنوز FID گزارش می‌دهد، قدیمی است.
اعداد اولیه‌تان را یادداشت کنید. بعد از هر اصلاح دوباره آزمایش کنید تا بدانید چه کمکی کرده است.
زمان کجا می‌رود: گزینه‌ها و مبادله‌ها
هر علت رایج راه‌حلی دارد و هر راه‌حل هزینه‌ای. از بالای جدول شروع کنید — آن‌ها ارزان‌ترین و رایج‌ترین هستند.
| علت | راه‌حل معمول | مبادله |
|---|---|---|
| تصاویر بزرگ | تغییر اندازه به اندازه نمایش، فشرده‌سازی، استفاده از WebP یا AVIF | افت کمی کیفیت اگر بیش‌ازحد فشرده شود |
| ترتیب بد بارگذاری تصاویر | تنبل‌بارگذاری تصاویر زیر تاخوردگی؛ اولویت بالا برای تصویر اصلی | هیچ، اگر تصویر اصلی تنبل بارگذاری نشود |
| جاوااسکریپت زیاد | تقسیم کد برای هر مسیر، حذف کتابخانه‌های استفاده‌نشده | کمی بازسازی کد |
| رندر فقط سمت کلاینت | پیش‌رندر یا رندر سمت سرور صفحات عمومی | راه‌اندازی بیشتر ساخت یا سرور |
| فونت‌های وب | خانواده و وزن کمتر، پیش‌بارگذاری فونت اصلی، font-display: swap | تنوع تایپوگرافی کمتر |
| اسکریپت‌های شخص ثالث | حذف آنهایی که استفاده نمی‌شوند، بارگذاری بقیه بعد از صفحه | از دست دادن یک ویجت یا ردیاب |
| پاسخ کند سرور | کش، CDN، میزبانی استاتیک برای صفحات محتوا | باید به بی‌اعتبار شدن کش فکر کنید |
تصاویر
تصاویر رایج‌ترین مشکل و آسان‌ترین اصلاح هستند. یک عکس ۴۰۰۰ پیکسلی که با عرض ۸۰۰ پیکسل نمایش داده می‌شود، هر بازدیدکننده را وادار می‌کند پنج برابر آنچه می‌بیند دانلود کند.
- تصاویر را در اندازه‌ای که نمایش داده می‌شوند ارائه دهید، با
srcsetواکنش‌گرا برای گوشی و دسکتاپ. - از فرمت‌های مدرن (WebP یا AVIF) و فشرده‌سازی معقول استفاده کنید.
- برای هر تصویر
widthوheightبگذارید تا مرورگر فضا را رزرو کند. همین به تنهایی بیشتر پرش چیدمان را درست می‌کند. - تصاویر زیر تاخوردگی را با
loading="lazy"تنبل‌بارگذاری کنید. - تصویر اصلی بالای صفحه را هرگز تنبل‌بارگذاری نکنید. راهنمای LCP گوگل صریح است: تنبل‌بارگذاری تصویر LCP همیشه آن را دیر می‌کند. به‌جایش
fetchpriority="high"بدهید.
جاوااسکریپت
بسیاری از سایت‌های ساخته‌شده با هوش مصنوعی اپلیکیشن‌های تک‌صفحه‌ای (SPA) هستند: مرورگر یک بسته جاوااسکریپت را دانلود می‌کند و بعد صفحه را می‌کشد. هرچه بسته بزرگ‌تر باشد، صفحه سفید طولانی‌تر است. راه‌حل‌ها به ترتیب تلاش:
- هر چیزی را که استفاده نمی‌کنید حذف کنید. فهرست وابستگی‌ها را بخواهید و کتابخانه‌هایی را که یک‌بار اضافه شده و فراموش شده‌اند برش دهید — یک کتابخانه تاریخ برای یک تاریخ، یا یک بسته کامل آیکون برای پنج آیکون.
- بر اساس مسیر تقسیم کنید. کد داشبورد مدیریت را فقط وقتی کسی آن را باز می‌کند بارگذاری کنید، نه در صفحه اصلی.
- صفحات عمومی را پیش‌رندر کنید. یک صفحه بازاریابی که به‌صورت HTML واقعی ارسال می‌شود، پیش از اجرای هر جاوااسکریپتی ظاهر می‌شود. این برای موتورهای جستجو هم مفید است؛ سئو برای وب‌سایت‌های ساخته‌شده با هوش مصنوعی را ببینید.
INP کند معمولاً یعنی یک کار طولانی واحد صفحه را مسدود می‌کند — فیلتر کردن یک فهرست بزرگ با هر کلید، یا رندر دوباره کل یک جدول وقتی یک سلول تغییر می‌کند. پنل Performance در DevTools کروم نشان می‌دهد کدام است.
فونت‌ها
هر خانواده و وزن فونت یک فایل دیگر است. دو خانواده و سه یا چهار وزن معمولاً کافی است. فونتی را که بالای تاخوردگی استفاده می‌شود پیش‌بارگذاری کنید، از font-display: swap استفاده کنید تا متن فوراً نمایش داده شود، و اگر سرویس فونت بیرونی برای بازدیدکنندگانتان کند است، فونت‌ها را روی سرورخودتان میزبانی کنید.
اسکریپت‌های شخص ثالث
ویجت‌های چت، تحلیل‌گرها، نقشه‌های حرارتی، پیکسل‌های تبلیغاتی، ویدیوهای جاسازی‌شده و فیدهای شبکه‌های اجتماعی همه کد را از سرورهای دیگر بارگذاری می‌کنند. هرکدام کوچک به نظر می‌رسد؛ روی هم اغلب کندترین بخش صفحه‌اند. آنهایی را نگه دارید که واقعاً نگاه‌شان می‌کنید. بقیه را بعد از اینکه صفحه تعاملی شد بارگذاری کنید، و جاسازی‌های سنگین (پخش‌کننده یوتیوب، نقشه) را با یک پیش‌نمایش سبک جایگزین کنید که با کلیک، محتوای واقعی را بارگذاری کند.
پاسخ سرور
زمان تا اولین بایت (TTFB) — مدتی که سرور طول می‌کشد تا شروع به پاسخ کند — زیر همه معیارهای دیگر است. صفحات استاتیک که از یک CDN (شبکه‌ای از سرورها نزدیک به بازدیدکنندگان؛ CDN چیست را ببینید) تقریباً همه‌جا سریع‌اند. صفحاتی که سرور در هر درخواست می‌سازد به آن سرور و پایگاه داده‌اش وابسته‌اند. کش کردن کارهای تکراری و افزودن ایندکس‌های پایگاه داده برای کوئری‌های کند، راه‌حل‌های رایج هستند.
پرامپت‌هایی که جواب می‌دهند
دقیق باشید: صفحه، معیار و محدودیت را نام ببرید. اگر یافته‌های PageSpeed Insights را دارید، آن‌ها را بچسبانید.
PageSpeed Insights برای صفحه اصلی روی موبایل LCP برابر ۴٫۸ ثانیه گزارش می‌دهد، و عنصر LCP تصویر اصلی است. تصویر اصلی را تغییر اندازه بده و به WebP تبدیل کن، اندازه‌های واکنش‌گرا ارائه بده، width و height بگذار، fetchpriority="high" بده و مطمئن شو تنبل‌بارگذاری نمی‌شود. همه تصاویر زیر تاخوردگی را تنبل‌بارگذاری کن. طراحی را تغییر نده.
وابستگی‌های این اپلیکیشن را بررسی کن. هر بسته، آنچه از آن استفاده می‌کند و تقریباً چقدر به بسته اضافه می‌کند را فهرست کن. بسته‌هایی را که استفاده نمی‌شوند حذف کن و مسیرهای /admin و /settings را به بخش‌های جدا تقسیم کن که فقط وقتی بازدید می‌شوند بارگذاری شوند.
جعبه جستجو در /products کند به نظر می‌رسد. فیلتر را debounce کن، از رندر دوباره کل فهرست با هر کلید خودداری کن، و اگر فهرست بیش از ۲۰۰ مورد دارد، آن را صفحه‌بندی یا virtualize کن.
گام‌به‌گام
- صفحه زنده را آزمایش کنید در PageSpeed Insights روی موبایل. LCP، INP و CLS و سه مشکل اول فهرست‌شده را یادداشت کنید.
- اول تصاویر را درست کنید: اندازه‌ها، فرمت‌ها، ابعاد، تنبل‌بارگذاری زیر تاخوردگی، اولویت برای تصویر اصلی.
- اسکریپت‌های شخص ثالث را که استفاده نمی‌کنید حذف کنید و بقیه را به تأخیر بیندازید.
- فونت‌ها را به آنچه طراحی لازم دارد کم کنید.
- جاوااسکریپت را کوچک کنید: بسته‌های استفاده‌نشده را حذف کنید، برای هر مسیر تقسیم کنید.
- صفحات عمومی را پیش‌رندر کنید اگر هنوز سمت کلاینت رندر می‌شوند و LCP هنوز کند است.
- سرور را بررسی کنید: کش، ایندکس‌های پایگاه داده، میزبانی استاتیک برای محتوایی که به‌ندرت تغییر می‌کند.
- دوباره منتشر و دوباره آزمایش کنید. داده‌های میدانی در PageSpeed Insights طی هفته‌ها با آمدن بازدیدهای واقعی به‌روز می‌شود، پس نتایج اولیه را با داده آزمایشگاهی بسنجید.
اشتباه‌های رایج
- فقط روی لپ‌تاپ سریع آزمایش کردن. بازدیدکنندگانتان با گوشی‌های میان‌رده و اینترنت موبایل ناپایدار می‌آیند. در حالت موبایل آزمایش کنید.
- دنبال نمره ۱۰۰ کامل بودن. امتیاز آزمایشگاهی راهنماست. وقتی Core Web Vitals در محدوده خوب است، محتوا و قابلیت استفاده مهم‌تر از چند امتیاز آخر هستند.
- تنبل‌بارگذاری همه چیز، از جمله تصویر اصلی. این LCP را بدتر می‌کند.
- افزودن یک افزونه یا کتابخانه سرعت روی آن. حذف وزن تقریباً همیشه بهتر از اضافه کردن کد برای مدیریت آن است.
- بهینه‌سازی پیش‌نمایش به‌جای سایت زنده. پیش‌نمایش‌های توسعه از ساخت‌های بهینه‌نشده استفاده می‌کنند. نشانی منتشرشده را اندازه بگیرید.
- یک‌بار سرعت را درست کردن. هر ویجت، تصویر و امکان تازه وزن اضافه می‌کند. بعد از تغییرات بزرگ دوباره آزمایش کنید.
چک‌لیست سرعت
- LCP ≤ ۲٫۵ ثانیه، INP ≤ ۲۰۰ میلی‌ثانیه، CLS ≤ ۰٫۱ روی موبایل
- تصاویر تغییر اندازه، فشرده و با فرمت مدرن، با width و height
- تصویر اصلی تنبل‌بارگذاری نمی‌شود؛ تصاویر زیر تاخوردگی تنبل‌بارگذاری می‌شوند
- هیچ کتابخانه جاوااسکریپت استفاده‌نشده؛ مسیرهای سنگین جدا شده‌اند
- دو خانواده فونت یا کمتر، فونت اصلی پیش‌بارگذاری شده
- فقط اسکریپت‌های شخص ثالث که واقعاً استفاده می‌کنید، با تأخیر بارگذاری می‌شوند
- صفحات عمومی پیش‌رندر یا استاتیک، تا جایی که ممکن است
- بعد از انتشار روی نشانی زنده دوباره آزمایش شده
سرعت و چیدمان موبایل با هم پیش می‌روند؛ چگونه وب‌سایت را واکنش‌گرای موبایل کنیم را ببینید. برای بررسی کامل پیش از راه‌اندازی، چگونه نمونه اولیه هوش مصنوعی را به محصول واقعی برسانیم بقیه را پوشش می‌دهد.
سرعت در Mythex
در Mythex این تغییرات را با درخواست در چت انجام می‌دهید، یا در ویرایشگر کد روی Pro. روی نشانی منتشرشده بررسی کنید، نه در Preview، چون Preview یک سرور توسعه را اجرا می‌کند. فرانت‌اندهای استاتیک هنگام انتشار به‌صورت سایت استاتیک مستقر می‌شوند (وب‌سایت‌های استاتیک) که برای صفحات محتوا مناسب است. اپلیکیشن‌هایی که سرور دارند تا صفر مقیاس می‌شوند: وقتی بیکار باشند می‌خوابند و با بازدید بعدی بیدار می‌شوند، پس اولین درخواست بعد از یک دوره آرام کندتر است، و پایگاه داده متصل بعد از ۵ دقیقه بیکاری می‌خوابد (محدودیت‌های میزبانی). اگر یک صفحه عمومی فقط در بازدید اول کند است، علت احتمالی همین است. نگه داشتن صفحات بازاریابی به‌صورت استاتیک کمک می‌کند. بعد از تغییرات، دوباره منتشر کنید و با Hard Refresh بررسی کنید.
پرسش‌ها
زمان بارگذاری خوب یک صفحه چقدر است؟
Core Web Vitals گوگل روشن‌ترین هدف‌ها را می‌دهد: محتوای اصلی باید ظرف ۲٫۵ ثانیه (LCP) نمایش داده شود، صفحه باید به ورودی ظرف ۲۰۰ میلی‌ثانیه (INP) پاسخ دهد، و جابه‌جایی چیدمان باید ۰٫۱ یا کمتر (CLS) باشد، که در صدک ۷۵ بازدیدهای واقعی اندازه گرفته می‌شود.
سرعت سایت روی سئو اثر دارد؟
بله، کمی. گوگل از سیگنال‌های تجربه صفحه، از جمله Core Web Vitals، استفاده می‌کند، اما محتوای مرتبط خیلی مهم‌تر است. سرعت بیشتر روی بازدیدکنندگان اثر دارد، چون آن‌ها صفحات کند را قبل از خواندن هر چیزی ترک می‌کنند.
چرا امتیاز PageSpeed Insights من هر بار فرق می‌کند؟
امتیاز آزمایشگاهی از یک بارگذاری شبیه‌سازی‌شده به دست می‌آید و زمان‌بندی شبکه و سرور بین هر اجرا فرق دارد. چند بار اجرا کنید و روند را ببینید، و به بخش داده‌های میدانی بیشتر وزن دهید که از کاربران واقعی Chrome می‌آید.
بیشتر سایت‌ها را چه چیزی کند می‌کند؟
معمولاً تصاویر بیش‌ازحد بزرگ، جاوااسکریپت زیاد، فونت‌های وب و اسکریپت‌های شخص ثالث مثل ویجت‌های چت، پیکسل‌های تبلیغاتی و جاسازی‌ها. پاسخ کند سرور یا بک‌اندی که با شروع سرد کار می‌کند هم به همه این‌ها اضافه می‌کند.