Lazy Loading در وردپرس چرا هنوز اشتباه پیاده می‌شود؟

Lazy Loading در وردپرس یعنی به تأخیر انداختن بارگذاری تصاویر و iframeها تا لحظه‌ای که کاربر به آن‌ها نزدیک می‌شود، و همین سادگی ظاهری دلیل اصلی اشتباه پیاده‌سازی آن در بسیاری از پروژه‌هاست.

از نسخه ۵.۵ وردپرس، صفت loading="lazy" به‌طور خودکار روی تصاویر اعمال می‌شود و همین پیش‌فرض، منبع اصلی اشتباهات است.

سه دام اصلی وجود دارد: اعمال خودکار روی تصویر شاخص، نبود fetchpriority="high" برای عنصر اصلی LCP و بی‌توجهی به تفاوت رفتار مرورگرها.

خطا در هر یک از این سه، یا معیار LCP (Largest Contentful Paint) را خراب می‌کند یا باعث جهش چیدمان و افت معیار CLS (Cumulative Layout Shift) می‌شود.

هدف این نوشته، جدا کردن پیاده‌سازی سطحی از پیاده‌سازی مهندسی‌شده در محیط تولید است.

چند وقت پیش روی سایتی کار می‌کردم که همه معیارهای سرعتش سبز بود، جز یک مورد: LCP روی موبایل مدام بین ۳ تا ۴ ثانیه نوسان داشت. بررسی که انجام شد، ریشه در یک پیش‌فرض وردپرس بود که کسی درباره‌اش تصمیم نگرفته بود. تصویر شاخص صفحه اصلی، به‌طور خودکار loading="lazy" گرفته بود و همین، بزرگ‌ترین عنصر صفحه را به آخر صف بارگذاری می‌فرستاد. تصمیم برای رفع آن، بیش از هر ابزاری، به یک اصلاح کوچک در یک فیلتر وردپرس نیاز داشت.

Lazy Loading دقیقاً چه چیزی را به تأخیر می‌اندازد

Lazy Loading (Lazy loading) یک الگوی طراحی است که در آن، منابع سنگین تنها زمانی بارگذاری می‌شوند که واقعاً مورد نیاز باشند. در زمینه وب، این الگو بیشتر برای تصاویر، iframeها و ویدئوها به کار می‌رود.

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

اثر این الگو روی سایت‌های عکس‌محور چشمگیر است. یک صفحه آرشیو با ۵۰ تصویر می‌تواند بدون Lazy Loading چند مگابایت داده دانلود کند، در حالی که با Lazy Loading، شاید تنها چند تصویر اولیه بارگذاری شود.

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

Lazy Loading بومی مرورگر و پیش‌فرض وردپرس

مرورگرهای مدرن از یک مکانیزم بومی برای Lazy Loading پشتیبانی می‌کنند که بر پایه صفت loading روی عناصر تصویر و iframe کار می‌کند. سه مقدار برای این صفت وجود دارد: lazy، eager و auto.

مقدار lazy به مرورگر می‌گوید که بارگذاری این منبع را تا زمان نیاز به تأخیر بیندازد. مقدار eager برعکس عمل می‌کند و مرورگر را ملزم به بارگذاری فوری می‌کند. مقدار auto تصمیم را به مرورگر می‌سپارد که معمولاً به معنی بارگذاری فوری است.

<img src="photo.webp" loading="lazy" width="800" height="600" alt="...">
<img src="hero.webp" loading="eager" fetchpriority="high" width="1920" height="1080" alt="...">

وردپرس به‌طور پیش‌فرض صفت loading="lazy" را روی همه تصاویر محتوا اعمال می‌کند، به‌جز در مواردی که تصویر در بخش بالایی صفحه (Above the Fold) باشد. تشخیص این موارد با استفاده از تابع wp_get_loading_optimization_attributes انجام می‌شود که در نسخه‌های اخیر وردپرس اضافه شده است.

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

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

هر پیش‌فرضی که بدون تصمیم‌گیری پذیرفته شود، یک بدهی فنی پنهان است؛ و Lazy Loading بومی وردپرس، یکی از پرتکرارترین آن‌هاست.

