Responsive Images در وردپرس یک ضرورت عملکردی است که با استفاده از تگ‌های srcset و sizes، تصاویر مناسب هر دستگاه را بارگذاری می‌کند و پهنای باند مصرفی کاربران موبایل را تا ۷۰ درصد کاهش می‌دهد. بدون تصاویر ریسپانسیو، کاربران موبایل با صفحه کوچک، همان تصویر ۲۰۰۰ پیکسلی دسکتاپ را دانلود می‌کنند که حجم آن چند برابر نیاز واقعی است. وردپرس از نسخه ۴.۴ به بعد به‌طور بومی از Responsive Images پشتیبانی می‌کند و توابعی مثل `wp_get_attachment_image()` و `the_post_thumbnail()` به‌صورت خودکار srcset و sizes تولید می‌کنند. اما در بلاک‌های سفارشی، قالب‌های دست‌ساز و استفاده از تگ img ساده، این قابلیت نادیده گرفته می‌شود و منجر به افت LCP و افزایش نرخ پرش می‌گردد. این مقاله چارچوب کامل پیاده‌سازی Responsive Images در وردپرس، از srcset و sizes تا Art Direction و Picture Element، را ارائه می‌دهد.

در یک پروژه فروشگاهی، تحلیل داده‌های RUM (Real User Monitoring) نشان داد که ۴۰٪ کاربران موبایل، LCP بالای ۴ ثانیه تجربه می‌کنند. بررسی WebPageTest نشان داد که تصویر شاخص محصول، با ابعاد ۱۸۰۰×۱۲۰۰ پیکسل و حجم ۴۸۰ کیلوبایت، برای همه دستگاه‌ها ارسال می‌شود. بعد از پیاده‌سازی Responsive Images، همان تصویر در موبایل با ابعاد ۶۰۰×۴۰۰ و حجم ۹۰ کیلوبایت بارگذاری شد و LCP به ۲.۱ ثانیه کاهش یافت.

Responsive Images چیست و چرا ضروری است؟

Responsive Images (تصاویر ریسپانسیو) مجموعه‌ای از تکنیک‌های HTML و CSS است که به مرورگر اجازه می‌دهد تصویر مناسب هر دستگاه را از میان چند نسخه انتخاب کند. این تکنیک‌ها بر پایه دو Attribute بنا شده‌اند: srcset که لیست نسخه‌های تصویر را تعریف می‌کند، و sizes که اندازه نمایش تصویر در Viewportهای مختلف را توصیف می‌نماید.

ضرورت Responsive Images از چند جهت قابل تحلیل است. اول، مصرف پهنای باند: تصاویر بخش عمده حجم صفحات وب را تشکیل می‌دهند — حدود ۵۰ تا ۷۰ درصد. اگر کاربر موبایل، همان تصویر دسکتاپ را دانلود کند، پهنای باند بیهوده مصرف می‌شود. دوم، سرعت بارگذاری: تصاویر بزرگ‌تر، زمان بارگذاری بیشتری دارند و LCP را افزایش می‌دهند. سوم، هزینه داده کاربر: در ایران، بسیاری از کاربران از اینترنت موبایل با حجم محدود استفاده می‌کنند و دانلود تصاویر غیرضروری، هزینه واقعی برای آن‌ها دارد.

«Responsive Images نه فقط یک بهینه‌سازی فنی، یک احترام به کاربر است: به او فقط آنچه نیاز دارد را بدهید، نه بیشتر.»

اگر با مفاهیم Core Web Vitals و اهمیت آن آشنا شده باشید، می‌دانید که LCP یکی از سه معیار اصلی گوگل است و تصاویر، بزرگ‌ترین عامل تأثیرگذار بر آن هستند.

سناریو حجم تصویر زمان بارگذاری
تصویر ۱۸۰۰px بدون srcset ۴۸۰ KB ۲.۵s (4G)
تصویر ۶۰۰px با srcset ۹۰ KB ۰.۵s (4G)
تصویر ۳۰۰px موبایل ۳۵ KB ۰.۲s (4G)

