یک صفحه را در عرض ۳۹۰ پیکسل باز می‌کنید؛ ستون‌ها زیر هم می‌آیند و منوی همبرگری ظاهر می‌شود. ظاهراً «ریسپانسیو» است. اما با بازشدن صفحه‌کلید، دکمه پرداخت ناپدید می‌شود؛ در زوم ۲۰۰٪ متن روی قیمت می‌افتد؛ کاربر کیبورد داخل منو گیر می‌کند؛ و تصویر ۲ مگابایتی دسکتاپ همچنان روی اینترنت موبایل دانلود می‌شود. تغییر چیدمان لازم است، اما کافی نیست.
طراحی ریسپانسیو یعنی حفظ معنا، اولویت و امکان انجام کار در شرایط متفاوتِ Viewport، Container، Zoom، Input، Orientation، Locale، Content، Network و State. واحد موفقیت «اسکرین‌شات بی‌نقص» نیست؛ کاربری است که بتواند با دستگاه و محدودیت خودش مسیر اصلی را کامل کند.
خلاصه اجرایی: HTML معنایی و ترتیب Source را درست بچینید؛ Layout را با Grid/Flex و واحدهای منعطف بسازید؛ Breakpoint را هنگام شکست محتوا اضافه کنید؛ Component را با Container query مستقل کنید؛ تصویر را با srcset/sizes و ابعاد ذاتی تحویل دهید؛ Reflow، Zoom، Keyboard، Touch، RTL، شبکه و حالت‌های خطا را تست کنید؛ و کیفیت را با Acceptance matrix و داده Field کنترل کنید.
طراحی ریسپانسیو چیست؟
Responsive Web Design یک محصول یا فناوری جدا نیست؛ رویکردی برای طراحی و پیاده‌سازی وب است تا محتوا و تعامل در اندازه‌ها، رزولوشن‌ها و روش‌های ورودی مختلف قابل‌استفاده بمانند. راهنمای رسمی MDN درباره Responsive design سه پایه تاریخی Fluid grid، Fluid media و Media query را توضیح می‌دهد؛ ابزارهای امروز مانند Grid، Flexbox، min()/max()/clamp() و Container query این مدل را Componentمحورتر کرده‌اند.
«قابل‌استفاده ماندن» را به قراردادهای قابل‌آزمون تبدیل کنید:
| بُعد | تغییر نمونه | قرارداد |
|---|---|---|
| Viewport | موبایل باریک تا مانیتور عریض | بدون Overflow ناخواسته و با اولویت روشن |
| Container | یک Card در Main، Sidebar یا Modal | Component براساس فضای خودش سازگار شود |
| Zoom/Text | بزرگ‌نمایی یا فونت کاربر | محتوا Reflow کند و Action گم نشود |
| Input | Touch، Mouse، Keyboard یا Stylus | Hover تنها راه کشف و Drag تنها راه عمل نباشد |
| Orientation | Portrait و Landscape | کار بدون قفل‌کردن جهت ادامه یابد، مگر ضروری |
| Locale | فارسی RTL، متن انگلیسی، ارقام و قیمت | ترتیب بصری و خواندن معنایی درست بماند |
| Content | عنوان بلند، خطا، داده خالی یا زیاد | Layout فقط با محتوای نمونه کوتاه کار نکند |
| Network/Device | شبکه ناپایدار و گوشی اقتصادی | مسیر اصلی با Payload و JS کنترل‌شده کار کند |
| State | Loading، Empty، Error، Offline و Success | هر State پیام و Recovery قابل‌دسترس داشته باشد |
Responsive، Adaptive و سایت موبایل جدا چه تفاوتی دارند؟
| الگو | رفتار | مزیت | ریسک |
|---|---|---|---|
| Responsive | معمولاً یک URL و HTML، Layout منعطف | Parity و نگهداری ساده‌تر | اگر فقط CSS باشد، Payload پنهان ممکن است دانلود شود |
| Adaptive | چند Layout ازپیش‌تعریف‌شده | کنترل دقیق برای Context محدود | شکاف در عرض‌های بین Layoutها و نگهداری چند نسخه |
| Dynamic serving | یک URL، HTML متفاوت بر اساس User-Agent | تحویل Context-specific | تشخیص اشتباه، Cache و Parity پیچیده |
| Separate mobile URL | URL یا Subdomain جدا | جداسازی Legacy | Redirect، Canonical/Alternate، محتوا و عملیات مضاعف |
برای پروژه تازه، Responsive اغلب نقطه شروع کم‌اصطکاک‌تری است؛ ولی نسخه جدا را نباید فقط با شعار رد کرد. سیستم Legacy، دستگاه صنعتی یا جریان کاملاً متفاوت ممکن است محدودیت خاص داشته باشد. تصمیم را با Parity، هزینه نگهداری، Cache، Analytics، SEO، دسترس‌پذیری و برنامه خروج بگیرید. مقاله موبایل‌فرندلی، سئو موبایل و تست UX لایه گسترده‌تر Mobile readiness را پوشش می‌دهد؛ این راهنما بر قرارداد طراحی و پیاده‌سازی Responsive تمرکز دارد.
پیش از CSS، قرارداد Responsive را بنویسید
اگر Designer فقط سه Frame برای موبایل، تبلت و دسکتاپ تحویل دهد، Developer باید رفتار بین آن‌ها و تمام Stateها را حدس بزند. یک Responsive contract برای هر Component بسازید:
| فیلد | پرسش | نمونه Card محصول |
|---|---|---|
| Purpose | کار اصلی چیست؟ | مقایسه سریع و افزودن محصول |
| Content priority | چه چیزی همیشه باید بماند؟ | نام، قیمت نهایی، وضعیت موجودی و CTA |
| Intrinsic limits | کمینه/بیشینه محتوا چیست؟ | نام یک تا چهار خط، تخفیف صفر یا زیاد |
| Container states | در چه فضای داخلی تغییر می‌کند؟ | Compact زیر 22rem، Horizontal بالاتر |
| Interaction | Touch/Keyboard/Pointer چه می‌کند؟ | CTA واقعی، Focus visible، بدون Hover-only |
| System states | Loading/Error/Unavailable چطور است؟ | Skeleton پایدار، پیام و اقدام جایگزین |
| Content stress | چه داده‌ای Layout را می‌شکند؟ | تومان/ریال، عنوان فارسی-لاتین و Badgeهای متعدد |
| Acceptance | چه شاهدی قبولی را ثابت می‌کند؟ | Zoom، RTL، Keyboard، شبکه و Screenshot diff |
Content priority به معنی حذف بی‌دلیل محتوا در موبایل نیست. گاهی Disclosure تدریجی مناسب است، اما اطلاعات حیاتی، شرط قیمت، خطا، نام کنترل و لینک‌های لازم باید برای کاربر و فناوری کمکی در دسترس بمانند. Visual order را نیز با CSS از Source order جدا نکنید اگر ترتیب خواندن و Focus معنادار عوض می‌شود.
پایه HTML: معنایی، Mobile-first و مقاوم
Viewport را درست اعلام کنید
در <head> سند معمولاً این خط لازم است:
<meta name="viewport" content="width=device-width, initial-scale=1">این تنظیم به مرورگر موبایل می‌گوید عرض واقعی Device را مبنای Layout بگیرد. از user-scalable=no یا maximum-scale=1 برای مهار Zoom استفاده نکنید؛ این کار می‌تواند ابزار ضروری کاربران کم‌بینا را محدود کند.
Source order را قبل از Grid مشخص کنید
HTML باید بدون CSS نیز ترتیب منطقی داشته باشد: Heading، توضیح، کنترل و نتیجه. ویژگی‌های order در Flex/Grid فقط ظاهر را جابه‌جا می‌کنند و الزاماً ترتیب DOM، Screen reader یا Tab را تغییر نمی‌دهند. اگر موبایل و دسکتاپ به ترتیبهای معنایی متناقض نیاز دارند، معماری محتوا را بازنگری کنید؛ با عددهای order مسئله را پنهان نکنید.
Progressive enhancement بسازید
جریان اصلی باید با HTML و کنترل‌های Native قابل‌فهم باشد؛ CSS تجربه را Layout و JavaScript رفتار را غنی کند. برای Feature تازه، Baseline مرورگرهای واقعی خود را بررسی و Fallback تعیین کنید. Responsive بودن نباید به اجرای کامل یک Bundle بزرگ JavaScript وابسته باشد.
Layout منعطف با Grid، Flex و واحدهای نسبی
یک Layout خوب تا حد ممکن «ذاتی» پاسخ‌گو است و برای هر عرض به Media query جدا نیاز ندارد:
.cards {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
gap: clamp(0.75rem, 2vw, 1.5rem);
}
.page-shell {
inline-size: min(100% - 2rem, 75rem);
margin-inline: auto;
}inline-size و margin-inline از Logical propertyها هستند و با جهت نوشتار سازگارتر از width، margin-left و margin-right عمل می‌کنند. minmax() و auto-fit نیز اجازه می‌دهند تعداد ستون‌ها از فضای واقعی و حداقل قابل‌خواندن Card بیاید.
| ابزار | کاربرد مناسب | خطای رایج |
|---|---|---|
| Flexbox | محور اصلی؛ Toolbar، گروه CTA و Item | جلوگیری از Wrap و فشرده‌شدن متن |
| Grid | ردیف و ستون؛ Page و Card collection | ستون Fixed بدون minmax(0, 1fr) |
rem/em | مقیاس متأثر از فونت و Component | ترکیب بی‌قاعده با px و شکستن Zoom |
clamp() | فاصله و تایپوگرافی سیال با حد | مقدار میانی تهاجمی و عنوان بسیار بزرگ |
| Logical properties | RTL/LTR و Writing mode | Override فراوان برای left/right |
برای Childهای Grid/Flex که متن بلند دارند، گاهی min-inline-size: 0 لازم است؛ وگرنه مقدار min-width: auto اجازه کوچک‌شدن را نمی‌دهد و Overflow می‌سازد. URL، SKU یا رشته بدون فاصله را با overflow-wrap: anywhere مدیریت کنید؛ برش یا سه‌نقطه فقط وقتی مجاز است که متن کامل راه دسترسی داشته باشد.
Breakpoint را از شکست محتوا پیدا کنید
Breakpoint نام یک مدل گوشی نیست. صفحه را از باریک به عریض حرکت دهید و نقطه‌ای را ثبت کنید که Constraint واقعی نقض می‌شود: طول خط، فضای هدف لمسی، تراکم ناوبری، هم‌پوشانی، Overflow یا ازبین‌رفتن سلسله‌مراتب. سپس کمترین Rule لازم را اضافه کنید. راهنمای Media query در MDN نیز انتخاب Breakpoint براساس نیاز محتوا و رویکرد Mobile-first را توضیح می‌دهد.
.product-layout {
display: grid;
gap: 1rem;
}
@media (width >= 48rem) {
.product-layout {
grid-template-columns: minmax(0, 1.4fr) minmax(18rem, 0.6fr);
align-items: start;
}
}استفاده از em یا rem برای Breakpoint می‌تواند رفتار را با مقیاس متن هماهنگ‌تر کند. اعداد استاندارد تیم را به‌عنوان Token نگه دارید، اما هر Component را مجبور نکنید فقط در همان اعداد بشکند. عرض‌های دقیق Breakpoint را در −1، خود نقطه و +1 تست کنید تا Gap یا Rule متناقض آشکار شود.
Media query فقط برای Width نیست
ویژگی‌های محیط و ترجیح کاربر نیز مهم‌اند:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
scroll-behavior: auto;
animation-duration: 0.01ms;
animation-iteration-count: 1;
}
}
@media (hover: hover) and (pointer: fine) {
.card:hover { /* enhancement; not the only way to reveal content */ }
}
@media (forced-colors: active) {
.status-icon { forced-color-adjust: auto; }
}hover: none را معادل «موبایل» و pointer: coarse را معادل یک دستگاه ثابت ندانید؛ دستگاه ترکیبی ممکن است چند ورودی داشته باشد. Capability را برای Enhancement استفاده کنید، نه برای حذف مسیر پایه.
Container query: Component به جای صفحه پاسخ می‌دهد
Media query فضای Viewport را می‌سنجد؛ اما Card ممکن است در Viewport عریض داخل Sidebar باریک باشد. Container query رفتار را به فضای واقعی والد متصل می‌کند. مستند MDN برای Container query نحوه تعریف Containment و Query اندازه Container را شرح می‌دهد.
.product-card-shell {
container: product-card / inline-size;
}
.product-card {
display: grid;
gap: 0.75rem;
}
@container product-card (inline-size >= 30rem) {
.product-card {
grid-template-columns: 10rem minmax(0, 1fr);
}
}Container را در Design system به Contract Component وصل کنید: Variantها، حداقل فضای محتوا و Acceptance. برای محیط‌های خارج Browser matrix، Fallback تک‌ستونه امن بدهید و با @supports Enhancement را لایه‌گذاری کنید. Queryهای متعدد و تصادفی می‌توانند Component را غیرقابل‌پیش‌بینی کنند؛ نام، هدف و Owner هر Threshold را مستند کنید.
Viewport height، نوار مرورگر و صفحه‌کلید موبایل
100vh همیشه برابر فضای قابل‌دید کاربر نیست؛ نوار آدرس، Navigation مرورگر و صفحه‌کلید نرم می‌توانند Viewport را تغییر دهند. واحدهای svh، lvh و dvh برای Small، Large و Dynamic viewport ساخته شده‌اند، اما استفاده باید با نیاز و Browser matrix هماهنگ باشد.
.dialog-panel {
max-block-size: min(90dvh, 44rem);
overflow: auto;
padding-block-end: max(1rem, env(safe-area-inset-bottom));
}CTA ثابت پایین صفحه را با Keyboard واقعی تست کنید. وقتی فیلد Focus می‌گیرد، باید دیده شود، پیام خطا و دکمه قابل‌دسترسی بمانند و Sticky bar محتوای Focusشده را نپوشاند. برای Notch و Safe area نیز فقط روی شبیه‌ساز حساب نکنید.
تایپوگرافی Responsive و Reflow
فونت کوچک روی موبایل راه‌حل کمبود فضا نیست. اندازه پایه، Line-height، طول خط، فاصله پاراگراف و وزن فونت باید خواندن فارسی را پشتیبانی کنند. یک الگوی محتاطانه:
:root {
--step-0: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
--step-3: clamp(1.75rem, 1.3rem + 2vw, 3rem);
}
body {
font-size: var(--step-0);
line-height: 1.75;
}
h2 { font-size: var(--step-3); line-height: 1.25; }
p { max-inline-size: 70ch; }این اعداد Template نیستند؛ با فونت فارسی، وزن واقعی و محتوای طولانی تست شوند. معیار Reflow در WCAG برای محتوای معمول انتظار دارد در معادل عرض ۳۲۰ CSS pixel بدون اسکرول دوبعدی و از دست‌رفتن اطلاعات/کارکرد استفاده شود؛ محتوای ذاتاً دوبعدی مانند جدول داده استثناهای مشخص دارد. Zoom مرورگر ۴۰۰٪ و بزرگ‌کردن متن را جداگانه بررسی کنید.
تصویر و رسانه Responsive: فقط max-width کافی نیست
max-inline-size: 100% جلوی بیرون‌زدگی را می‌گیرد، اما یک تصویر بزرگ را ارزان‌تر نمی‌کند. برای Resolution switching از srcset و sizes و برای Art direction از <picture> استفاده کنید. راهنمای Responsive images در web.dev تفاوت انتخاب توصیفی مرورگر با انتخاب کنترل‌شده picture را توضیح می‌دهد.
<picture>
<source
media="(width < 40rem)"
srcset="team-portrait-480.avif 480w, team-portrait-768.avif 768w"
sizes="100vw">
<img
src="team-wide-1280.jpg"
srcset="team-wide-640.jpg 640w, team-wide-1280.jpg 1280w"
sizes="(width >= 75rem) 70rem, calc(100vw - 2rem)"
width="1280"
height="720"
alt="تیم پشتیبانی در حال بررسی داشبورد سفارش‌ها"
decoding="async">
</picture>راهنمای رسمی MDN برای تصاویر واکنش‌گرا نیز دو مسئله Resolution switching و Art direction را تفکیک می‌کند. نکات عملی:
sizesباید عرض واقعی Slot را توصیف کند؛100vwپیش‌فرض تنبلانه می‌تواند فایل بزرگ انتخاب کند.widthوheightیاaspect-ratioفضای تصویر را رزرو می‌کنند و از جابه‌جایی Layout می‌کاهند.- تصویر LCP را بی‌دلیل Lazy-load نکنید؛ تصاویر پایین صفحه می‌توانند
loading="lazy"داشته باشند. - Crop موبایل نباید موضوع یا متن ضروری تصویر را حذف کند و همه Sourceها باید معنای Alt یکسان را حفظ کنند.
- پنهان‌کردن تصویر دسکتاپ با CSS الزاماً مانع Download نمی‌شود؛ Network panel را بررسی کنید.
ویدئو، iframe و نسبت تصویر
.media-frame {
aspect-ratio: 16 / 9;
inline-size: 100%;
}
.media-frame iframe,
.media-frame video {
inline-size: 100%;
block-size: 100%;
}Embed ثالث ممکن است Layout را پاسخ‌گو ولی صفحه را کند و داده کاربر را به طرف ثالث ارسال کند. Facade، Consent، Lazy activation و Placeholder با ابعاد ثابت را ارزیابی کنید. Transcript یا Caption نیز بخشی از سازگاری محتواست، نه افزونه تزئینی.
ناوبری، Dialog و هدف لمسی
منوی همبرگری Responsive نیست اگر Label، Focus، Escape، بازگشت Focus و Screen reader state درست نباشد. از button واقعی با نام قابل‌فهم و aria-expanded استفاده کنید؛ منوی بازشده نباید کاربر کیبورد را پشت Overlay بفرستد. برای Dialog، رفتار Focus و Scroll lock را با Component آزموده‌شده پیاده کنید.
معیار Target Size (Minimum) در WCAG ۲.۲ حداقل ۲۴×۲۴ CSS pixel یا فاصله معادل را با استثناهای تعریف‌شده مطرح می‌کند. حداقل استاندارد را با «هدف راحت محصول» اشتباه نگیرید؛ CTA حیاتی روی Touch معمولاً فضای بیشتری لازم دارد. فاصله میان آیکون‌ها، Tap نزدیک لبه، Thumb reach و خطای لمس را با کاربر و دستگاه واقعی بسنجید.
| Component | Failure رایج | Acceptance نمونه |
|---|---|---|
| Navigation | Hover-only یا Submenu بدون Keyboard | Tab/Enter/Escape و بازگشت Focus |
| Sticky header | پوشاندن Anchor یا Focus | هدف پس از Jump کاملاً دیده شود |
| Carousel | Drag-only و حرکت اجباری | Button، نام، توقف و Reduced motion |
| Tooltip | فقط Hover و محتوای غیرقابل‌دسترسی | Focus/Touch و Dismiss بدون از دست‌رفتن |
| Bottom CTA | پوشاندن محتوا/Keyboard | Safe area، Zoom و Soft keyboard Pass |
برای ارزیابی عمیق‌تر Keyboard، Screen reader، Zoom و Componentها، از راهنمای ممیزی دسترس‌پذیری وب و WCAG ۲.۲ استفاده کنید. متن رسمی WCAG ۲.۲ نیز مرجع معیارهای Reflow، Orientation، Focus و Input است.
فرم Responsive روی موبایل
فرم فقط وقتی Responsive است که در حضور صفحه‌کلید، Autofill، خطا، Paste، متن بلند و شبکه ناپایدار قابل‌تکمیل بماند.
- Label دائمی را با Placeholder جایگزین نکنید.
typeرا برای معنا و Validation وinputmodeرا برای چیدمان صفحه‌کلید انتخاب کنید.autocompleteاستاندارد را برای نام، تلفن، ایمیل و آدرس فعال کنید.- خطا را نزدیک فیلد و در Summary قابل Focus بدهید؛ داده صحیح را حفظ کنید.
- دکمه Submit هنگام Keyboard و Zoom دیده و قابل‌لمس بماند.
- ارسال تکراری، Timeout و بازگشت از درگاه را Idempotent و Recoverable طراحی کنید.
برای ایران، شماره موبایل با +98، 09، فاصله یا رقم فارسی ممکن است وارد شود. Normalization را از پیام ظاهری جدا کنید و مقدار اصلی را بی‌دلیل از بین نبرید. OTP باید Paste/Autofill، شمارش معقول، Resend کنترل‌شده و خطای شبکه داشته باشد. مبلغ ریال/تومان، کد ملی، کد پستی و تاریخ را با داده واقعی و سیاست صریح اعتبارسنجی کنید.
جدول، نمودار، کد و محتوای عریض
برای جدول داده، یک پاسخ جهانی وجود ندارد:
| الگو | چه زمانی مناسب است؟ | احتیاط |
|---|---|---|
| Horizontal scroll | رابطه ستونی باید حفظ شود | ناحیه Scroll دارای Label، Focus و نشانه بصری باشد |
| Column priority | ستون‌های فرعی واقعاً اختیاری‌اند | داده حیاتی یا Header معنایی حذف نشود |
| Card transform | هر Row یک Entity مستقل است | Label هر Value در DOM واضح باشد |
| Summary + detail | موبایل به Overview و Drill-down نیاز دارد | مسیر Detail و State بازگشت حفظ شود |
نمودار باید Table یا Summary متنی داشته باشد و Tooltip فقط به Hover وابسته نباشد. Code block می‌تواند اسکرول افقی کنترل‌شده داشته باشد چون شکستن خط، معنا را عوض می‌کند. نقشه، Timeline و Canvas ذاتاً دوبعدی‌اند؛ جایگزین متنی یا List برای Task اصلی فراهم کنید.
Responsive فارسی و RTL
اضافه‌کردن direction: rtl پایان کار نیست. جهت سند را با dir="rtl" روی HTML یا Container معنایی اعلام و برای قطعات مستقل LTR از dir="ltr" یا <bdi> استفاده کنید. Logical propertyها هزینه Override را کم می‌کنند:
.notice {
border-inline-start: 0.25rem solid currentColor;
padding-inline: 1rem;
margin-block: 1rem;
}
.mixed-token {
direction: ltr;
unicode-bidi: isolate;
}این داده‌ها را در Content stress test بگذارید:
- عنوان فارسی طولانی و عنوان انگلیسی بدون فاصله؛
- شماره سفارش، Email، URL، کد رهگیری و نسخه نرم‌افزار؛
- مبلغ با ریال و تومان و جداکننده هزارگان؛
- تاریخ شمسی/میلادی و زمان تهران؛
- نام محصول فارسی همراه SKU لاتین؛
- پیام خطای چندخطی و ترجمه‌ای ۳۰ تا ۵۰ درصد بلندتر.
آیکون جهت‌دار مانند Back/Next باید با معنا و جهت Journey هماهنگ شود؛ لوگو، Play، Search و بسیاری از نمادها Mirror نمی‌شوند. ترتیب Grid بصری را با خواندن Screen reader و Tab مقایسه کنید.
Responsive مساوی سریع نیست
یک صفحه می‌تواند در موبایل زیبا باشد و همچنان CSS/JS/Image دسکتاپ را دانلود، Parse و اجرا کند. display: none هزینه Network و Main thread را به‌طور خودکار حذف نمی‌کند. Budget را برای هر Template و Journey تعریف کنید:
| بودجه | سؤال | شاهد |
|---|---|---|
| Bytes | در Mobile cold load چه حجمی می‌آید؟ | Network transfer به تفکیک Type/Third party |
| Requests | چند Origin و Connection لازم است؟ | Waterfall |
| Main thread | Interaction چقدر با JS رقابت می‌کند؟ | Long task و INP attribution |
| Image slot | Browser فایل متناسب انتخاب کرده؟ | CurrentSrc در Width/DPR مختلف |
| Stability | Card/Ad/Font فضای رزروشده دارند؟ | CLS و Visual inspection |
| Task | کاربر مسیر را در شبکه ضعیف کامل می‌کند؟ | Success/Failure/Retry و زمان End-to-end |
Lab برای Debug و Field/RUM برای تجربه واقعی‌اند. میانگین کل می‌تواند گوشی اقتصادی یا یک اپراتور را پنهان کند؛ داده را بر Device class، Network، Template و Release بخش‌بندی کنید. راهنمای سرعت سایت و Performance budget اولویت اقتصادی را توضیح می‌دهد و مقاله Core Web Vitals و RUM برای تشخیص LCP، INP و CLS عمیق‌تر است.
طراحی ریسپانسیو و سئو؛ رابطه واقعی چیست؟
Google می‌گوید محتوای نسخه موبایل را با Smartphone crawler برای Indexing و Ranking به کار می‌برد و Responsive design را به‌دلیل پیاده‌سازی و نگهداری ساده‌تر توصیه می‌کند. این توصیه در راهنمای رسمی Mobile-first indexing آمده است. اما Responsive بودن به‌تنهایی رتبه را تضمین نمی‌کند.
Parity موبایل را روی این موارد کنترل کنید
- محتوای اصلی، Headingها و لینک‌های داخلی؛
- Title، Meta description، Robots و Canonical؛
- Structured data و شناسه‌های Entity؛
- تصویر اصلی، Alt، Caption و Video metadata؛
- داده‌ای که فقط پس از Interaction کاربر Load می‌شود؛
- وضعیت HTTP، Lazy loading و قابلیت Crawl resourceها.
Accordion برای UX موبایل می‌تواند مناسب باشد و محتوای داخل DOM همچنان قابل‌دسترسی بماند؛ ولی حذف کامل محتوا یا Load فقط پس از Tap ممکن است Parity را بشکند. یک URL مشترک مدیریت Signalها را ساده می‌کند، اما کیفیت Content، Internal link، Rendering و Performance همچنان باید آزموده شوند. چک‌های انتشار و مهاجرت در چک‌لیست سئو طراحی سایت آمده‌اند.
ماتریس تست Responsive
فهرست مدل‌های گوشی پایان‌ناپذیر است. ماتریس را با Risk و داده واقعی بسازید:
| محور | نمونه پوشش | Failure هدف |
|---|---|---|
| Viewport | باریک‌ترین پشتیبانی‌شده، میان Breakpoint، عریض | Overflow، Gap، طول خط و فضای خالی |
| Browser/OS | سهم واقعی Analytics + یک Engine جایگزین | Feature/Font/Input ناسازگار |
| Device class | Android اقتصادی، میان‌رده و دسکتاپ | CPU/Memory و Touch واقعی |
| Input | Touch، Keyboard، Mouse و Screen reader | Hover/Drag-only، Focus و نام کنترل |
| Display | Portrait/Landscape، Zoom ۲۰۰/۴۰۰، Text size | Reflow، Crop و Focus obscured |
| Network | Fast، کند، Latency، Offline/retry | Skeleton، Timeout و Recovery |
| Locale | RTL، Mixed bidi، اعداد و متن بلند | ترتیب، Wrap و Truncation |
| State | Loading/Empty/Error/Partial/Success | Layout shift و اقدام گم‌شده |
سه لایه تست
- Static/automated: Lint، Screenshot در Widthهای خطر، Visual diff، Accessibility scan و Overflow detector.
- Interaction: Navigation، Form، Dialog، Search، Filter، Cart و Payment با Inputهای مختلف.
- Real-world: دستگاه واقعی، شبکه و WebViewهای پرتکرار، کاربر هدف و داده Production/RUM.
DevTools برای کشف سریع عالی است، اما Hardware، Keyboard، Browser chrome، Safe area، Font rendering، Memory و رفتار Touch را کامل شبیه‌سازی نمی‌کند. یافته باید URL/Component، Viewport، Browser، Input، State، مراحل بازتولید، Severity، Evidence و Expected behavior داشته باشد.
Acceptance criteria قابل‌خودکارسازی
| قرارداد | قبولی نمونه | روش |
|---|---|---|
| No accidental overflow | در Widthهای نمونه، scrollWidth ≤ clientWidth برای صفحه عادی | Browser test + استثناهای ثبت‌شده |
| Reflow | Zoom ۴۰۰٪ بدون از دست‌رفتن Task | Manual + Screenshot |
| Focus | ترتیب منطقی و Focus بدون پوشیدگی | Keyboard test |
| Touch | Target/Spacing مصوب و خطای لمس قابل‌قبول | Static check + دستگاه واقعی |
| Content stress | داده Min/Max/Mixed RTL بدون شکست | Story fixtures |
| Image | currentSrc با Slot/DPR منطقی و ابعاد رزرو | Network + DOM assertion |
| Performance | Budget Template در Lab و Guardrail Field | CI + RUM |
| SEO parity | Content/Metadata/Schema موبایل برابر قرارداد | Rendered crawl diff |
Visual snapshot را تنها Oracle نکنید؛ تغییر یک پیکسل لزوماً Failure نیست و Layout ظاهراً برابر می‌تواند از نظر Keyboard یا DOM شکسته باشد. Smoke test، Semantic assertion، Interaction و Human review را ترکیب کنید. برای تبدیل مشاهده به Task، Severity و تصمیم اصلاح، راهنمای اشتباهات رایج طراحی سایت و ممیزی UX مفید است؛ برای سنجش موفقیت Task با کاربران واقعی نیز راهنمای تست کاربردپذیری را ببینید.
عیب‌یابی Failureهای رایج
| نشانه | علت‌های محتمل | بررسی اول |
|---|---|---|
| اسکرول افقی کل صفحه | Fixed width، Grid min-content، Transform، URL بلند | عنصر فراتر از documentElement.clientWidth |
| عنوان از Card بیرون می‌زند | min-width:auto یا رشته بدون شکست | min-inline-size:0 و Content fixture |
| CTA با Keyboard گم می‌شود | 100vh، Sticky و Scroll lock | Visual viewport و Focus scroll |
| منو در Width میانی می‌شکند | Breakpoint دستگاه‌محور یا Label بلند | Content-driven threshold و Wrap policy |
| تصویر موبایل سنگین است | sizes غلط یا CSS hide | currentSrc و Network transfer |
| Tab با ظاهر هماهنگ نیست | CSS order یا DOM تکراری | Source order و Accessibility tree |
| CLS در Cardها | ابعاد تصویر/Ad/Font/Async state نامشخص | Reserved space و Field attribution |
| RTL فقط در یک Width خراب است | left/right override یا Absolute position | Logical property و Bidi fixture |
سایت قدیمی را اصلاح کنیم یا بازطراحی؟
ابتدا Inventory و نمونه‌گیری کنید؛ تصمیم Rebuild از چند Screenshot بد به دست نمی‌آید.
| وضعیت | مسیر محتمل | شرط |
|---|---|---|
| چند Component Fixed/Overflow | Refactor محدود CSS/HTML | Source order و Template سالم‌اند |
| Design token و Component پراکنده | بازسازی تدریجی Design system | Strangler pattern و Regression suite |
| DOM جداگانه موبایل/دسکتاپ | ادغام مرحله‌ای | Parity map و Analytics کنترل‌شده |
| CMS/Theme مانع Semantics و Performance | Replatform یا Rebuild | Business case، Migration و Rollback |
| فقط نمره ابزار پایین است | اول تشخیص | Field/Task evidence پیش از Scope بزرگ |
یک Template یا Journey پرارزش را Pilot کنید، Baseline بگیرید، تغییر را مرحله‌ای منتشر و Guardrail تعریف کنید. بازطراحی صفحه اصلی نیز باید پیام و مسیر را همراه Layout ببیند؛ مقاله طراحی صفحه اصلی سایت این قرارداد را پوشش می‌دهد.
برنامه اجرایی ۳۰ روزه
- روز ۱ تا ۵ — Baseline: Template/Journey/Component inventory، Analytics دستگاه و Browser، نمونه Failure و معیارهای تجاری را جمع کنید.
- روز ۶ تا ۱۰ — Contract: Content priority، Source order، State matrix، Container/Breakpoint و Browser support policy را بنویسید.
- روز ۱۱ تا ۱۵ — Foundation: Viewport، Token، Grid/Flex، Logical property، Typography و Media پایه را اصلاح کنید.
- روز ۱۶ تا ۲۰ — Critical paths: Navigation، Form، Search، Cart/Payment، Error و Loading را روی Width/Input/Network بسازید.
- روز ۲۱ تا ۲۵ — Quality: Reflow، WCAG، Responsive image، Performance، SEO parity، RTL/Bidi و دستگاه واقعی را تست کنید.
- روز ۲۶ تا ۳۰ — Release: Regression suite، Pilot، Monitoring، Owner، Rollback و Post-release review را فعال کنید.
چک‌لیست طراحی ریسپانسیو
- Responsive contract برای Viewport/Container/Input/Zoom/Locale/Network/State نوشته شده است.
- HTML معنایی و Source order بدون اتکا به CSS منطقی است.
- Viewport meta امکان Zoom کاربر را محدود نمی‌کند.
- Layout با Grid/Flex، واحد نسبی و Intrinsic sizing ساخته شده است.
- Breakpointها از شکست محتوا آمده‌اند و در مرز ±۱ تست شده‌اند.
- Componentهای قابل‌استفاده مجدد در Containerهای مختلف آزموده شده‌اند.
- Height، Keyboard، Safe area و Sticky element روی دستگاه واقعی بررسی شده‌اند.
- Zoom، Text size، Reflow و Orientation مسیر اصلی را نمی‌شکنند.
- Touch، Keyboard، Mouse، Screen reader و Reduced motion پوشش دارند.
- فرم Label، Autofill، Input mode، Error recovery و Submit پایدار دارد.
- تصویر
srcset/sizes، ابعاد ذاتی و Alt مناسب دارد. - جدول/نمودار/کد برای محتوای عریض Pattern و جایگزین دارند.
- RTL/Bidi، مبلغ، شماره، Email و متن بلند تست شده‌اند.
- Mobile HTML پنهان‌شده Payload اضافی و غیرضروری ندارد.
- Content، Metadata، Schema و Link موبایل Parity دارند.
- Visual، Semantic، Interaction، Device و RUM با هم استفاده می‌شوند.
- هر Failure Owner، Severity، Evidence و Acceptance دارد.
- Release دارای Performance/Accessibility guardrail و Rollback است.
پرسش‌های متداول
طراحی ریسپانسیو دقیقاً یعنی چه؟
یعنی Layout، محتوا و تعامل براساس فضای نمایش و شرایط کاربر سازگار شوند، بدون اینکه معنا یا امکان انجام کار از بین برود. پاسخ‌گویی فقط کوچک‌کردن نسخه دسکتاپ نیست و Zoom، Input، Orientation، RTL، Network و State را هم شامل می‌شود.
چند Breakpoint برای سایت لازم است؟
عدد جهانی وجود ندارد. با Layout سیال شروع کنید و هرجا محتوا، هدف لمسی یا سلسله‌مراتب شکست، Breakpoint اضافه کنید. Design tokenهای مشترک برای نظم مفیدند، اما نباید نیاز Component را نادیده بگیرند.
Media query بهتر است یا Container query؟
رقیب هم نیستند. Media query برای ویژگی‌های Viewport/Environment و Container query برای رفتار مستقل Component در فضای والد مناسب است. Layout صفحه می‌تواند Media query و Card داخل آن Container query داشته باشد.
آیا طراحی ریسپانسیو باعث بهبود رتبه گوگل می‌شود؟
رتبه را تضمین نمی‌کند. Google Responsive design را برای سادگی پیاده‌سازی و نگهداری توصیه می‌کند و محتوای موبایل را مبنای Mobile-first indexing می‌گیرد. Parity محتوا، Crawl/Render، کیفیت، سرعت و عوامل دیگر همچنان تعیین‌کننده‌اند.
چگونه بفهمیم سایت واقعاً ریسپانسیو است؟
Journeyهای اصلی را در عرض‌های بین Breakpoint، Zoom ۲۰۰/۴۰۰٪، Portrait/Landscape، Touch/Keyboard، متن فارسی-لاتین، داده بلند، شبکه کند و Stateهای Error/Loading روی دستگاه واقعی اجرا کنید. قبولی یعنی Task کامل شود، نه فقط اینکه صفحه بدون اسکرول افقی دیده شود.
جمع‌بندی: طراحی ریسپانسیو یک مجموعه Screenshot نیست؛ قرارداد تطبیق و کیفیت است. وقتی Source order، Layout ذاتی، Breakpoint محتوامحور، Container، رسانه، Accessibility، RTL، Performance، SEO parity و تست واقعی به هم متصل شوند، سایت از «در موبایل جا می‌شود» به محصولی تبدیل می‌شود که در شرایط واقعی کار می‌کند.