تله LCP: چرا اعمال خودکار تصویر شاخص را خراب می‌کند

معیار LCP (Largest Contentful Paint) بزرگ‌ترین عنصر محتوایی در بخش قابل مشاهده صفحه را می‌سنجد. در بیشتر سایت‌های وردپرسی، این عنصر یک تصویر است: تصویر شاخص نوشته، بنر صفحه اصلی یا تصویر اصلی محصول.

وقتی تصویر LCP صفت loading="lazy" می‌گیرد، مرورگر آن را در اولویت پایین بارگذاری می‌کند. یعنی حتی اگر تصویر در بخش بالایی صفحه باشد، بارگذاری آن پس از تصاویر دیگر انجام می‌شود. نتیجه، تأخیر مستقیم در LCP و افت معیار Core Web Vitals است.

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

راه‌حل، استفاده از فیلتر wp_get_loading_optimization_attributes یا فیلتر wp_img_tag_add_loading_attr برای کنترل دستی صفت loading روی تصویر LCP است.

add_filter( "wp_get_loading_optimization_attributes", function ( $attr, $tag_name, $context ) {
    if ( "img" !== $tag_name || ! is_singular() ) {
        return $attr;
    }
    $post_thumbnail_id = get_post_thumbnail_id();
    if ( ! $post_thumbnail_id ) {
        return $attr;
    }
    $post_thumbnail_url = wp_get_attachment_image_url( $post_thumbnail_id, "full" );
    if ( $post_thumbnail_url && false !== strpos( $context, $post_thumbnail_url ) ) {
        $attr["loading"]       = "eager";
        $attr["fetchpriority"] = "high";
    }
    return $attr;
}, 10, 3 );

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

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

مسئله مرتبط، اعمال Lazy Loading روی تصاویر بالای صفحه در صفحه‌های غیرمفرد است. صفحه‌های آرشیو، صفحه‌های دسته‌بندی و صفحه اصلی وبلاگ، همه تصویر بالای خود را دارند. در این موارد، منطق تشخیص باید گسترده‌تر از تصویر شاخص باشد.

fetchpriority و تعیین اولویت واقعی

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

ترکیب fetchpriority="high" با loading="eager" روی تصویر LCP، بهترین نتیجه را می‌دهد. این ترکیب به مرورگر می‌گوید تصویر را با بالاترین اولویت ممکن بارگذاری کند.

<img src="hero.webp" loading="eager" fetchpriority="high" width="1920" height="1080" alt="Hero">

در سمت دیگر، fetchpriority="low" برای منابعی مناسب است که بارگذاری‌شان در صف پایین، تجربه کاربر را بهتر می‌کند. مثلاً تصاویری که در پاورقی یا بخش‌های دور از دید هستند.

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

نکته ظریف دیگر، ترتیب استفاده از این صفت در آرشیوهای تصویری است. در صفحه‌ای که چند تصویر بالای صفحه دارد، تنها یکی از آن‌ها باید fetchpriority="high" بگیرد. اعمال این صفت روی چند منبع، اثر آن را از بین می‌برد، چون مرورگر منابع متعدد را رقابتی بارگذاری می‌کند.

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

صفت decoding و رفتار مرورگر در رمزگشایی

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

سه مقدار برای این صفت وجود دارد: sync، async و auto. مقدار sync مرورگر را مجبور به رمزگشایی همزمان می‌کند که می‌تواند به تأخیر در نمایش کمک کند. مقدار async اجازه می‌دهد رمزگشایی در پس‌زمینه انجام شود. مقدار auto تصمیم را به مرورگر می‌سپارد.

<img src="hero.webp" loading="eager" fetchpriority="high" decoding="sync" width="1920" height="1080" alt="Hero">
<img src="photo.webp" loading="lazy" decoding="async" width="800" height="600" alt="...">