مرورگر چگونه تصویر مناسب را انتخاب می‌کند؟

فرآیند انتخاب تصویر توسط مرورگر، بر پایه سه عامل انجام می‌شود: Viewport Width (عرض پنجره مرورگر)، Device Pixel Ratio (نسبت پیکسل دستگاه)، و sizes Attribute (اندازه نمایش تصویر). درک این فرآیند، پیش‌نیاز پیاده‌سازی صحیح است.

عامل اول: Viewport Width. عرض پنجره مرورگر، مبنای اولیه انتخاب است. اگر Viewport ۴۰۰ پیکسل باشد، مرورگر به دنبال تصویری می‌گردد که برای این عرض بهینه باشد.

عامل دوم: Device Pixel Ratio (DPR). دستگاه‌های با صفحه Retina (مثل iPhone و MacBook) نسبت پیکسل بالاتری دارند. اگر DPR برابر ۲ باشد، مرورگر به تصویری با ابعاد دو برابر نیاز دارد تا وضوح حفظ شود.

عامل سوم: sizes Attribute. این Attribute به مرورگر می‌گوید تصویر در هر Viewport چقدر عرض خواهد داشت:

sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"

این یعنی: اگر Viewport کمتر از ۶۰۰ پیکسل باشد، تصویر ۱۰۰٪ عرض Viewport را می‌گیرد. اگر بین ۶۰۰ و ۱۲۰۰ باشد، ۵۰٪ عرض. و اگر بزرگ‌تر باشد، ۸۰۰ پیکسل ثابت.

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

<img
  src="image-800.jpg"
  srcset="image-400.jpg 400w,
          image-800.jpg 800w,
          image-1200.jpg 1200w,
          image-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="توضیح تصویر"
  width="800"
  height="600"
>

پشتیبانی بومی وردپرس از Responsive Images

وردپرس از نسخه ۴.۴ (دسامبر ۲۰۱۵) پشتیبانی بومی از Responsive Images را اضافه کرد. این پشتیبانی بر پایه دو مکانیزم است:

مکانیزم اول: تولید خودکار اندازه‌ها. وقتی تصویری در وردپرس آپلود می‌شود، چند نسخه با ابعاد مختلف تولید می‌گردد. این ابعاد در Settings → Media قابل تنظیم هستند:

Thumbnail: 150×150
Medium: 300×300
Medium Large: 768×0 (عرض ثابت)
Large: 1024×1024

علاوه بر این، وردپرس اندازه 1536×1536 و 2048×2048 را برای تصاویر بزرگ‌تر تولید می‌کند که در نسخه ۵.۳ اضافه شده‌اند. اگر با بهترین فرمت تصویر برای وب آشنا شده باشید، می‌دانید که این اندازه‌ها، پایه Responsive Images هستند.

مکانیزم دوم: تولید خودکار srcset. توابع وردپرس مثل wp_get_attachment_image() و the_post_thumbnail() به‌طور خودکار srcset و sizes تولید می‌کنند:

<?php
echo wp_get_attachment_image(
    get_post_thumbnail_id(),
    'large',
    false,
    array(
        'class' => 'featured-image',
        'sizes' => '(max-width: 600px) 100vw, 800px',
    )
);
?>

این تابع، HTML کاملی با src، srcset، sizes، width و height تولید می‌کند. نکته مهم: اگر sizes تعریف نشود، وردپرس از یک مقدار پیش‌فرض استفاده می‌کند که ممکن است دقیق نباشد.

srcset و sizes: قلب تصاویر ریسپانسیو

دو روش برای تعریف srcset وجود دارد: Width Descriptors و Pixel Density Descriptors. انتخاب بین این دو، به کاربرد تصویر بستگی دارد.

روش اول: Width Descriptors. در این روش، عرض هر نسخه تصویر با پسوند w مشخص می‌شود:

