طراحی ریسپانسیو چیست؟ آموزش CSS، سایزها و استانداردهای ۲۰۲۶

طراحی ریسپانسیو (Responsive Web Design یا RWD) یعنی یک وب‌سایت در اندازه‌های مختلف صفحه، از موبایل باریک تا نمایشگر دسکتاپ، بدون از دست دادن محتوا و امکانات قابل استفاده باشد. این کار فقط با کوچک‌کردن فونت و تصویر انجام نمی‌شود؛ چیدمان، ناوبری، فرم، جدول، خوانایی، لمس و عملکرد سایت هم باید با فضای موجود سازگار شوند.

طراحی ریسپانسیو دقیقاً چیست و چه فرقی با سایت موبایلی دارد؟

در طراحی واکنش‌گرا معمولاً یک HTML و یک URL داریم، اما CSS بسته به فضای موجود، تعداد ستون‌ها، فاصله‌ها و چیدمان عناصر را تغییر می‌دهد. در طراحی Adaptive معمولاً چند چیدمان ازپیش‌تعریف‌شده برای گروه‌های خاصی از عرض یا دستگاه آماده می‌شود. Responsive انعطاف بیشتری میان اندازه‌ها دارد؛ Adaptive در بعضی پروژه‌ها برای کنترل دقیق چند حالت مشخص مناسب است. این دو رویکرد می‌توانند در یک محصول ترکیب شوند.

گوگل طراحی واکنش‌گرا را برای مدیریت آسان‌تر نسخه موبایل توصیه می‌کند؛ چون محتوا در همان URL و با HTML یکسان ارائه می‌شود.

سایزهای ریسپانسیو سایت در ۲۰۲۶؛ کدام عرض‌ها را طراحی و تست کنیم؟

Breakpoint به عرضی گفته می‌شود که در آن چیدمان برای حفظ خوانایی یا عملکرد تغییر می‌کند. برخلاف فهرست ابعاد گوشی‌ها، هیچ استاندارد جهانی وجود ندارد که همه سایت‌ها الزاماً در ۷۶۸ یا ۱۰۲۴ پیکسل تغییر حالت بدهند. جدول زیر یک ماتریس پیشنهادی طراحی و تست است، نه فهرست اندازه‌های رسمی W3C.

عرض Viewport براساس CSS pixel محاسبه می‌شود، نه تعداد پیکسل فیزیکی نمایشگر. گوشی با رزولوشن سخت‌افزاری بالا ممکن است Viewport نسبتاً باریکی داشته باشد. در DevTools باید عرض CSS را مشاهده کنید، نه صرفاً مدل دستگاه را.

Breakpoint را بر اساس محتوا انتخاب کنید، نه مدل گوشی

مثلاً اگر یک کارت محصول با تصویر، عنوان و قیمت در عرض ۶۳۰ پیکسل دیگر فضای مناسب ندارد، تغییر تعداد ستون‌ها در همان محدوده منطقی است؛ حتی اگر آن عدد در فهرست breakpoint یک فریم‌ورک نباشد. راهنمای MDN درباره طراحی ریسپانسیو نیز روی تغییر چیدمان متناسب با فضای واقعی تأکید دارد.

Mobile-First را با یک مثال واقعی CSS اجرا کنیم

در روش Mobile-First، چیدمان پایه برای فضای محدود و بدون وابستگی به media query نوشته می‌شود؛ سپس برای صفحه‌های عریض‌تر ویژگی‌هایی اضافه می‌کنیم. ابتدا مطمئن شوید تگ viewport در head وجود دارد:

<meta name="viewport" content="width=device-width, initial-scale=1">

کد زیر یک صفحه محتوا با سایدبار است که در موبایل تک‌ستونی و از عرض مناسب به بعد دو‌ستونی می‌شود:

.page-layout {
  width: min(100% - 2rem, 75rem);
  margin-inline: auto;
  display: grid;
  gap: 1.5rem;
  grid-template-columns: minmax(0, 1fr);
}
@media (min-width: 64rem) {
  .page-layout {
    grid-template-columns: minmax(0, 1fr) 17rem;
  }
}

استفاده از minmax(0, 1fr) کمک می‌کند محتوای داخلی، ستون را بی‌دلیل از عرض مجاز بزرگ‌تر نکند. بااین‌حال جدول یا کد بلند باید اسکرول افقی محلی داشته باشد.

ساخت گرید محصولات بدون breakpointهای متعدد

برای لیست محصول فروشگاهی، Grid همراه با auto-fit و minmax() اغلب از تعریف دستی ستون برای تمام گوشی‌ها ساده‌تر است:

.product-grid {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: clamp(.75rem, 2vw, 1.5rem);
}
.product-card img {
  display: block;
  width: 100%;
  aspect-ratio: 4 / 5;
  object-fit: cover;
}
.product-card { min-width: 0; }