برای تصویر LCP، مقدار sync منطقی است، چون نمایش فوری آن هدف اصلی است. برای تصاویر پایین صفحه که Lazy Loading روی آن‌ها اعمال شده، async انتخاب بهتری است تا پردازش رمزگشایی بلاک نشود.

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

کتابخانه‌های جاوااسکریپتی و مشکل تشخیص تصویر اصلی

پیش از Lazy Loading بومی، کتابخانه‌های جاوااسکریپتی مانند LazySizes، lozad و yall جایگزین اصلی بودند. این کتابخانه‌ها همچنان در برخی پروژه‌ها استفاده می‌شوند و دلایل مشخصی هم دارند: پشتیبانی از مرورگرهای قدیمی، کنترل دقیق‌تر و قابلیت‌های پیشرفته مانند Placeholder و انیمیشن ورود.

مسئله اصلی این کتابخانه‌ها، نحوه تشخیص تصویر اصلی است. بیشتر آن‌ها با استفاده از IntersectionObserver (رابط برنامه‌نویسی رصد تقاطع عناصر) کار می‌کنند و تصاویر را زمانی بارگذاری می‌کنند که وارد بخش قابل مشاهده صفحه شوند. این منطق، برای تصویر LCP که از ابتدا در بخش قابل مشاهده است، می‌تواند به تأخیر مصنوعی منجر شود.

بسیاری از این کتابخانه‌ها مکانیزمی برای خارج‌کردن تصویر اصلی از Lazy Loading دارند، اما این مکانیزم باید به‌درستی تنظیم شود. تنظیم ناقص، همان تله LCP را بازتولید می‌کند، با این تفاوت که حالا در لایه جاوااسکریپت پنهان شده است.

در پروژه‌هایی که این کتابخانه‌ها را حفظ کرده‌اند، ترکیب با Lazy Loading بومی می‌تواند به تعارض منجر شود. اگر وردپرس loading="lazy" را روی تصویری بگذارد و کتابخانه هم همان تصویر را مدیریت کند، رفتار نهایی می‌تواند پیش‌بینی‌ناپذیر شود.

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

در ادامه این تصمیم‌گیری، توجه به جزئیات تجربه کاربر اهمیت دارد. روابط میان Lazy Loading، ابعاد صریح و جلوگیری از جهش چیدمان، موضوعی است که در مسیر کاهش CLS به‌طور کامل بررسی شده است.

اگریم‌ها، ویدئوها و پس‌زمینه‌ها

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

Lazy Loading بومی روی iframeها هم کار می‌کند و می‌تواند با صفت loading="lazy" فعال شود. این ویژگی، به‌خصوص برای صفحاتی که چند ویدئو دارند، اثر قابل توجهی دارد.

<iframe src="https://www.youtube.com/embed/VIDEO_ID" loading="lazy" width="560" height="315" title="..."></iframe>

برای ویدئوهای بومی HTML5، صفت preload="none" روی عنصر video می‌تواند مشابه Lazy Loading عمل کند. این صفت به مرورگر می‌گوید داده‌ای پیش از پخش بارگذاری نکند.

<video controls preload="none" poster="poster.webp" width="640" height="360">
    <source src="video.mp4" type="video/mp4">
</video>

تصاویر پس‌زمینه که با CSS اعمال می‌شوند، از Lazy Loading بومی پشتیبانی نمی‌کنند. این محدودیت، در سایت‌هایی که از این تصاویر زیاد استفاده می‌کنند، به یک مسئله عملی تبدیل می‌شود. راه‌حل‌های ممکن شامل استفاده از عناصر picture به‌جای پس‌زمینه CSS یا استفاده از کتابخانه‌های جاوااسکریپتی است.

مسئله دیگری که در پروژه‌ها کمتر به آن توجه می‌شود، Lazy Loading روی iframeهای شخص ثالث است. برخی سرویس‌ها مانند نقشه‌های تعاملی یا ابزارهای چت، iframeهایی با محتوای سنگین تزریق می‌کنند. اعمال Lazy Loading روی این iframeها می‌تواند تجربه کاربر را بهبود دهد، اما باید مراقب بود که عملکرد اصلی سرویس مختل نشود.