srcset="image-400.jpg 400w,
        image-800.jpg 800w,
        image-1200.jpg 1200w"

این روش، مناسب تصاویری است که در Viewportهای مختلف با اندازه‌های متفاوت نمایش داده می‌شوند (مثل تصویر شاخص نوشته).

روش دوم: Pixel Density Descriptors. در این روش، تراکم پیکسل با پسوند x مشخص می‌شود:

srcset="image-400.jpg 1x,
        image-800.jpg 2x,
        image-1200.jpg 3x"

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

ترکیب این دو روش با sizes، امکان انتخاب دقیق را فراهم می‌کند:

<img
  src="image-800.jpg"
  srcset="image-400.jpg 400w,
          image-800.jpg 800w,
          image-1200.jpg 1200w,
          image-1600.jpg 1600w"
  sizes="(max-width: 480px) 100vw,
         (max-width: 768px) 80vw,
         (max-width: 1024px) 60vw,
         800px"
  alt="تصویر نمونه"
  width="800"
  height="600"
  loading="lazy"
>

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

Picture Element و Art Direction

Picture Element (<picture>) یک Alternative برای <img> است که امکان Art Direction (هدایت هنری) و انتخاب فرمت را فراهم می‌کند. سه کاربرد اصلی:

کاربرد اول: Art Direction. نمایش تصاویر مختلف در Viewportهای مختلف. مثلاً در دسکتاپ یک تصویر افقی و در موبایل یک تصویر عمودی:

<picture>
  <source media="(max-width: 600px)" srcset="mobile-vertical.jpg">
  <source media="(min-width: 601px)" srcset="desktop-horizontal.jpg">
  <img src="desktop-horizontal.jpg" alt="تصویر نمونه">
</picture>

کاربرد دوم: انتخاب فرمت. ارائه فرمت‌های مدرن (WebP، AVIF) با Fallback برای مرورگرهای قدیمی:

<picture>
  <source type="image/avif" srcset="image.avif">
  <source type="image/webp" srcset="image.webp">
  <img src="image.jpg" alt="تصویر نمونه">
</picture>

کاربرد سوم: ترکیب Art Direction و فرمت. استفاده همزمان از هر دو قابلیت:

<picture>
  <source media="(max-width: 600px)" type="image/webp" srcset="mobile.webp">
  <source media="(max-width: 600px)" type="image/jpeg" srcset="mobile.jpg">
  <source type="image/webp" srcset="desktop.webp">
  <img src="desktop.jpg" alt="تصویر نمونه">
</picture>

در وردپرس، Picture Element به‌طور خودکار توسط توابع بومی تولید نمی‌شود. برای استفاده از آن، باید بلاک سفارشی یا کد سفارشی نوشت. اگر با مقایسه WebP و JPEG برای سرعت آشنا شده باشید، می‌دانید که WebP می‌تواند حجم را ۳۰ تا ۵۰ درصد کاهش دهد.

توابع وردپرس برای Responsive Images

وردپرس چند تابع کلیدی برای Responsive Images فراهم می‌کند که هرکدام کاربرد خاصی دارند:

تابع اول: wp_get_attachment_image(). این تابع، HTML کامل <img> با srcset، sizes، width و height تولید می‌کند. بهترین انتخاب برای بلاک‌های سفارشی و قالب‌های دست‌ساز:

echo wp_get_attachment_image(
    $attachment_id,
    'large',
    false,
    array(
        'class' => 'custom-image',
        'sizes' => '(max-width: 768px) 100vw, 50vw',
        'loading' => 'lazy',
        'decoding' => 'async',
    )
);

تابع دوم: the_post_thumbnail(). این تابع، تصویر شاخص نوشته را نمایش می‌دهد و به‌طور خودکار srcset تولید می‌کند:

the_post_thumbnail(
    'large',
    array(
        'class' => 'featured-image',
        'sizes' => '(max-width: 768px) 100vw, 800px',
    )
);

