تصویر بالای صفحهتان محو است و LCP از ۴ ثانیه گذشته
سایت را باز میکنید، بالای صفحه خالی است، بعد تصویر هدر آرامآرام ظاهر میشود. در PageSpeed Insights هم Lighthouse میگوید «Largest Contentful Paint» از حد مجاز گذشته. مقصر را پیدا کردهاید: attribute ای به نام loading="lazy" که یک ماه پیش با خوشحالی به همهی تصاویر اضافه کردید. این دقیقاً همان جایی است که lazy loading از یک ابزار بهینهسازی به یک ضدالگو تبدیل میشود.
بیایید یک بار برای همیشه تکلیف را روشن کنیم. lazy loading یعنی مرورگر تا وقتی کاربر به عنصر نزدیک نشده، آن را دانلود نکند. ایدهاش درست است: صفحههای بلند پر از تصویر، بدون آن، مگابایتها داده بیهوده منتقل میکنند. اما اجرای نادرستش، معیار اصلی گوگل برای تجربه کاربری را نابود میکند. این مقاله فقط درباره «چطور» نیست؛ درباره «کجا» و «کجا نه» است.
lazy loading کجا واقعاً کمک میکند
فرض کنید صفحه محصولی دارید با ۴۰ تصویر گالری، یا یک بلاگ با ۱۵ عکس در یک نوشته بلند. کاربر برای دیدن عکس دهم، باید اسکرول کند. اگر همه تصاویر از ابتدا دانلود شوند، پهنای باند هدر رفته و زمان بارگذاری کامل صفحه بالا میرود. اینجا lazy loading معجزه میکند: مرورگر فقط تصاویر نزدیک به viewport را میگیرد و بقیه را برای لحظه نیاز نگه میدارد.
نتیجه عملی را با یک تست ساده ببینید. صفحهای با ۲۰ تصویر ۲۰۰ کیلوبایتی را در نظر بگیرید. بدون lazy loading، مرورگر حدود ۴ مگابایت دانلود میکند. با آن، شاید فقط ۲ مگابایت تا لحظه اسکرول کامل. این یعنی TTFB و سرعت ادراکی بهتر، و برای کاربران موبایل با اینترنت محدود، یک تفاوت واقعی است.
اما این فقط نیمی از ماجراست. lazy loading درست، فقط به تصاویر پایین صفحه محدود نمیشود. اگر iframe ویدیوی یوتیوب یا نقشه گوگل هم در پایین صفحه دارید، همان منطق را اعمال کنید. این عناصر سنگینترین بخش یک صفحهاند و تا وقتی کاربر به آنها نرسیده، دلیلی برای دانلودشان وجود ندارد.
نحوه پیادهسازی درست
سادهترین راه، attribute بومی HTML است. یک خط کد، بدون هیچ کتابخانهای:
<img src="product-1.jpg" alt="محصول شماره ۱" loading="lazy" width="800" height="600">دقت کنید width و height را حتماً بدهید. بدون این دو، مرورگر فضای تصویر را نمیداند و هنگام اسکرول، صفحه میپرد. این پرش، CLS (Cumulative Layout Shift) را بالا میبرد و معیار دوم Core Web Vitals را خراب میکند. اگر تصویر واکنشگراست، از srcset با همان attribute استفاده کنید:
<img src="small.jpg" srcset="small.jpg 400w, large.jpg 1200w" sizes="(max-width: 600px) 400px, 1200px" loading="lazy" width="1200" height="800" alt="توضیح">برای مرورگرهای قدیمیتر که loading="lazy" را نمیشناسند (سافاری قبل از ۱۵.۴)، از کتابخانههایی مثل lazysizes استفاده کنید. اما اول بپرسید: آیا مخاطب شما واقعاً از این مرورگرها استفاده میکند؟ آمار گوگل آنالیتیکس را چک کنید. اگر سهم سافاری قدیمی زیر ۲٪ است، کتابخانه اضافه نکنید؛ یک اسکریپت ۳۰ کیلوبایتی، خودش بخشی از مشکل است.
جایی که lazy loading LCP را خراب میکند
LCP یعنی بزرگترین عنصر محتوایی که در viewport اولیه دیده میشود. معمولاً این عنصر، تصویر هدر، اسلایدر اصلی یا تیتر بزرگ است. اگر به این تصویر loading="lazy" بدهید، مرورگر دانلودش را به تأخیر میاندازد. نتیجه؟ کاربر یک صفحه خالی یا نیمهخالی میبیند و LCP شما از ۲.۵ ثانیه به ۴ یا ۵ ثانیه میرود.
اینجا اشتباه میکنند: خیلیها فکر میکنند «همه تصاویر را lazy کنم، سایت سریعتر میشود». نتیجه را در PageSpeed Insights میبینید: یک هشدار قرمز که میگوید تصویر LCP با تأخیر بارگذاری شده. این خطا آنقدر رایج است که گوگل یک audit اختصاصی برایش دارد: «Largest Contentful Paint image was lazily loaded».
قانون طلایی: هر عنصری که در ۱۰۰۰ پیکسل اول صفحه (یا بهتر بگوییم، در viewport اولیه) دیده میشود، هرگز lazy نشود. این شامل لوگو، تصویر هدر، و اسلایدر اصلی است. برای اینها از fetchpriority="high" استفاده کنید تا به مرورگر بگویید این عنصر حیاتی است:
<img src="hero.jpg" alt="بنر اصلی" fetchpriority="high" width="1920" height="1080">توجه کنید که این attribute را با lazy ترکیب نکنید. این دو با هم تناقض دارند و مرورگر ممکن است رفتاری غیرقابل پیشبینی نشان دهد. یا یکی، یا دیگری.
چطور بفهمیم کدام تصویر LCP است
ابزارهای رایگان گوگل را فراموش نکنید. در Chrome DevTools، تب Performance را باز کنید، یک بار ضبط کنید و به بخش Timings نگاه کنید. عنصر LCP با یک برچسب آبی مشخص شده. در PageSpeed Insights هم گزارش دقیق میگیرید. اگر نمیخواهید وارد این جزئیات شوید، یک قانون سرانگشتی ساده دارم: هر تصویری که بدون اسکرول دیده میشود، LCP است یا نزدیک به آن. پس lazy نکنید.
برای بررسی دقیقتر فنی، میتوانید از ابزارهای آنلاین بررسی DNS و هدرهای HTTP استفاده کنید تا مطمئن شوید سرور پاسخدهی درستی دارد. تأخیر در DNS یا TTFB بالا، حتی با lazy loading درست، LCP را خراب میکند. این دو مشکل را جدا از هم ببینید: lazy loading فقط دانلود مرورگر را به تأخیر میاندازد، اما اگر خود سرور کند باشد، هیچ ترفند سمت کلاینت کمکی نمیکند.
تصاویر پسزمینه CSS را فراموش نکنید
یک سناریوی رایج دیگر: تصاویر پسزمینه که با background-image در CSS تعریف شدهاند. attribute بومی loading="lazy" روی آنها کار نمیکند. این تصاویر خارج از HTML هستند و مرورگر آنها را مثل یک asset عادی میبیند. نتیجه؟ اگر یک تصویر پسزمینه سنگین در بالای صفحه دارید، بدون هیچ کنترلی دانلود میشود و LCP را خراب میکند.
راهحل چیست؟ دو گزینه دارید. اول، اگر تصویر پسزمینه فقط تزئینی است، آن را با یک گرادیان CSS یا رنگ ساده جایگزین کنید. دوم، اگر واقعاً لازمش دارید، از تکنیک content-visibility: auto استفاده کنید:
.lazy-bg {
content-visibility: auto;
contain-intrinsic-size: 0 500px;
}این ویژگی به مرورگر میگوید رندر این بخش را تا وقتی در viewport نیست به تأخیر بیندازد. اما توجه کنید: این برای رندر است، نه دانلود. مرورگر ممکن است همچنان تصویر را دانلود کند، فقط رندر را عقب میاندازد. برای کنترل واقعی دانلود، باید از Intersection Observer استفاده کنید و کلاس را بهصورت شرطی اضافه کنید. این پیچیدهتر است، اما تنها راه درست برای تصاویر پسزمینه است.
lazy loading و سئو؛ رابطهای که بد فهمیده شده
گوگل اعلام کرده که lazy loading را میفهمد و محتوای تنبلشده را ایندکس میکند. خزندههای گوگل صفحه را با viewport بزرگتری میبینند و عناصر lazy شده را هم بررسی میکنند. پس نگران نباشید که تصاویر پایین صفحه از ایندکس خارج شوند. اما یک شرط وجود دارد: اگر از جاوااسکریپت برای lazy loading استفاده میکنید، مطمئن شوید محتوا بدون JS هم در دسترس است. اگر تصویر فقط با JS بارگذاری شود و گوگلبات نتواند اسکریپت را اجرا کند، آن تصویر برای سئو گم میشود.
نکته مهم دیگر: lazy loading جایگزین فشردهسازی تصویر نیست. اگر تصویری ۵ مگابایتی را lazy کنید، فقط دانلودش را عقب انداختهاید؛ وقتی کاربر به آن برسد، همان ۵ مگابایت را میگیرد. فرمت WebP یا AVIF، فشردهسازی با ابزارهایی مثل Squoosh، و ابعاد درست، همیشه اولویت اول هستند. lazy loading فقط لایه آخر بهینهسازی است، نه کل ماجرا.
اگر میخواهید تصویر بهینهشده را با lazy loading ترکیب کنید، ترتیب کار را درست کنید: اول فشردهسازی، بعد ابعاد درست، بعد lazy loading. این ترتیب را عوض نکنید. خیلیها فکر میکنند lazy loading یعنی «دیگر لازم نیست تصویر را بهینه کنم». این اشتباه است و کاربر نهایی هزینه آن را با یک اسکرول کند و لگ میپردازد.
تصمیم نهایی: چه زمانی از lazy loading استفاده کنیم
یک جدول ساده برای تصمیمگیری سریع:
| موقعیت عنصر | lazy loading؟ | دلیل |
|---|---|---|
| تصویر هدر / بنر اصلی | خیر | عنصر LCP است؛ تأخیر یعنی صفحه خالی |
| تصاویر گالری پایین صفحه | بله | کاربر ممکن است هرگز به آنها نرسد |
| تصاویر داخل مقاله بلند | بله | صرفهجویی واقعی در پهنای باند |
| iframe ویدیو / نقشه | بله | سنگینترین عناصر صفحه |
| لوگو در هدر | خیر | کوچک است، اما همیشه دیده میشود |
اگر سایت شما یک صفحه فرود کوتاه با ۳ تصویر است، lazy loading تقریباً هیچ کمکی نمیکند. پیچیدگی اضافهاش ارزش ندارد. این تکنیک برای صفحات بلند با محتوای زیاد طراحی شده، نه برای همهچیز. انتخاب من؟ برای هر پروژه جدید، ابتدا تصاویر را فشرده میکنم، ابعاد را دقیق میدهم، و فقط بعد از آن، برای عناصر پایین صفحه lazy loading اضافه میکنم. اگر صفحه کوتاه است، اصلاً اضافه نمیکنم.
یک نکته آخر درباره ابزارها: اگر با وردپرس کار میکنید، افزونههایی مثل Smush یا ShortPixel این کار را خودکار میکنند. اما خودکار یعنی بیدقت. این افزونهها معمولاً همه تصاویر را lazy میکنند، از جمله تصویر هدر. بعد از نصب، حتماً صفحه اصلی را در PageSpeed Insights چک کنید و اگر خطای «lazily loaded LCP image» دیدید، تصویر هدر را از لیست lazy خارج کنید. این دقیقاً همان جایی است که ابزارهای خودکار، کار دست شما میدهند.
اگر بهدنبال یک بررسی کاملتر از وضعیت سرعت سایت خود هستید، ابزارهای سئو و وبمستر سرورنت میتوانند یک نمای کلی از وضعیت فنی سایت به شما بدهند. اما یادتان باشد: هیچ ابزاری جای درک درست از رفتار مرورگر را نمیگیرد.
پرسشهای پرتکرار
آیا lazy loading روی سئو تأثیر منفی دارد؟
خیر، اگر درست پیادهسازی شود. گوگل محتوای lazy شده را ایندکس میکند و تفاوتی بین تصویر عادی و تنبلشده قائل نمیشود. مشکل فقط وقتی پیش میآید که محتوا بدون جاوااسکریپت در دسترس نباشد، یا تصویر LCP را lazy کنید و سرعت سایت را خراب کنید که بهصورت غیرمستقیم روی رتبه اثر میگذارد.
چطور بفهمم lazy loading کار میکند؟
در Chrome DevTools، تب Network را باز کنید و صفحه را رفرش کنید. به لیست درخواستها نگاه کنید؛ تصاویر پایین صفحه نباید در ابتدا دانلود شوند. حالا اسکرول کنید و ببینید که با نزدیک شدن به هر تصویر، درخواستش ارسال میشود. اگر همه تصاویر از ابتدا دانلود شدند، یا attribute را درست نگذاشتهاید یا مرورگر از آن پشتیبانی نمیکند.
آیا lazy loading برای ویدیو هم کار میکند؟
بله، برای تگ <video> هم میتوانید از loading="lazy" استفاده کنید، اما پشتیبانی مرورگرها محدودتر است. روش مطمئنتر برای ویدیو، استفاده از attribute preload="none" است که به مرورگر میگوید ویدیو را تا شروع پخش دانلود نکند. برای iframeهای یوتیوب هم loading="lazy" بهخوبی کار میکند.
فرق lazy loading با preload چیست؟
این دو دقیقاً برعکس هم هستند. lazy loading میگوید «تا نیاز نشده، دانلود نکن». preload میگوید «همین حالا دانلود کن، چون بهزودی لازم میشود». برای تصویر LCP از fetchpriority="high" یا preload استفاده کنید، برای بقیه از lazy loading. ترکیب این دو روی یک عنصر، رفتار مرورگر را غیرقابل پیشبینی میکند.
دیدگاهها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!