CLS و اهمیت ابعاد صریح

CLS (Cumulative Layout Shift) معیاری است که مقدار جابه‌جایی ناخواسته عناصر صفحه در زمان بارگذاری را می‌سنجد. Lazy Loading می‌تواند این معیار را خراب کند اگر تصاویر بدون ابعاد صریح باشند.

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

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

<img src="photo.webp" loading="lazy" width="800" height="600" alt="..." style="width:100%;height:auto;">

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

نکته مهم دیگر، اعمال CSS مناسب است. اگر استایل تصویر ابعاد را به‌طور کامل بازنویسی کند، ابعاد صریح اثر خود را از دست می‌دهند. بهترین رویکرد، استفاده از ترکیب ابعاد صریح و استایل width:100%; height:auto; است که در آن، نسبت ابعاد از صفت‌ها استخراج می‌شود.

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

Lazy Loading بدون ابعاد صریح، صرفه‌جویی در پهنای باند را با افت تجربه کاربر معاوضه می‌کند.

content-visibility و مرز با Lazy Loading

ویژگی content-visibility در CSS یک مفهوم مرتبط اما متفاوت از Lazy Loading است. این ویژگی به مرورگر می‌گوید رندر بخش‌هایی از صفحه را به تأخیر بیندازد تا زمانی که به آن‌ها نزدیک شود.

.deferred-section {
    content-visibility: auto;
    contain-intrinsic-size: 0 500px;
}

تفاوت اصلی این است که content-visibility روی رندر اثر می‌گذارد، نه روی بارگذاری. یعنی منابع ممکن است بارگذاری شوند، اما رندر آن‌ها به تأخیر می‌افتد. این ویژگی در صفحات بسیار طولانی اثر قابل توجهی دارد، چون هزینه رندر را کاهش می‌دهد.

پارامتر contain-intrinsic-size برای رزرو فضا استفاده می‌شود و به جلوگیری از CLS کمک می‌کند. اگر این پارامتر تعیین نشود، مرورگر نمی‌داند چه ابعادی برای بخش به تأخیر افتاده رزرو کند.

ترکیب این دو ویژگی می‌تواند اثر مطلوبی داشته باشد. Lazy Loading بارگذاری را به تأخیر می‌اندازد و content-visibility رندر را. در صفحات طولانی با محتوای سنگین، این ترکیب می‌تواند تجربه کاربر را به‌طور محسوس بهبود دهد.

توجه به این نکته ضروری است که content-visibility هنوز پشتیبانی کامل همه مرورگرها را ندارد. در مرورگرهایی که آن را پشتیبانی نمی‌کنند، رفتار عادی رندر اعمال می‌شود که مشکلی ایجاد نمی‌کند. این ویژگی، به‌عنوان یک بهبود اختیاری در نظر گرفته می‌شود، نه یک شرط لازم.

Lazy Loading در فروشگاه ووکامرس

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

Lazy Loading در این صفحات، به‌طور پیش‌فرض از طرف وردپرس اعمال می‌شود. مسئله، تصویر اصلی صفحه محصول است که در بیشتر موارد عنصر LCP است. اگر این تصویر صفت lazy بگیرد، تجربه صفحه محصول دچار افت می‌شود.

add_filter( "wp_get_loading_optimization_attributes", function ( $attr, $tag_name, $context ) {
    if ( "img" !== $tag_name ) {
        return $attr;
    }
    if ( function_exists( "is_product" ) && is_product() ) {
        global $product;
        if ( $product ) {
            $main_image_id = $product->get_image_id();
            $main_image_url = wp_get_attachment_image_url( $main_image_id, "woocommerce_single" );
            if ( $main_image_url && false !== strpos( $context, $main_image_url ) ) {
                $attr["loading"]       = "eager";
                $attr["fetchpriority"] = "high";
            }
        }
    }
    return $attr;
}, 10, 3 );

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

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

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

سنجش، آزمایش و ابزارها

سنجش اثر Lazy Loading نیازمند ابزارهای دقیق است. سه سطح اندازه‌گیری وجود دارد: سطح عنصر، سطح صفحه و سطح تجربه کاربر.