تابع سوم: get_the_post_thumbnail_url(). این تابع، فقط URL تصویر را برمی‌گرداند و برای مواردی که نیاز به HTML سفارشی دارید، مفید است.

تابع چهارم: wp_calculate_image_sizes(). این تابع، مقدار sizes را بر پایه اندازه تصویر محاسبه می‌کند. وردپرس از این تابع به‌صورت داخلی استفاده می‌کند.

تابع خروجی کاربرد
wp_get_attachment_image() HTML کامل img بلاک سفارشی، قالب دست‌ساز
the_post_thumbnail() HTML کامل img تصویر شاخص نوشته
get_the_post_thumbnail_url() URL HTML سفارشی
wp_calculate_image_sizes() مقدار sizes محاسبه دستی

Responsive Images در بلاک‌های سفارشی

در بلاک‌های سفارشی گوتنبرگ، اگر از تابع wp_get_attachment_image() استفاده نکنید، Responsive Images به‌طور خودکار اعمال نمی‌شود. سه رویکرد برای حل این مشکل:

رویکرد اول: استفاده از wp_get_attachment_image() در Render Callback. اگر بلاک شما داینامیک است، از این تابع در render_callback استفاده کنید:

function my_block_render_callback( $attributes ) {
    if ( empty( $attributes['imageId'] ) ) {
        return '';
    }
    
    return wp_get_attachment_image(
        $attributes['imageId'],
        'large',
        false,
        array(
            'class' => 'my-block-image',
            'sizes' => '(max-width: 768px) 100vw, 50vw',
        )
    );
}

رویکرد دوم: استفاده از @wordpress/components در ویرایشگر. اگر بلاک شما استاتیک است و از save.js استفاده می‌کند، باید srcset و sizes را به‌صورت دستی تولید کنید:

export default function save( { attributes } ) {
    const { imageUrl, imageAlt, imageWidth, imageHeight } = attributes;
    
    return (
        <img
            src={ imageUrl }
            srcset={ attributes.srcset }
            sizes="(max-width: 768px) 100vw, 50vw"
            alt={ imageAlt }
            width={ imageWidth }
            height={ imageHeight }
            loading="lazy"
        />
    );
}

رویکرد سوم: استفاده از بلاک Image بومی. اگر بلاک شما یک تصویر ساده را نمایش می‌دهد، به‌جای ساخت بلاک سفارشی، از بلاک core/image استفاده کنید که به‌طور خودکار Responsive است. اگر با ساخت بلاک سفارشی گوتنبرگ از صفر آشنا شده باشید، می‌دانید که استفاده از بلاک بومی در بسیاری از موارد انتخاب عاقلانه‌تری است.

WebP، AVIF و فرمت‌های مدرن

Responsive Images فقط به ابعاد محدود نمی‌شود؛ فرمت نیز بخشی از بهینه‌سازی است. سه فرمت اصلی برای وب وجود دارد:

فرمت اول: JPEG. فرمت کلاسیک که در تمام مرورگرها پشتیبانی می‌شود. حجم آن بزرگ‌تر از WebP و AVIF است اما سازگاری بالایی دارد.

فرمت دوم: WebP. فرمت مدرن گوگل که از سال ۲۰۱۰ معرفی شد. حجم آن ۳۰ تا ۵۰ درصد کمتر از JPEG است و در تمام مرورگرهای مدرن پشتیبانی می‌شود.

فرمت سوم: AVIF. فرمت جدیدتر که از سال ۲۰۱۹ معرفی شد. حجم آن ۵۰ تا ۷۰ درصد کمتر از JPEG است اما پشتیبانی مرورگرها هنوز کامل نیست. اگر با بهترین فرمت تصویر برای وب آشنا شده باشید، می‌دانید که AVIF آینده تصاویر وب است.

<picture>
  <source type="image/avif" srcset="image-400.avif 400w, image-800.avif 800w">
  <source type="image/webp" srcset="image-400.webp 400w, image-800.webp 800w">
  <img src="image-800.jpg" srcset="image-400.jpg 400w, image-800.jpg 800w" alt="تصویر نمونه">
