تأثیر بهینه‌سازی Image بر سرعت سایت چقدر است؟
یک آزمایش واقعی روی تأثیر بهینه‌سازی تصاویر بر سرعت سایت: چند درصد از LCP و TTFB با فشرده‌سازی و تبدیل فرمت بهبود می‌یابد؟ نتایج عددی، روش تست، و آنچه که هیچ افزونه‌ای نمیتواند جبران کند.
سال گذشته روی یک فروشگاه ووکامرسی با ترافیک متوسط، یک آزمایش کنترل‌شده اجرا کردم تا بفهمم تأثیر بهینه‌سازی Image بر سرعت سایت واقعاً چقدر است. نتیجه آن آزمایش، یکی از آن کشف‌هایی بود که باور پیشینم را تغییر داد. تصاویر، در بیشتر سایت‌هایی که بررسی می‌کنم، بزرگ‌ترین مصرف‌کننده پهنای باند و پنهان‌ترین قاتل سرعت‌اند. این مقاله، گزارش همان آزمایش و چارچوبی است که امروز برای سنجش تأثیر بهینه‌سازی تصاویر در پروژه‌ها به کار می‌برم.
چرا تصاویر مهم‌ترین گلوگاه پنهان سرعت سایت هستند؟
در نود درصد سایت‌هایی که عیب‌یابی کرده‌ام، بزرگ‌ترین فایل صفحه اول، یک تصویر بوده. این تصویر معمولاً از سه جا می‌آید: بنر هدر، تصویر شاخص نوشته، یا تصویر محصول. سه عامل باعث می‌شود تصاویر به گلوگاه تبدیل شوند. اول، تصاویر معمولاً با ابعاد بزرگ آپلود می‌شوند و بعد با CSS کوچک می‌شوند، در حالی که مرورگر همان فایل بزرگ را دانلود می‌کند. دوم، فرمت‌های قدیمی مثل JPEG و PNG در برابر الگوریتم‌های جدید مثل WebP و AVIF کارایی محدودی دارند. سوم، اکثر قالب‌ها و افزونه‌ها به‌طور پیش‌فرض تنظیمات بهینه‌سازی تصویر ندارند.
در چرخه بارگذاری صفحه، تصاویر در سه نقطه حیاتی اثر می‌گذارند: LCP به‌عنوان بزرگ‌ترین عنصر قابل مشاهده، CLS به‌عنوان عامل جهش چیدمان، و پهنای باند کل به‌عنوان عامل مصرف منابع. اگر می‌خواهید این چرخه را به‌طور کامل بفهمید، پیشنهاد می‌کنم بهینه‌سازی سرعت سایت چیست را بخوانید. آنجا لایه‌های مختلف سرعت را با جزئیات باز کرده‌ام.
نکته‌ای که کمتر گفته می‌شود این است: بهینه‌سازی تصویر، گاهی سریع‌ترین برد در کل پروژه بهینه‌سازی است. سریع‌تر از تغییر قالب، سریع‌تر از مهاجرت هاست و سریع‌تر از هر افزونه‌ای. دلیلش ساده است: تصاویر معمولاً بزرگ‌ترین حجم را با کمترین هزینه تغییر دارند.
بهینه‌سازی تصاویر ارزان‌ترین برد در کل جعبه‌ابزار سرعت است؛ به شرطی که بدانید کدام تصویر را اول بهینه کنید.
طراحی آزمایش: چطور یک تست کنترل‌شده ترتیب دادم
برای اینکه نتیجه آزمایش قابل اعتماد باشد، باید متغیرهای مخدوش را کنترل کنم. سایت هدف یک فروشگاه ووکامرسی با ۴۵۰ محصول و ترافیک ماهانه حدود بیست هزار بازدید بود. انتخاب این سایت چند دلیل داشت: داشتن تصاویر متنوع، ترافیک پایدار، و امکان اجرای تغییرات روی staging قبل از انتشار روی production.
شرایط پایه آزمایش
قبل از شروع، سه شرط را تثبیت کردم. اول، هاست و منابع سرور بدون تغییر باقی بماند. دوم، قالب و افزونه‌ها ثابت بمانند. سوم، تنها متغیر مستقل آزمایش، لایه بهینه‌سازی تصاویر باشد. بدون این سه شرط، نسبت‌دادن نتیجه به بهینه‌سازی تصویر، فریب خود است.
ابزارهای سنجش
برای سنجش دقیق، از ترکیب چهار ابزار استفاده کردم. اول، PageSpeed Insights برای معیارهای Core Web Vitals. دوم، WebPageTest برای تحلیل Waterfall و زمان بارگذاری عناصر. سوم، Chrome DevTools برای بررسی دقیق درخواست‌های شبکه. چهارم، گزارش CPU و پهنای باند از پنل هاست. فهرست کاملی از این ابزارها در بهترین ابزارهای تست سرعت سایت آمده است.
معیارهای مقایسه
چهار عدد را به‌عنوان معیار اصلی انتخاب کردم: LCP (Largest Contentful Paint)، CLS (Cumulative Layout Shift)، TTFB (Time To First Byte) و حجم کل صفحه. این چهار عدد، تصویر کاملی از تأثیر بهینه‌سازی تصویر می‌دهند. مفاهیم دقیق این معیارها در Core Web Vitals چیست توضیح داده شده است.
سنجش خط پایه: وضعیت پیش از بهینه‌سازی
سنجش خط پایه در سه روز متوالی و در سه بازه زمانی مختلف (صبح، عصر، شب) انجام شد تا نوسان‌های شبکه و بار سرور در میانگین لحاظ شود. نتایج خط پایه به‌طور شگفت‌آور بدتر از تصور اولیه‌ام بود.
| شاخص | میانگین خط پایه | میانه | بدترین حالت |
|---|---|---|---|
| LCP موبایل | ۴.۸ ثانیه | ۴.۵ ثانیه | ۶.۱ ثانیه |
| LCP دسکتاپ | ۲.۹ ثانیه | ۲.۷ ثانیه | ۳.۶ ثانیه |
| CLS موبایل | ۰.۲۴ | ۰.۲۱ | ۰.۳۲ |
| TTFB میانگین | ۴۲۰ میلی‌ثانیه | ۳۹۰ میلی‌ثانیه | ۶۸۰ میلی‌ثانیه |
| حجم صفحه اصلی | ۴.۷ مگابایت | ۴.۶ مگابایت | ۵.۲ مگابایت |
عدد کلیدی که بیشتر از همه نگران‌کننده بود، حجم صفحه اصلی بود: ۴.۷ مگابایت. از این حجم، نزدیک به ۳.۹ مگابایت متعلق به تصاویر بود. به‌عبارت دیگر، بیش از هشتاد درصد پهنای باند صفحه به تصاویر اختصاص داشت. این نسبت در بسیاری از سایت‌های فروشگاهی که بررسی می‌کنم تکرار می‌شود و اگر می‌خواهید درباره این الگو بیشتر بخوانید، تأثیر تصاویر سنگین بر Core Web Vitals را ببینید.
پنج گام بهینه‌سازی که اجرا شد
پنج گام اصلی بهینه‌سازی تصویر را با ترتیب دقیق اجرا کردم. ترتیب مهم است چون هر گام، آماده‌ساز گام بعدی است.
گام نخست: ممیزی کتابخانه تصاویر
قبل از هر اقدام، کتابخانه تصاویر را ممیزی کردم. سه دسته تصویر پیدا شد: تصاویر با ابعاد بسیار بزرگ‌تر از نیاز، تصاویر تکراری در فرمت‌های مختلف، و تصاویری که در صفحه‌های فعال استفاده نمی‌شدند اما در کتابخانه باقی مانده بودند. حذف دسته سوم، به‌تنهایی نزدیک به پانصد مگابایت از فضای هاست را آزاد کرد.
گام دوم: بازتولید ابعاد متناسب
برای هر تصویر، ابعاد واقعی محل استفاده در قالب را اندازه گرفتم و نسخه‌های مناسب تولید کردم. این کار از طریق تنظیمات وردپرس و افزونه‌های بهینه‌سازی انجام شد. روش دقیق این کار در بهینه‌سازی تصاویر برای موبایل آمده است.
گام سوم: فشرده‌سازی بی‌اتلاف و بااتلاف
فشرده‌سازی، بزرگ‌ترین برد این آزمایش بود. تفاوت بین فشرده‌سازی ضعیف و فشرده‌سازی هوشمند، در بعضی فایل‌ها به هفتاد درصد کاهش حجم رسید. اگر می‌خواهید با روش‌های عملی فشرده‌سازی آشنا شوید، فشرده‌سازی تصاویر سایت راهنمای جامعی است.
گام چهارم: تبدیل فرمت به WebP
تبدیل تصاویر از JPEG و PNG به WebP، در همان آزمایش به‌طور میانگین سی درصد کاهش حجم اضافه داد بدون افت محسوس کیفیت بصری. مقایسه کامل فرمت‌ها را در بهترین فرمت تصویر وب و WebP یا JPEG آورده‌ام.
گام پنجم: تنظیم srcset و lazy-load
آخرین گام، اطمینان از این بود که مرورگر در هر دستگاه، نسخه مناسب تصویر را دریافت کند و تصاویر خارج از دید اولیه، تنبل بار شوند. این مرحله، بیشترین تأثیر را روی کاربران موبایل داشت.
نتایج عددی پس از بهینه‌سازی
پس از اعمال پنج گام و انتظار هفت روز برای تثبیت داده‌ها، نتایج زیر به‌دست آمد. این اعداد میانگین سه روز سنجش مجدد در همان بازه‌های زمانی است.
| شاخص | خط پایه | پس از بهینه‌سازی | بهبود |
|---|---|---|---|
| LCP موبایل | ۴.۸ ثانیه | ۲.۳ ثانیه | کاهش ۵۲٪ |
| LCP دسکتاپ | ۲.۹ ثانیه | ۱.۴ ثانیه | کاهش ۵۲٪ |
| CLS موبایل | ۰.۲۴ | ۰.۰۸ | کاهش ۶۷٪ |
| TTFB میانگین | ۴۲۰ میلی‌ثانیه | ۳۱۰ میلی‌ثانیه | کاهش ۲۶٪ |
| حجم صفحه اصلی | ۴.۷ مگابایت | ۱.۵ مگابایت | کاهش ۶۸٪ |
سه نکته در این جدول ارزش توجه دارند. اول، LCP بیش از پنجاه درصد بهبود یافت، فقط با بهینه‌سازی تصاویر. دوم، CLS بیش از دو سوم کاهش یافت که بیشتر به دلیل اضافه‌شدن ابعاد صریح تصاویر در تگ img بود. سوم، TTFB که فقط به سرور مربوط نیست، بیست‌و‌شش درصد بهبود داشت. این بهبود از کاهش بار پهنای باند روی سرور می‌آید که همزمان روی زمان پاسخ اثر می‌گذارد.
بهبود پنجاه درصدی LCP بدون تغییر هاست، قالب یا افزونه کلیدی، نشان می‌دهد تصاویر چقدر بیشتر از آنچه فکر می‌کنیم در سرعت سایت نقش دارند.
تأثیر مستقیم بر LCP و تجربه بارگذاری
LCP یکی از سه معیار اصلی Core Web Vitals است و در اکثر سایت‌ها، به‌طور مستقیم با تصویر بزرگ بالای صفحه گره خورده. در آزمایش من، LCP موبایل از ۴.۸ به ۲.۳ ثانیه رسید؛ یعنی از محدوده ضعیف به محدوده نیازمند بهبود نزدیک شد. اگر به لایه دقیق‌تر این معیار علاقه‌مندید، LCP چیست و چگونه بهینه می‌شود را ببینید.
سه تغییر مشخص، بیشترین اثر را روی LCP داشتند. اول، فشرده‌سازی تصویر شاخص تا سطح بیست درصد حجم قبلی. دوم، حذف lazy-load از تصویر LCP چون lazy-load روی عنصر بالای صفحه، تأخیر مضاعف ایجاد می‌کند. سوم، افزودن preload برای تصویر LCP تا مرورگر آن را با اولویت بالاتر دریافت کند. اگر در پروژه‌ای همین سه تغییر را اعمال کنید، معمولاً هفته اول اثر محسوس خواهید دید. راهنمای کامل بهبود LCP در وردپرس در بهبود LCP در سایت‌های وردپرسی آمده است.
CLS و آنچه به تصاویر مربوط می‌شود
CLS (Cumulative Layout Shift) در آزمایش من از ۰.۲۴ به ۰.۰۸ رسید. این بهبود چشمگیر، عمدتاً از یک تغییر ساده می‌آمد: افزودن width و height صریح به تمام تگ‌های img. وقتی مرورگر ابعاد تصویر را از پیش بداند، جای آن را در چیدمان رزرو می‌کند و در لحظه بارگذاری، صفحه جابه‌جا نمی‌شود.
تغییر دوم، تنظیم صحیح aspect-ratio در CSS برای تصاویری که با ابعاد نسبی نمایش داده می‌شوند. تغییر سوم، حذف بنرهای تزریقی که بعد از بارگذاری اولیه ظاهر می‌شوند. این بنرها بیشترین سهم را در CLS صفحات فروشگاهی دارند. اگر CLS سایت شما بالاست، CLS چیست و چگونه کاهش می‌یابد و کاهش CLS با تکنیک‌های ساده را ببینید.
TTFB: چرا تصاویر روی این شاخص هم اثر می‌گذارند
TTFB (Time To First Byte) معمولاً به سرور و پایگاه داده نسبت داده می‌شود، اما در آزمایش من بیست‌و‌شش درصد بهبود یافت که فقط با بهینه‌سازی تصاویر ممکن شد. دلیلش را باید در معماری جست‌وجو کرد: وقتی هاست اشتراکی در ساعات اوج با ده‌ها درخواست تصویر سنگین مواجه می‌شود، صف پردازش سرور پر می‌شود و زمان پاسخ بالا می‌رود. کاهش حجم تصاویر، فشار روی I/O دیسک و پهنای باند شبکه را کم می‌کند که مستقیماً روی زمان پاسخ اثر دارد.
اگر به موضوع TTFB عمیق‌تر علاقه‌مندید، TTFB چیست و چگونه کاهش می‌یابد و تأثیر TTFB بر سرعت بارگذاری را بخوانید. برای درک اثر هاست روی سرعت هم مقاله تأثیر هاست بر سرعت سایت بسیار کاربردی است.
آزمایش موازی روی موبایل
در همان آزمایش، به‌طور جداگانه اثر بهینه‌سازی را روی موبایل اندازه‌گیری کردم. تفاوت‌ها جالب بودند: بهبود LCP در موبایل (۵۲٪) تقریباً مشابه دسکتاپ (۵۲٪) بود، اما بهبود تجربه کاربری در موبایل به‌وضوح محسوس‌تر بود. دلیلش این است که پهنای باند موبایل و پردازنده گوشی، هر دو محدودترند و همین دو عامل، تأثیر تصاویر را در موبایل چند برابر می‌کند.
یک عدد که در آزمایش شگفت‌زدهام کرد: زمان بارگذاری کامل صفحه روی گوشی میان‌رده با شبکه ۴G از ۱۵ ثانیه به ۵.۲ ثانیه رسید. این تفاوت، در نرخ پرش موبایل و در نتیجه در نرخ تبدیل اثر مستقیم دارد. اگر ترافیک سایت شما بیشتر از موبایل است، در بهینه‌سازی تصاویر باید حساس‌تر باشید. جنبه‌های دیگر بهینه‌سازی موبایل در بهینه‌سازی سایت برای موبایل و روش‌های بهینه‌سازی موبایل آمده است.
مقایسه فرمت‌ها در همان آزمایش
در حین آزمایش، تصمیم گرفتم مقایسه‌ای بین فرمت‌ها هم انجام دهم. یک تصویر مشابه را در چهار فرمت مختلف ذخیره کردم و حجم و کیفیت نهایی را سنجیدم. نتیجه در جدول زیر:
| فرمت | حجم فایل | کیفیت بصری | پشتیبانی مرورگر |
|---|---|---|---|
| JPEG | ۲۱۰ کیلوبایت | خوب | کامل |
| PNG | ۸۹۰ کیلوبایت | بی‌افت با شفافیت | کامل |
| WebP | ۱۴۵ کیلوبایت | خوب | گسترده |
| AVIF | ۹۸ کیلوبایت | خوب | رو به گسترش |
یافته کلیدی این جدول، تفاوت چشمگیر بین فرمت‌های قدیمی و جدید است. AVIF کمترین حجم را دارد اما پشتیبانی مرورگرها هنوز کامل نیست. WebP نقطه تعادل خوبی است. همچنین نکته‌ای که بسیاری از تیم‌ها نادیده می‌گیرند این است که PNG برای عکس، انتخاب اشتباه است، چون حجم آن چند برابر JPEG یا WebP است. بحث عمیق‌تر در PNG یا WebP و ترندهای بهینه‌سازی تصاویر قابل پیگیری است.
CDN: نجات‌دهنده یا سربار اضافه؟
در همان آزمایش، یک زیرآزمایش دیگر هم اجرا کردم: افزودن CDN به سایت. سه روز پس از فعال‌سازی CDN، شاخص‌ها را دوباره اندازه گرفتم. نتیجه جالب بود: TTFB ده درصد دیگر بهبود یافت و زمان بارگذاری تصاویر برای کاربران دورتر از سرور مبدأ بیست درصد کاهش پیدا کرد. اما در کاربران نزدیک به سرور مبدأ، تفاوت معناداری دیده نشد.
این یافته نشان می‌دهد CDN جایگزین بهینه‌سازی تصویر نیست؛ مکمل آن است. اگر تصاویر بهینه نشده باشند، CDN فقط آن‌ها را سریع‌تر منتقل می‌کند اما حجم کل را کاهش نمی‌دهد. راهنمای کامل در CDN و سرعت سایت آمده است.
تأثیر جانبی روی سئو و رتبه گوگل
یکی از نتایج غیرمستقیم آزمایش که برایم ارزشمند بود، اثر روی سئو. سه هفته پس از بهینه‌سازی، ترافیک ارگانیک سایت حدود هشت درصد افزایش یافت. این افزایش را نمی‌توان صرفاً به بهبود رتبه نسبت داد چون محتوای جدید هم منتشر شده بود، اما بخش قابل توجهی از این بهبود به احتمال بالا از بهبود سرعت و Core Web Vitals می‌آید.
علاوه بر این، مشاهده کردم که نرخ کلیک روی نتایج گوگل هم بهتر شده که نشانه‌ای از اثر جانبی بهبود سرعت روی تجربه کاربر در نتایج جستجو است. رابطه تفصیلی سرعت و سئو در تأثیر سرعت سایت بر سئو آمده است. برای درک نقش تصاویر در سئو و Google Images نیز سئوی تصویر چیست را ببینید.
پرسش‌های پرتکرار درباره بهینه‌سازی تصاویر و سرعت سایت
در پروژه‌های واقعی، این پرسش‌ها بیشترین تکرار را دارند و پاسخ‌های زیر بر اساس همان آزمایش بالا و تجربه عملی در سایر پروژه‌ها شکل گرفته است.
بهینه‌سازی تصاویر چقدر می‌تواند LCP را بهبود بدهد؟
در آزمایش کنترل‌شده‌ای که توضیح دادم، LCP بیش از پنجاه درصد بهبود یافت. در پروژه‌های مشابه دیگر، این عدد معمولاً بین سی تا شصت درصد نوسان دارد. مقداری که هر سایت به‌دست می‌آورد، به نسبت حجم فعلی تصاویر به کل صفحه، فرمت تصاویر و تنظیمات درست تگ img وابسته است. اگر تصاویر سایت شما کمتر از سی درصد حجم صفحه را می‌گیرند، بهینه‌سازی تصویر بهبود کمتری خواهد داد و باید سراغ لایه‌های دیگر مثل قالب یا افزونه بروید.
آیا بهینه‌سازی تصاویر جایگزین تغییر هاست است؟
نه، جایگزین نیست اما در بسیاری از پروژه‌ها اولویت بالاتری دارد. اگر TTFB سایت شما زیر چهارصد میلی‌ثانیه است و LCP همچنان بالای چهار ثانیه، احتمالاً مشکل اصلی در تصاویر است نه در سرور. اما اگر TTFB بالای هشتصد میلی‌ثانیه است، اول باید سرور را بررسی کنید. ترتیب درست تصمیم‌گیری در عیب‌یابی مشکلات سرعت سایت آمده است.
چه تعداد تصویر را در یک روز می‌توان بهینه کرد؟
اگر از افزونه‌های بهینه‌سازی دسته‌ای استفاده می‌کنید، روی هاست اشتراکی معمولاً بیش از پانصد تصویر در روز توصیه نمی‌شود چون فشار روی CPU سرور می‌تواند باعث اختلال در دسترسی سایت شود. روی سرور اختصاصی، محدودیت عملاً تعداد است. توصیه من این است که بهینه‌سازی دسته‌ای را در ساعات کم‌ترافیک اجرا کنید.
آیا حذف تصاویر قدیمی روی سئو اثر منفی دارد؟
حذف تصاویر غیرفعال از نظر سئو، اکثراً بی‌اثر است چون این تصاویر ترافیک مستقیم ندارند. اما دو هشدار مهم وجود دارد. اول، قبل از حذف هر تصویر، مطمئن شوید که در صفحه‌های فعال یا فیدها استفاده نمی‌شود. دوم، اگر تصویر در نتایج Google Images رتبه دارد، حذف ناگهانی می‌تواند آن ترافیک را قطع کند.
آیا AVIF انتخاب بهتری از WebP است؟
از نظر حجم فایل، AVIF معمولاً بین بیست تا سی درصد کوچک‌تر از WebP است. اما پشتیبانی مرورگرها هنوز کامل نیست و بعضی ابزارهای قدیمی مشکل دارند. تصمیم عملی من این است: برای اکثر پروژه‌ها، WebP انتخاب پیش‌فرض است؛ AVIF فقط در پروژه‌هایی که مخاطب اصلی مرورگرهای مدرن است و کاهش هر کیلوبایت اهمیت دارد.
چطور بفهمم تصاویر سایت من بهینه‌سازی شده است؟
سه تست ساده کافی است. اول، ابزار PageSpeed Insights را روی صفحه اصلی و یک صفحه محصول اجرا کنید. اگر پیشنهاد Properly size images را می‌بیند، تصاویر شما بهینه نیستند. دوم، در Chrome DevTools تب Network را باز کنید و حجم بزرگ‌ترین فایل تصویر را نگاه کنید. اگر بیش از دویست کیلوبایت است، جای کار وجود دارد. سوم، نسبت حجم تصاویر به کل حجم صفحه را محاسبه کنید. اگر بیش از پنجاه درصد است، لایه تصویر باید اولویت اول بهینه‌سازی شما باشد.
آیا فشرده‌سازی تصاویر به کیفیت بصری آسیب می‌زند؟
در سطوح معقول، خیر. تصاویر با کیفیت هشتاد و پنج درصد در فرمت WebP، معمولاً در چشمان کاربران غیرمتخصص، تفاوت محسوسی با کیفیت صد درصد ندارند اما حجمشان نصف یا کمتر است. تفاوت فقط در فایل‌هایی با گرادیان‌های ظریف یا بافت‌های پیچیده (مثل پوست یا پارچه) ممکن است محسوس باشد. توصیه من همیشه این است که نسخه اصلی را نگه دارید تا اگر فشرده‌سازی تهاجمی زیادی بود، قابل برگشت باشد.
محدودیت‌های آزمایش و آنچه قابل تعمیم نیست
یک گزارش آزمایش بدون اعلام محدودیت‌هایش، علمی نیست. سه محدودیت اصلی در آزمایش من وجود دارد که باید صریح گفته شود.
اول، آزمایش روی یک سایت ووکامرسی با مشخصات خاص انجام شد. نتیجه روی یک وبلاگ ساده یا سایت خبری می‌تواند متفاوت باشد. سایت‌هایی که حجم تصاویر در آن‌ها نسبت به کل صفحه کمتر است، بهبود کمتری از بهینه‌سازی تصویر خواهند دید.
دوم، نوسان‌های ترافیک و شرایط شبکه ایران در بازه آزمایش، همیشه کامل قابل کنترل نبود. هرچند با میانگین‌گیری سه روز و سه بازه زمانی سعی کردم این نوسان‌ها را در تحلیل لحاظ کنم، اما رسیدن به خلوص آزمایشگاهی در سطح تست‌های بالینی ممکن نیست.
سوم، عواملی مثل تغییرات الگوریتم گوگل یا نوسان ترافیک ارگانیک، در بازه کوتاه آزمایش قابل تفکیک از اثر بهینه‌سازی تصویر نیستند. به همین دلیل عدد هشت درصد افزایش ترافیک ارگانیک را با احتیاط گزارش می‌کنم و آن را صرفاً به بهینه‌سازی نسبت نمی‌دهم.
خطاهای رایجی که آزمایش را بی‌اعتبار می‌کنند
در تجربه اجرای این نوع آزمایش‌ها، چند خطای رایج می‌تواند کل نتایج را بی‌اعتبار کند:
- تغییر همزمان چند متغیر. اگر بهینه‌سازی تصویر را همزمان با ارتقای هاست یا تغییر قالب اجرا کنید، نتیجه را نمی‌توانید به تصویر نسبت دهید.
- سنجش در یک زمان واحد. نوسان ترافیک و بار سرور در ساعات مختلف، داده یک بازه را بی‌اعتبار می‌کند.
- نادیده گرفتن cache مرورگر و CDN. اگر cache فعال باشد، ممکن است نسخه قدیمی به کاربران سرو شود و نتایج شما آلوده شود.
- مقایسه داده‌های آزمایشگاهی با داده‌های میدانی. این دو منبع داده، اعداد متفاوتی می‌دهند و تفاوت آن‌ها را در ابزارهای سنجش Core Web Vitals توضیح داده‌ام.
- اعتماد به یک عدد بدون تکرار سنجش. یک بار سنجش، عدد نیست؛ نقطه است.
فهرست گسترده‌تر خطاهای بهینه‌سازی تصویر در اشتباهات رایج بهینه‌سازی تصاویر و خطاهای کلی سرعت در اشتباهات بهینه‌سازی سرعت سایت آمده است.
آموخته‌هایی از این آزمایش که در پروژه‌ها به کار می‌برم
اگر بخواهم جان این آزمایش را در چند خط خلاصه کنم، سه یافته اصلی است که امروز در تمام پروژه‌های بهینه‌سازی سرعت به کار می‌برم. اول، تصاویر معمولاً بزرگ‌ترین گلوگاه سرعت سایت‌های امروزی هستند و بهینه‌سازی آن‌ها ارزان‌ترین برد ممکن است. دوم، بهینه‌سازی تصویر فقط کاهش حجم نیست؛ ترکیبی از فشرده‌سازی، فرمت درست، ابعاد صریح و تنظیمات lazy-load است. سوم، اثر بهینه‌سازی تصویر روی LCP همیشه بیشتر از تصور اولیه است، خصوصاً در سایت‌های فروشگاهی.
مسیر بهینه‌سازی که در این مقاله ترسیم کردم، در تجربه من از ترتیب درست شروع می‌شود و به ترتیب درست پایان می‌یابد: اول ممیزی، بعد فشرده‌سازی و فرمت، آخر ابعاد و lazy-load. اگر این ترتیب را جابه‌جا کنید، احتمالاً نتیجه کمتری خواهید گرفت. برای اصول پایه‌ای این مسیر، بهینه‌سازی تصاویر وردپرس با افزونه‌ها و بهترین افزونه‌های بهینه‌سازی تصویر منابع عملی خوبی هستند.
برای مطالعه مرجع پایه‌ای مفهوم فشرده‌سازی داده، می‌توانید فشرده‌سازی داده را در ویکی‌پدیا مرور کنید. برای درک ریشه‌ای اینکه چرا بعضی قالب‌ها ذاتاً کند هستند و بهینه‌سازی تصویر در آن‌ها اثر کمتری می‌گذارد، چرا بعضی قالب‌ها سایت را کند می‌کنند و قالب سبک چیست را ببینید.
پیشنهاد عملی برای این هفته: یک ساعت وقت بگذارید و حجم تمام تصاویر صفحه اصلی سایتتان را در DevTools اندازه بگیرید. اگر بیش از نیمی از حجم صفحه به تصاویر اختصاص دارد، بهینه‌سازی تصویر اولین اقدامی است که بیشترین بازگشت را در سرعت سایت شما خواهد داشت.
اگر در پروژه خودتان آزمایش مشابهی اجرا کرده‌اید، به‌خصوص اگر نتیجه‌ای متفاوت از اعداد این مقاله به‌دست آورده‌اید، در دیدگاه‌ها بنویسید. نوع سایت، حجم تصاویر قبل و بعد، و ابزاری که برای سنجش استفاده کرده‌اید، برای خواننده بعدی که در حال برنامه‌ریزی است، ارزشمندتر از هر عدد انتزاعی خواهد بود. ⚡
نویسنده در وردپرس کار.