در سطح عنصر، تب Network در ابزار توسعه‌دهنده مرورگر نشان می‌دهد هر تصویر چه زمانی بارگذاری شده است. اگر تصویر LCP بعد از سایر تصاویر بارگذاری شود، احتمالاً اعمال lazy روی آن اشتباه است.

در سطح صفحه، ابزارهای مانند Lighthouse و PageSpeed Insights معیارهای Core Web Vitals را اندازه می‌گیرند. توجه به این ابزارها در سرعت واقعی کاربر مهم است، چون شرایط آزمایشگاهی می‌تواند تفاوت قابل توجهی با تجربه میدانی داشته باشد. ابزارهای مناسب برای این اندازه‌گیری در ابزارهای سنجش Core Web Vitals معرفی شده‌اند.

در سطح تجربه کاربر، داده‌های CrUX (Chrome User Experience Report) تصویر واقعی‌تری از تجربه کاربران ارائه می‌دهد. این داده‌ها بر اساس نمونه‌های واقعی از کاربران کروم ساخته می‌شوند و تفاوت‌های جغرافیایی و شبکه‌ای را بازتاب می‌دهند.

روش آزمایش A/B برای Lazy Loading می‌تواند مفید باشد. دو نسخه از یک صفحه، یکی با Lazy Loading و یکی بدون آن، در بازه‌ای مشخص آزمایش می‌شوند و اثر روی معیارهای کلیدی سنجیده می‌شود. این روش، جای شک را با داده عوض می‌کند.

نکته مهم دیگر، آزمایش روی دستگاه‌ها و شبکه‌های مختلف است. Lazy Loading روی شبکه‌های کند و دستگاه‌های ضعیف، اثر بیشتری دارد. آزمایش فقط روی دسکتاپ با اینترنت پرسرعت، تصویر ناقصی ارائه می‌دهد.

جدول تصمیم‌گیری سیاست Lazy Loading

اشتباهات رایج

نخستین اشتباه، پذیرش بی‌قید و شرط پیش‌فرض وردپرس است. این پیش‌فرض برای بیشتر سایت‌ها خوب است، اما برای قالب‌های سفارشی و ساختارهای غیرمعمول، نیازمند بازبینی است.

دومین اشتباه، نبود تمایز میان تصویر LCP و تصاویر دیگر است. اعمال یکسان loading="lazy" روی همه تصاویر، معیار LCP را خراب می‌کند.

سومین اشتباه، فراموش‌کردن fetchpriority است. حتی اگر تصویر LCP صفت eager داشته باشد، بدون fetchpriority="high" ممکن است رقابت با سایر منابع باعث تأخیر در بارگذاری شود.

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

پنجمین اشتباه، ترکیب Lazy Loading بومی با کتابخانه‌های جاوااسکریپتی بدون هماهنگی است. نتیجه، تعارض در رفتار و پیش‌بینی‌ناپذیری نتایج.

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

هفتمین اشتباه، آزمایش فقط روی دسکتاپ با اینترنت پرسرعت است. Lazy Loading بیشترین اثر را روی شبکه‌های کند و دستگاه‌های ضعیف دارد و آزمایش فقط روی یک سناریو، تصویر ناقصی ارائه می‌دهد. این موضوع با مسیر اشتباهات رایج در بهینه‌سازی تصاویر هم‌راستا است، چون هر دو به یک پیاده‌سازی ناقص اشاره می‌کنند.

هشتمین اشتباه، فشرده‌نکردن تصاویر پیش از Lazy Loading است. اگر تصاویر بهینه نشده باشند، Lazy Loading تنها بارگذاری را به تأخیر می‌اندازد، نه حجم را کاهش می‌دهد. فشرده‌سازی تصاویر پیش از Lazy Loading، در مسیر فشرده‌سازی تصاویر سایت به‌تفصیل آمده است.

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

پرسش‌های پرتکرار درباره Lazy Loading در وردپرس

آیا Lazy Loading روی همه تصاویر باید اعمال شود؟