</picture>

در وردپرس، تولید خودکار WebP و AVIF نیازمند افزونه است. افزونه‌هایی مثل Imagify، ShortPixel و Optimole این کار را انجام می‌دهند. اگر با بررسی امکانات و محدودیت‌های Imagify آشنا شده باشید، می‌دانید که این افزونه‌ها تفاوت محسوسی در LCP ایجاد می‌کنند.

Lazy Loading و ارتباط با Responsive Images

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

<img src="image.jpg" loading="lazy" alt="تصویر">

اما نکته حیاتی این است که تصویر LCP نباید Lazy Load شود. اگر تصویر Hero یا تصویر شاخص، بزرگ‌ترین عنصر قابل مشاهده در Viewport اولیه باشد، باید با loading="eager" و fetchpriority="high" علامت‌گذاری شود:

<img
  src="hero.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
  width="1200"
  height="600"
  alt="تصویر اصلی"
>

در وردپرس، می‌توان این تنظیم را با فیلتر wp_get_attachment_image_attributes اعمال کرد:

add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
    if ( is_singular() && $attachment->ID === get_post_thumbnail_id() ) {
        $attr['loading'] = 'eager';
        $attr['fetchpriority'] = 'high';
    }
    return $attr;
}, 10, 3 );

اگر با LCP و روش‌های بهینه‌سازی آن آشنا شده باشید، می‌دانید که این تنظیم یکی از مؤثرترین گام‌ها در بهبود LCP است.

تأثیر بر Core Web Vitals

Responsive Images تأثیر مستقیمی بر Core Web Vitals دارد، به‌ویژه بر LCP و CLS:

تأثیر بر LCP. با کاهش حجم تصویر و تسریع بارگذاری، LCP بهبود می‌یابد. اگر تصویر LCP از ۴۸۰ کیلوبایت به ۹۰ کیلوبایت کاهش یابد، زمان بارگذاری روی شبکه 4G از ۲.۵ ثانیه به ۰.۵ ثانیه می‌رسد.

تأثیر بر CLS. اگر width و height تصویر تعریف شوند، مرورگر فضای موردنیاز را از قبل رزرو می‌کند و CLS کاهش می‌یابد:

<img src="image.jpg" width="800" height="600" alt="تصویر">

اگر با CLS و روش‌های کاهش آن آشنا شده باشید، می‌دانید که نبود width و height یکی از شایع‌ترین دلایل CLS است.

تأثیر بر INP. INP (Interaction to Next Paint) کمتر تحت تأثیر Responsive Images است اما اگر تصاویر بزرگ، Main Thread را اشغال کنند، INP افزایش می‌یابد.

«Responsive Images یکی از کم‌هزینه‌ترین و پربازده‌ترین بهینه‌سازی‌هاست: چند خط HTML اضافه می‌شود، اما تجربه موبایل به‌طور کامل متحول می‌گردد.»

اشتباهات رایج در Responsive Images

اشتباه اول: نبود srcset. اگر از <img src="image.jpg"> ساده استفاده شود، مرورگر همان تصویر را برای همه دستگاه‌ها بارگذاری می‌کند. راه‌حل: استفاده از wp_get_attachment_image() یا تعریف دستی srcset.

اشتباه دوم: sizes نادرست. اگر sizes به‌درستی تعریف نشود، مرورگر تصویر اشتباهی انتخاب می‌کند. مثلاً اگر sizes="100vw" باشد اما تصویر در واقع ۵۰٪ عرض را بگیرد، مرورگر تصویر بزرگ‌تری دانلود می‌کند.

اشتباه سوم: نبود width و height. اگر ابعاد تصویر تعریف نشوند، مرورگر نمی‌تواند فضا را از قبل رزرو کند و CLS افزایش می‌یابد.