در این مثال، وقتی فضای کافی وجود داشته باشد ستون جدید اضافه می‌شود و وقتی فضا کم شود تعداد ستون‌ها کاهش می‌یابد. بخش min(100%, 16rem) جلوی بیرون‌زدن حداقل عرض کارت از کانتینر باریک را می‌گیرد. در فروشگاه واقعی، نسبت تصویر را متناسب با نوع محصولات و نیاز نمایش جزئیات انتخاب کنید.

Container Queries؛ وقتی اندازه کامپوننت مهم‌تر از کل صفحه است

ممکن است یک کارت پیشنهاد ویژه در محتوای اصلی عریض و در سایدبار باریک نمایش داده شود، درحالی‌که عرض پنجره مرورگر ثابت است. Media Query عرض viewport را می‌سنجد؛ Container Query می‌تواند براساس عرض کانتینر نزدیک‌تر رفتار کامپوننت را تنظیم کند:

.offer-container { container-type: inline-size; }
.offer-card { display: grid; gap: 1rem; }
@container (min-width: 30rem) {
  .offer-card { grid-template-columns: 9rem minmax(0, 1fr); }
}

این ویژگی برای اجزای قابل استفاده مجدد در المنتور، صفحه محصول و داشبورد کاربرد دارد. شرط مهم آن است که کانتینر موردنظر به‌درستی با container-type تعریف شده باشد.

فونت، تصاویر و ارتفاع صفحه در طراحی ریسپانسیو

تایپوگرافی منعطف با clamp()

.article-title {
  font-size: clamp(1.5rem, 1rem + 2vw, 2.75rem);
  line-height: 1.35;
}
.article-body { max-width: 70ch; }

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

تصاویر Responsive با srcset و sizes

<img
  src="/images/product-800.webp"
  srcset="/images/product-400.webp 400w,
          /images/product-800.webp 800w,
          /images/product-1200.webp 1200w"
  sizes="(min-width: 64rem) 33vw,
         (min-width: 40rem) 50vw, 100vw"
  width="800" height="1000"
  alt="نمای محصول از روبه‌رو">

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

vh، dvh و ارتفاع صفحه موبایل

نوار آدرس و کنترل‌های مرورگر موبایل ارتفاع ناحیه قابل مشاهده را تغییر می‌دهند. واحد dvh برای بعضی بخش‌های تمام‌قد مفید است، اما برای فرم‌ها و محتوای طولانی نباید ارتفاع ثابت و محدودکننده تعیین کرد.

.hero {
  min-height: 100svh;
  min-height: 100dvh;
}

استانداردهای WCAG 2.2 در نسخه موبایل

واکنش‌گرایی واقعی فقط ظاهر مناسب نیست؛ سایت باید با بزرگ‌نمایی، لمس، کیبورد و فناوری‌های کمکی هم قابل استفاده بماند. معیار Reflow در WCAG 2.2 برای محتوای عمودی، نمایش در عرض معادل ۳۲۰ CSS px را بدون نیاز به اسکرول دوبعدیِ کل صفحه می‌سنجد؛ البته برای داده‌هایی مانند جدول‌های واقعی استثنا وجود دارد.

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

ریسپانسیو بودن چه ارتباطی با سئو و Core Web Vitals دارد؟

گوگل در Mobile-First Indexing از نسخه محتوای قابل دسترس برای خزنده موبایل برای ایندکس و رتبه‌بندی استفاده می‌کند. بنابراین اگر محتوای اصلی، لینک‌های مهم یا اطلاعات ساختاریافته فقط در نسخه دسکتاپ وجود داشته باشند، مشکل ایجاد می‌شود. اما داشتن CSS واکنش‌گرا به‌تنهایی به معنای سرعت یا رتبه بهتر نیست.

• LCP: سرعت نمایش بزرگ‌ترین محتوای اصلیِ قابل مشاهده؛ تصاویر هیرو و فونت‌ها می‌توانند بر آن اثر بگذارند.
• CLS: جابه‌جایی ناخواسته اجزا هنگام بارگذاری؛ ابعاد تصاویر و فضای عناصر پویا اهمیت دارد.
• INP: پاسخ‌گویی رابط به تعامل کاربر؛ JavaScript سنگین یا رویدادهای کند می‌توانند آن را بدتر کنند.

برای بررسی عملکرد از PageSpeed Insights و برای توضیح روش اندازه‌گیری از مستندات web.dev درباره Core Web Vitals استفاده کنید. نتیجه آزمایشگاهی را با داده کاربران واقعی اشتباه نگیرید.

روش تست طراحی ریسپانسیو؛ از DevTools تا دستگاه واقعی