خیر. تصویر LCP و تصاویر بخش بالای صفحه باید از Lazy Loading مستثنا شوند. اعمال loading="lazy" روی این تصاویر، معیار LCP را خراب می‌کند. تصاویر بخش پایین صفحه، کاندید اصلی Lazy Loading هستند.

چرا وردپرس به‌طور خودکار Lazy Loading را اعمال می‌کند؟

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

تفاوت loading="lazy" و loading="eager" چیست؟

lazy بارگذاری را تا زمان نیاز به تأخیر می‌اندازد. eager مرورگر را ملزم به بارگذاری فوری می‌کند. برای تصویر LCP، eager انتخاب درست است.

چرا LCP سایت با فعال بودن Lazy Loading بهبود پیدا نمی‌کند؟

احتمالاً تصویر LCP صفت loading="lazy" گرفته است و در اولویت پایین بارگذاری می‌شود. علاوه بر این، نبود fetchpriority="high" می‌تواند رقابت با سایر منابع را تشدید کند.

آیا Lazy Loading روی CLS اثر دارد؟

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

آیا Lazy Loading برای iframeها هم کار می‌کند؟

بله، صفت loading="lazy" روی iframeها پشتیبانی می‌شود. این موضوع برای iframeهای ویدئو، نقشه و محتوای سنگین خارجی اهمیت ویژه دارد.

آیا Lazy Loading جایگزین بهینه‌سازی تصویر است؟

خیر. Lazy Loading بارگذاری را به تأخیر می‌اندازد اما حجم تصویر را کاهش نمی‌دهد. برای بهینه‌سازی واقعی، تصاویر باید فشرده شوند و از فرمت‌های مدرن مانند WebP یا AVIF استفاده کنند.

چرا Lazy Loading روی تصاویر پس‌زمینه CSS کار نمی‌کند؟

Lazy Loading بومی مرورگر فقط روی عناصر تصویر و iframe اعمال می‌شود. تصاویر پس‌زمینه CSS از این پشتیبانی برخوردار نیستند و نیازمند راه‌حل‌های جایگزین مانند استفاده از عنصر picture یا کتابخانه‌های جاوااسکریپتی هستند.

آیا Lazy Loading روی سئو اثر دارد؟

اثر مستقیم ندارد، اما اثر غیرمستقیم آن جدی است. اگر Lazy Loading درست پیاده شود، معیارهای Core Web Vitals بهبود می‌یابد و این معیارها به‌عنوان سیگنال کیفیت در نظر گرفته می‌شوند. اگر اشتباه پیاده شود، می‌تواند به افت LCP و CLS منجر شود.

آیا Lazy Loading بر خزش موتورهای جستجو اثر منفی دارد؟

نه به‌طور ذاتی. موتورهای جستجوی مدرن جاوااسکریپت را اجرا می‌کنند و Lazy Loading را درک می‌کنند. اما اگر تصاویر حیاتی به‌درستی در ساختار صفحه نباشند، ممکن است در فهرست‌بندی تصاویر تأخیر ایجاد شود. برای سایت‌های عکس‌محور، این موضوع نیازمند توجه است.

آیا content-visibility جایگزین Lazy Loading است؟

خیر. این دو مفهوم مرتبط اما متفاوت هستند. Lazy Loading بارگذاری منابع را به تأخیر می‌اندازد و content-visibility رندر بخش‌هایی از صفحه را به تأخیر می‌اندازد. ترکیب این دو، اثر مطلوبی در صفحات طولانی دارد.

یک نکته برای ادامه مسیر

Lazy Loading یک تصمیم ساده نیست؛ مجموعه‌ای از تصمیم‌های کوچک است که هر یک بر دیگری اثر می‌گذارد. صفت loading، fetchpriority، decoding، ابعاد صریح، نوع عنصر و زمینه صفحه، همه در نتیجه نهایی شریک‌اند. تفاوت میان یک پیاده‌سازی سطحی و یک پیاده‌سازی مهندسی‌شده، در همین جزئیات است.

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