اشتباه چهارم: Lazy Loading برای تصویر LCP. اگر تصویر Hero با loading="lazy" بارگذاری شود، LCP به‌شدت افزایش می‌یابد. راه‌حل: loading="eager" و fetchpriority="high".

اشتباه پنجم: فرمت قدیمی. اگر تصاویر با فرمت JPEG یا PNG بارگذاری شوند، حجم آن‌ها چند برابر WebP یا AVIF است. راه‌حل: تبدیل به WebP با افزونه‌های بهینه‌سازی.

اشتباه ششم: نبود Picture Element برای Art Direction. اگر تصویر در دسکتاپ و موبایل ساختار متفاوتی دارد، باید از <picture> استفاده شود.

اشتباه هفتم: نادیده گرفتن DPR. اگر تصویر برای دستگاه‌های Retina بهینه نشود، در این دستگاه‌ها محو به نظر می‌رسد.

اشتباه هشتم: تولید نکردن اندازه‌های کافی. اگر فقط اندازه‌های پیش‌فرض وردپرس (Thumbnail، Medium، Large) تولید شوند، ممکن است برای برخی Viewportها اندازه مناسبی وجود نداشته باشد.

پرسش‌های پرتکرار درباره Responsive Images

Responsive Images چیست و چرا ضروری است؟

Responsive Images مجموعه‌ای از تکنیک‌هاست که به مرورگر اجازه می‌دهد تصویر مناسب هر دستگاه را از میان چند نسخه انتخاب کند. ضروری است چون مصرف پهنای باند را تا ۷۰٪ کاهش می‌دهد، LCP را بهبود می‌بخشد، و تجربه کاربران موبایل را متحول می‌کند.

چگونه Responsive Images را در وردپرس فعال کنم؟

وردپرس از نسخه ۴.۴ به‌طور خودکار Responsive Images را برای تصاویر شاخص و تصاویر درون محتوا فعال می‌کند. برای بلاک‌های سفارشی، باید از wp_get_attachment_image() استفاده کنید. برای تصاویر با تگ <img> ساده، باید srcset و sizes را دستی تعریف نمایید.

تفاوت srcset و sizes چیست؟

srcset لیست نسخه‌های تصویر را تعریف می‌کند (با Width Descriptor یا Pixel Density Descriptor). sizes اندازه نمایش تصویر در Viewportهای مختلف را توصیف می‌نماید. مرورگر این دو را ترکیب می‌کند تا مناسب‌ترین تصویر را انتخاب کند.

آیا Responsive Images بر سرعت سایت تأثیر دارد؟

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

Picture Element چه تفاوتی با srcset دارد؟

srcset برای انتخاب تصویر مناسب بر پایه اندازه Viewport استفاده می‌شود. <picture> برای Art Direction (نمایش تصاویر مختلف در Viewportهای مختلف) و انتخاب فرمت (WebP، AVIF) استفاده می‌شود.

آیا Lazy Loading برای همه تصاویر مناسب است؟

خیر. تصویر LCP (معمولاً تصویر Hero یا تصویر شاخص) نباید Lazy Load شود چون LCP را افزایش می‌دهد. برای این تصویر، از loading="eager" و fetchpriority="high" استفاده کنید.

چگونه width و height را برای Responsive Images تعریف کنم؟

از wp_get_attachment_image() استفاده کنید که به‌طور خودکار width و height را اضافه می‌کند. برای HTML سفارشی، ابعاد را دستی تعریف نمایید. این کار از CLS جلوگیری می‌کند.

آیا AVIF بهتر از WebP است؟

AVIF حجم کمتری دارد (۵۰-۷۰٪ کمتر از JPEG) اما پشتیبانی مرورگرها هنوز کامل نیست. توصیه می‌شود از <picture> با Fallback استفاده کنید: اول AVIF، بعد WebP، و در نهایت JPEG.

آیا Responsive Images با SEO ارتباط دارد؟