1. صفحه را در Chrome باز کنید و با DevTools وارد حالت Device Toolbar شوید.
2. عرض Viewport را روی ۳۲۰، ۳۶۰، ۳۹۰، ۴۳۰، ۷۶۸، ۱۰۲۴، ۱۲۸۰ و ۱۴۴۰ CSS px امتحان کنید؛ این اعداد ماتریس تست پیشنهادی‌اند.
3. در هر عرض، صفحه را از بالای هدر تا فوتر بررسی کنید؛ باز شدن منو، فرم، مودال، جدول قیمت و سبد خرید را تست کنید.
4. صفحه را در بزرگ‌نمایی ۲۰۰٪ و ۴۰۰٪، با کیبورد و در صورت امکان روی دستگاه واقعی بررسی کنید.
5. به جای پنهان‌کردن اسکرول افقی با overflow-x: hidden، علت بیرون‌زدگی را پیدا و برطرف کنید.
6. در پایان، از PageSpeed Insights برای سنجش تجربه بارگذاری و تعامل استفاده کنید.

ابزار قدیمی Mobile-Friendly Test که در بعضی آموزش‌ها معرفی شده، دیگر مسیر اصلی تست سایت نیست. با شبیه‌سازی دستگاه در DevTools و بررسی واقعی عملکرد رابط، جزئیات بیشتری قابل تشخیص است.

خطاهای رایج در سایت‌های وردپرسی و فروشگاهی

• عرض ثابت: عنصر با width: 1200px می‌تواند از صفحه موبایل بیرون بزند؛ به جای آن از عرض منعطف و max-width استفاده کنید.
• جدول‌های عریض: جدول مقایسه یا قیمت باید در ظرف خودش اسکرول داشته باشد، نه اینکه تمام صفحه را عریض کند.
• فیلتر محصولات: در موبایل بهتر است دسترسی به فیلتر و مرتب‌سازی روشن بماند و کنترل‌ها از دسترس خارج نشوند.
• تصویر نامتناسب: تغییر ابعاد تصویر بدون حفظ نسبت یا برش نادرست می‌تواند جزئیات مهم کالا را پنهان کند.
• پاپ‌آپ و نوار چسبان: نباید دکمه خرید، بخش اصلی محتوا یا امکان بستن پنجره را بپوشانند.
• نسخه موبایل ناقص: حذف توضیحات مهم محصول، لینک‌های داخلی یا اطلاعات ساختاریافته فقط برای کوتاه کردن صفحه تصمیم مناسبی نیست.

آیا AMP هنوز لازم است؟

AMP یک فناوری جدا برای ساخت صفحات وب است و شرط طراحی واکنش‌گرا، رتبه گرفتن یا نمایش سایت در موبایل نیست. برای بیشتر پروژه‌های شرکتی و فروشگاهی، HTML معنایی، CSS مدرن و بهینه‌سازی عملکرد مسیر مستقیم‌تر و قابل نگهداری‌تری است.

پرسش‌های متداول طراحی ریسپانسیو

منابع معتبر

• MDN — Responsive web design
• MDN — Container queries
• W3C — WCAG 2.2
• Google — Mobile-first indexing
• web.dev — Core Web Vitals

جایگزین Google Mobile-Friendly Test؛ چگونه سازگاری موبایل را بررسی کنیم؟

ابزار قدیمی Google Mobile-Friendly Test و API آن در دسامبر ۲۰۲۳ بازنشسته شدند؛ بنابراین آموزش ورود به آن ابزار دیگر قابل اجرا نیست. این تغییر به معنی بی‌اهمیت‌شدن تجربه موبایل نیست. برای ارزیابی امروزی از Chrome DevTools در حالت دستگاه‌های مختلف، Lighthouse و آزمایش روی گوشی واقعی استفاده کنید. اندازه متن و کنترل‌ها، اسکرول افقی ناخواسته، فرم‌ها، منو و جابه‌جایی چیدمان را جداگانه بررسی کنید. معیارهای Core Web Vitals در PageSpeed Insights نیز به سنجش بخشی از تجربه واقعی کمک می‌کنند، ولی جایگزین کامل تست کاربردپذیری موبایل نیستند. منبع رسمی گوگل درباره بازنشستگی Mobile-Friendly Test.

بهینه‌سازی کاربردپذیری نسخه موبایل

ریسپانسیو بودن تنها تغییر عرض ستون‌ها نیست. فرم‌ها، فیلترها، نوار ناوبری، عملکرد دکمه‌ها و پرداخت باید با لمس و کیبورد مجازی کار کنند. Popup مزاحم، محتوای خارج از قاب و هدف لمسی کوچک مشکل ایجاد می‌کنند. عملکرد نسخه موبایل را با داده واقعی کاربران و سناریوهای خرید یا تماس بررسی کنید؛ طراحی «mobile-first» به‌تنهایی تضمین سرعت نیست.

برای کنترل تجربه موبایل Core Web Vitals شامل LCP، INP و CLS و برای دسترس‌پذیری WCAG مرجع است. راهنمای Core Web Vitals و W3C.