بله، به‌طور مثبت. Responsive Images LCP و CLS را بهبود می‌دهد که هر دو بر Core Web Vitals اثر می‌گذارند. گوگل Core Web Vitals را به‌عنوان سیگنال رتبه‌بندی استفاده می‌کند. اگر با سئو تکنیکال و اهمیت آن آشنا شده باشید، این ارتباط را به‌عنوان یک مزیت دوگانه می‌شناسید.

چگونه Responsive Images را در بلاک سفارشی پیاده‌سازی کنم؟

اگر بلاک داینامیک است، از wp_get_attachment_image() در render_callback استفاده کنید. اگر بلاک استاتیک است، باید srcset و sizes را در save.js تولید کنید. اگر با ساخت بلاک سفارشی گوتنبرگ از صفر آشنا شده باشید، این الگو برای شما آشناست.

نگاه معمارانه سطح ارشد

از منظر معماری نرم‌افزار، Responsive Images یک نمونه از Adaptive Content Delivery است: به‌جای ارسال یک نسخه واحد برای همه، محتوا بر پایه ویژگی‌های دستگاه کاربر انتخاب و ارسال می‌شود. این رویکرد، در معماری‌های مدرن وب به یک اصل تبدیل شده: از Responsive Web Design تا Adaptive Loading و Progressive Enhancement.

چالش اصلی در Responsive Images، انتخاب درست در مرز ابهام است. مرورگر باید بر پایه اطلاعات ناقص (srcset و sizes) تصمیم بگیرد. اگر این اطلاعات دقیق نباشند، انتخاب نادرست رخ می‌دهد: تصویر بزرگ‌تر از نیاز (هدر رفتن پهنای باند) یا کوچک‌تر از نیاز (افت کیفیت). راه‌حل، تعریف دقیق sizes بر پایه Layout واقعی است.

چالش دوم، Sync بین Breakpointها و sizes است. اگر Breakpointهای CSS تغییر کنند اما sizes به‌روزرسانی نشود، انتخاب تصویر نادرست می‌شود. راه‌حل، استفاده از یک سیستم Design Token مشترک بین CSS و WordPress است. اگر با چرا قالب‌های بلاکی آینده وردپرس هستند آشنا شده باشید، می‌دانید که theme.json می‌تواند این Sync را فراهم کند.

چالش سوم، Observability است: چگونه می‌توان فهمید که مرورگر چه تصویری را انتخاب کرده است؟ ابزارهایی مثل WebPageTest و Chrome DevTools داده‌های انتخاب تصویر را نمایش می‌دهند. اگر با Real User Monitoring و اهمیت آن آشنا شده باشید، می‌دانید که این داده‌ها بخشی از استراتژی بهینه‌سازی مستمر هستند.

چالش چهارم، Cost Attribution است: کدام تصویر بیشترین سهم را در مصرف پهنای باند دارد؟ برای پاسخ به این سؤال، باید داده‌های CDN را با داده‌های RUM ترکیب کرد. اگر با CDN در وردپرس و نحوه انتخاب و پیکربندی آشنا شده باشید، می‌دانید که این تحلیل، بخشی از بهینه‌سازی مستمر است.

در نهایت، Responsive Images یک Engineering Discipline است: نیازمند توجه به جزئیات، درک عمیق از رفتار مرورگر، و تست مستمر. تیم‌هایی که این انضباط را در فرهنگ خود نهادینه می‌کنند، محصولاتی می‌سازند که در تمام دستگاه‌ها سریع و کارآمد هستند. تیم‌هایی که آن را نادیده می‌گیرند، با بدهی فنی سنگینی مواجه می‌شوند که رفع آن چند برابر هزینه دارد. اگر با Performance Budget در وردپرس و ضرورت آن آشنا شده باشید، می‌دانید که Responsive Images بخشی از این بودجه است.

اگر این تجربه را در یک پروژه واقعی داشته‌اید، جالب است بدانید کدام تکنیک Responsive Images بیشترین تأثیر را بر عملکرد سایت شما داشت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🖼️