Kích Thước Màn Hình Chuẩn Khi Thiết Kế Web

Không có một kích thước màn hình duy nhất được xem là “chuẩn” cho mọi website. Cách làm thực tế là thiết kế một hệ giao diện linh hoạt, dùng vài canvas đại diện để ra quyết định rồi kiểm thử liên tục ở mọi độ rộng giữa chúng. Bộ khởi đầu dễ dùng là 360 hoặc 390 CSS px cho mobile, 768 CSS px cho tablet, 1280 hoặc 1440 CSS px cho desktop; đồng thời phải kiểm tra reflow ở 320 CSS px và màn hình rộng khoảng 1920 px. Các con số này là điểm tham chiếu, không phải danh sách thiết bị cần nhắm tới. Bài viết giải thích cách phân biệt CSS pixel với độ phân giải vật lý, chọn breakpoint theo nội dung, đặt container–grid–gutter, bàn giao từ Figma sang HTML/CSS và nghiệm thu responsive mà không phụ thuộc một mẫu điện thoại hay laptop cụ thể.

Kích thước thiết kế web nên dùng là bao nhiêu?

Câu trả lời ngắn: hãy tạo ít nhất ba frame đại diện và kiểm tra thêm hai biên. Mobile có thể thiết kế ở 360 hoặc 390 CSS px; tablet ở 768 CSS px; desktop ở 1280 hoặc 1440 CSS px. Sau đó kiểm tra giao diện tại 320 CSS px để phát hiện tràn ngang và ở 1920 CSS px để bảo đảm nội dung không bị kéo giãn quá rộng. Nếu analytics của website hiện tại cho thấy nhóm viewport khác chiếm tỷ trọng lớn, hãy ưu tiên dữ liệu thật.

Không giao một file chỉ có desktop 1440 rồi yêu cầu developer “tự responsive”. Mỗi loại component quan trọng cần mô tả cách co giãn, xếp cột, xuống dòng, ẩn/hiện và giới hạn chiều rộng. Bài thiết kế website responsive đi sâu vào Flexbox, Grid, media query và kỹ thuật triển khai; bài hiện tại tập trung vào quyết định kích thước và tài liệu bàn giao.

CSS pixel, pixel màn hình và viewport khác nhau thế nào?

Trong thiết kế web, con số 390 thường đại diện cho CSS pixel của viewport, không phải số pixel vật lý trên tấm nền điện thoại. Một thiết bị có thể có độ phân giải vật lý rất cao và device pixel ratio lớn, nhưng trình duyệt vẫn báo viewport khoảng vài trăm CSS px. CSS pixel là đơn vị độc lập với mật độ, giúp chữ và component giữ kích thước sử dụng hợp lý trên các màn hình có mật độ khác nhau.

Viewport là vùng cửa sổ mà nội dung web được bố trí. Nó có thể nhỏ hơn màn hình vì thanh trình duyệt, cửa sổ chia đôi, sidebar hoặc zoom. Người dùng laptop 1920 px không nhất thiết xem website ở viewport 1920; họ có thể đặt trình duyệt nửa màn hình. Đây là lý do breakpoint không nên đồng nghĩa với tên thiết bị.

Tài liệu MDN về viewport giải thích rằng trình duyệt mobile cũ có thể dùng virtual viewport rộng khoảng 980 px rồi thu nhỏ toàn trang. Khai báo width=device-width cho trình duyệt biết nên khớp layout viewport với chiều rộng thiết bị tính bằng CSS pixel:

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

Trong Figma, frame 390 px có thể được xem như tham chiếu 390 CSS px khi bàn giao, nhưng ảnh bitmap cần đủ mật độ để sắc nét. Đừng nhân đôi toàn bộ layout thành 780 chỉ vì thiết bị có DPR 2. Thiết kế giữ kích thước logic; pipeline ảnh hoặc srcset cung cấp file phù hợp mật độ hiển thị.

Chọn frame mobile, tablet và desktop như thế nào?

Frame là nơi designer minh họa quyết định ở một độ rộng đại diện. Breakpoint là điều kiện khiến CSS thay đổi bố cục. Hai khái niệm liên quan nhưng không giống nhau: bạn có thể bàn giao ba frame trong khi code có hai, ba hoặc bốn breakpoint tùy component. Điều quan trọng là các trạng thái giữa frame không bị bỏ mặc.

Hãy chọn frame sau khi biết loại trang, dữ liệu và nguồn truy cập. Dashboard có sidebar, bảng và bộ lọc cần trạng thái trung gian khác landing page một cột. Website bán hàng phải thử tên sản phẩm dài, bộ lọc và giỏ hàng; trang nội dung cần kiểm soát độ dài dòng. Nếu đã có site, lấy phân bố viewport từ analytics và chọn các mốc đại diện cho nhóm người dùng thật thay vì sao chép preset của công cụ.

Mobile: thiết kế chính ở 360 hoặc 390 CSS px

360 px là canvas gọn, giúp phát hiện sớm tiêu đề dài, card quá cứng và nút chen nhau. 390 px gần với nhiều viewport điện thoại hiện đại và cho không gian thực tế hơn. Chọn một mốc làm frame chính, nhưng kéo thử liên tục từ 320 đến khoảng 480. Thiết kế mobile-first không có nghĩa thu nhỏ desktop; nó buộc bạn xác định thứ tự nội dung, CTA và trạng thái quan trọng trước. Dùng padding ngang khởi điểm 16–20 px, nhưng điều chỉnh theo brand và độ rộng component thay vì xem đây là hằng số bắt buộc.

Tablet: dùng 768 CSS px để kiểm tra trạng thái giữa

Tablet thường bị bỏ qua vì đội ngũ chỉ bàn giao mobile và desktop. Khoảng rộng trung gian lại là nơi menu, card ba cột, bảng và form dễ vỡ nhất. Frame 768 px là điểm tham chiếu thuận tiện, nhưng hãy kiểm tra cả portrait, landscape và cửa sổ trình duyệt bị thu nhỏ. Một layout không nhất thiết phải “trông như desktop nhỏ”; đôi khi sidebar chuyển thành drawer, ba cột thành hai và bộ lọc thành nút mở sheet. Quyết định dựa trên không gian của nội dung chứ không dựa trên nhãn tablet.

Desktop: dùng 1280 hoặc 1440 CSS px, nội dung có max-width

1280 phù hợp cho laptop và giúp tránh thiết kế quá rộng; 1440 cho thêm không gian trình bày hệ grid, hình hero hoặc dashboard. Dù dùng frame nào, phần nội dung thường nằm trong container giới hạn khoảng 1120–1280 px, tùy dự án, còn background có thể full-bleed. Nếu dàn chữ chạy hết 1440 hoặc 1920, độ dài dòng sẽ khó đọc và khoảng cách giữa nhóm thông tin mất liên kết. Bàn giao phải ghi max-width, min padding và hành vi khi viewport rộng hơn frame.

Màn hình rộng: kiểm tra ở 1920 CSS px thay vì kéo giãn mọi thứ

Ở màn hình rộng, container thường giữ giới hạn và được căn giữa; chỉ nền, ảnh trang trí hoặc section có chủ đích mới trải toàn chiều ngang. Kiểm tra hero không tạo khoảng trống vô nghĩa, ảnh đủ độ phân giải, modal không quá lớn và nội dung vẫn có trọng tâm. Với dashboard hoặc bản đồ, vùng làm việc có thể tận dụng thêm không gian nhưng vẫn cần giới hạn chiều dài form và đoạn chữ. 1920 là mốc QA hữu ích, không nhất thiết là một file thiết kế hoàn chỉnh riêng.

Chọn breakpoint theo nội dung, không theo tên thiết bị

Breakpoint tốt xuất hiện tại thời điểm bố cục bắt đầu mất chất lượng: menu không còn chỗ, card quá hẹp, tiêu đề tạo dòng xấu, bảng không đọc được hoặc khoảng trắng trở nên vô lý. web.dev khuyến nghị bắt đầu từ màn hình nhỏ, tăng dần chiều rộng và thêm breakpoint khi nội dung thực sự cần thay đổi, thay vì bám theo thương hiệu điện thoại hoặc hệ điều hành.

Quy trình thực tế gồm bốn bước. Đầu tiên, dựng layout nhỏ nhất với nội dung thật. Tiếp theo, kéo viewport rộng dần đến khi component trông quá thưa hoặc có đủ chỗ cho cấu trúc mới. Đặt breakpoint tại vùng chuyển đổi, rồi kiểm tra vài pixel trước và sau. Cuối cùng, lặp với dữ liệu dài, trạng thái lỗi, zoom và ngôn ngữ khác nếu site đa ngôn ngữ.

Các mốc như 640, 768, 1024, 1280 và 1536 px là điểm bắt đầu quen thuộc trong framework, không phải chuẩn web toàn cầu. Một website đơn giản có thể chỉ cần hai breakpoint; dashboard phức tạp có thể cần nhiều hơn. Càng nhiều breakpoint càng tăng chi phí kiểm thử và nguy cơ override xung đột. Ưu tiên fluid layout bằng Flexbox, Grid, minmax(), clamp() và container linh hoạt; dùng breakpoint khi cấu trúc thực sự phải đổi.

Container, grid và gutter nên đặt bao nhiêu?

Container kiểm soát chiều rộng nội dung; grid tạo quan hệ cột; gutter giữ khoảng cách giữa cột và mép màn hình. Không có một bộ số duy nhất, nhưng hệ khởi đầu nhất quán giúp Figma và CSS nói cùng ngôn ngữ. Đừng nhầm frame 1440 với container 1440: frame là viewport tham chiếu, còn nội dung thường hẹp hơn.

Đây là gợi ý khởi động, không phải tiêu chí WCAG hay SEO. Website editorial có thể dùng cột đọc 640–760 px trong container lớn; dashboard cần vùng dữ liệu rộng; landing page có section full-bleed nhưng text vẫn giới hạn. Xây spacing scale 4 hoặc 8 px để giảm giá trị tùy ý, song vẫn cho phép ngoại lệ có lý do. Ghi rõ tên token như container-lg, space-6, gutter-md thay vì chỉ ghi số rời rạc trên từng frame.

Thiết kế UI/UX responsive phải quyết định những gì?

Responsive không chỉ là thay số cột. Thiết kế chuẩn UI/UX phải giữ đúng thứ tự thông tin, chức năng và ngữ nghĩa khi không gian thay đổi. Mỗi component cần một quy tắc: kích thước linh hoạt đến đâu, khi nào wrap, khi nào đổi layout, nội dung nào ưu tiên, và trạng thái tương tác hoạt động thế nào với chuột, bàn phím và cảm ứng. Trước khi vẽ từng breakpoint, hãy lập danh sách component có rủi ro cao: navigation nhiều mục, card chứa dữ liệu dài, form nhiều trường, bảng, modal, banner có chữ trên ảnh và vùng sticky. Thử chúng bằng nội dung cực ngắn lẫn cực dài. Việc này biến responsive thành yêu cầu có thể kiểm tra, thay vì một ghi chú chung ở cuối file.

Typography và độ dài dòng

Dùng type scale có giới hạn thay vì phóng to theo viewport vô hạn. clamp() có thể giúp heading tăng mượt giữa giá trị tối thiểu và tối đa, nhưng vẫn phải thử tiếng Việt có dấu, tiêu đề dài và zoom. Khối văn bản chính nên có max-width theo số ký tự hoặc rem để không chạy từ mép này sang mép kia trên desktop. Line-height, khoảng đoạn và hierarchy phải còn rõ trên mobile. Không biến chữ thành ảnh chỉ để giữ đúng xuống dòng của mockup.

Nút, link và vùng chạm

Trên màn hình nhỏ, kích thước nhìn thấy và vùng tương tác không nhất thiết giống nhau, nhưng người dùng vẫn cần chạm chính xác. WCAG 2.2 Target Size (Minimum) đặt mức tối thiểu 24×24 CSS px hoặc yêu cầu khoảng cách theo ngoại lệ; các nút quan trọng thường nên rộng hơn mức tối thiểu để dễ dùng. Kiểm tra icon-only button, nút đóng modal, pagination và hai link đặt sát nhau. Luôn có trạng thái focus, hover, active, disabled và loading. Thử cả thao tác bằng một tay trên điện thoại thật.

Ảnh, video và asset đồ họa

Thiết kế cần ghi tỷ lệ khung, focal point và cách crop, không chỉ đặt một ảnh bitmap vào frame. HTML có thể dùng srcset và sizes để trình duyệt chọn file theo slot hiển thị và mật độ màn hình; MDN về responsive images giải thích cơ chế này. Cung cấp ảnh đủ lớn cho kích thước hiển thị lớn nhất nhưng nén hợp lý. Dùng SVG cho logo/icon khi phù hợp, khai báo width–height để giữ chỗ và tránh layout shift. Kiểm tra cả trường hợp ảnh tải lỗi hoặc chưa có ảnh.

Menu, form, bảng và nội dung khó co

Menu desktop có thể thành nút mở navigation trên mobile, nhưng mục và thứ tự phải còn đầy đủ. Form nhiều cột thường chuyển một cột; label không được chỉ tồn tại dưới dạng placeholder. Bảng dữ liệu cần chiến lược: cuộn vùng bảng, ưu tiên cột, card hóa hàng hoặc cung cấp chế độ chi tiết—không ép mọi cột thành chữ siêu nhỏ. Biểu đồ, bản đồ và trình chỉnh sửa là các trường hợp có thể cần scroll hai chiều có kiểm soát. Thiết kế cả empty, error, loading và nội dung dài vì đó là nơi kích thước “đẹp” ban đầu thường vỡ.

Từ Figma sang HTML, CSS và JavaScript

Figma mô tả ý định; trình duyệt quyết định layout cuối dựa trên HTML, CSS, nội dung và viewport. HTML5 tạo cấu trúc ngữ nghĩa như header, nav, main, section, form và table. CSS chịu vai trò chính về kích thước, spacing, grid, typography, media query và trạng thái hiển thị. JavaScript xử lý hành vi như menu, modal, carousel hoặc dữ liệu động; nó không nên được dùng để vá một layout mà CSS có thể giải quyết tự nhiên. PHP hoặc framework phía server tạo HTML/dữ liệu, nhưng breakpoint vẫn chủ yếu được triển khai ở lớp CSS.

Handoff không nên chỉ ghi “desktop 1440, mobile 390”. Với mỗi template và component, hãy giao token, max/min width, auto layout, quy tắc wrap, breakpoint thay đổi cấu trúc, trạng thái và ví dụ nội dung biên. Nếu developer phải đo từng khoảng cách bằng mắt hoặc đoán thứ tự mobile, file thiết kế chưa hoàn chỉnh.

Đọc thêm vai trò của HTML và vai trò của CSS nếu bạn cần hiểu nền tảng trước khi bàn giao. Hướng dẫn thiết kế giao diện bằng Figma và Canva trình bày quy trình wireframe, component và prototype rộng hơn.

Ma trận kiểm thử kích thước màn hình

Không thể thử mọi thiết bị, nhưng có thể phủ các loại lỗi bằng một ma trận nhỏ. Kiểm tra ở viewport cố định, kéo liên tục giữa breakpoint, zoom, thiết bị thật và dữ liệu biên. Browser DevTools hữu ích để lặp nhanh; thiết bị thật phát hiện bàn phím ảo, thanh trình duyệt, vùng an toàn, touch và hiệu năng mà giả lập không phản ánh đầy đủ.

WCAG 2.2 Reflow yêu cầu nội dung cuộn dọc có thể trình bày ở độ rộng tương đương 320 CSS px mà không mất thông tin/chức năng và không cần cuộn hai chiều, trừ nội dung thực sự cần bố cục hai chiều. Đây là tiêu chí accessibility, không phải tuyên bố rằng mọi người dùng có thiết bị 320 px. Khi kiểm thử, ghi viewport, trình duyệt, mức zoom, bước tái hiện, kết quả mong đợi và thực tế để lỗi có thể được sửa và kiểm lại.

Tám nguyên lý chọn size và thiết kế web responsive

Một hệ giao diện bền vững tuân theo tám nguyên lý. Thứ nhất, nội dung quyết định breakpoint, không phải tên thiết bị. Thứ hai, thiết kế từ nhỏ lên lớn để xác định ưu tiên sớm. Thứ ba, dùng layout fluid trước media query. Thứ tư, giới hạn chiều rộng nội dung, không kéo chữ theo toàn màn hình.

Thứ năm, component có quy tắc riêng: card có thể wrap ở mốc khác navigation. Container query cho phép style theo kích thước vùng chứa thay vì toàn viewport; MDN giải thích @container hoạt động tương tự media query nhưng dựa trên container. Thứ sáu, thiết kế bằng dữ liệu biên, gồm chữ dài, ảnh thiếu, lỗi và trạng thái rỗng. Thứ bảy, không khóa zoom hoặc ẩn chức năng mobile. Thứ tám, kiểm thử liên tục giữa các frame, không chỉ chụp ba màn hình đẹp.

Những nguyên lý này quan trọng hơn việc thuộc một bảng size. Khi thiết bị mới xuất hiện hoặc cửa sổ bị chia đôi, layout dựa trên quy tắc vẫn thích ứng; layout dựa trên tên model sẽ tạo thêm ngoại lệ. Một giao diện thiết kế web tốt không “đúng kích thước” ở ba ảnh, mà giữ được hierarchy, chức năng và khả năng đọc trong toàn dải.

Kích thước màn hình có làm website chuẩn SEO không?

Responsive là một phần của trải nghiệm và khả năng truy cập, không phải toàn bộ “thiết kế web chuẩn SEO”. Một website có thể hiển thị tốt ở 390, 768 và 1440 nhưng vẫn thiếu nội dung, title, canonical, internal link, sitemap hoặc tốc độ. Ngược lại, meta tag đầy đủ không cứu được trang bị tràn ngang, nút khó bấm và nội dung mobile bị ẩn.

Khi kích thước được xử lý tốt, người dùng đọc và thao tác dễ hơn; code có thể dùng cùng URL/nội dung thay vì duy trì phiên bản mobile tách rời. Ảnh responsive giúp tránh tải asset quá lớn; khai báo kích thước ảnh giúp trình duyệt giữ chỗ; layout fluid giảm lỗi trên viewport lạ. Những yếu tố này hỗ trợ chất lượng kỹ thuật và trải nghiệm, nhưng không nên được diễn giải thành cam kết thứ hạng.

Bài thiết kế website chuẩn SEO là gì bao quát cấu trúc, metadata, crawl/index, hiệu năng và nội dung. Trong dự án thực tế, hãy nghiệm thu responsive cùng SEO kỹ thuật và accessibility thay vì để ba nhóm kiểm tra độc lập vào phút cuối.

Câu hỏi thường gặp về kích thước thiết kế web

Các câu hỏi sau xử lý những nhầm lẫn thường gặp giữa frame Figma, breakpoint CSS, độ phân giải thiết bị và kích thước asset. Con số đưa ra là mốc khởi đầu; quyết định cuối phải dựa trên nội dung và dữ liệu dự án.

Thiết kế website desktop ở 1366 hay 1440 px?

Cả hai đều có thể dùng, nhưng 1440 thuận tiện cho thiết kế và hệ grid, còn 1366 đại diện nhiều laptop cũ hơn. Một lựa chọn thực tế là thiết kế chính ở 1440 với container 1200–1280, rồi kiểm tra ở 1280 và 1366. Nếu layout chỉ đẹp đúng 1440, hệ thống chưa responsive. Đừng để text hoặc form chiếm toàn chiều rộng frame chỉ vì canvas còn chỗ.

Nên thiết kế mobile ở 360 hay 390 px?

Chọn một mốc theo dữ liệu người dùng hoặc quy ước đội ngũ; cả 360 và 390 đều hợp lý. 360 tạo áp lực tốt cho nội dung hẹp, còn 390 gần nhiều viewport hiện đại. Quan trọng hơn là kiểm tra liên tục từ 320 đến 480 và không cố định component theo một model. Nếu có analytics, chọn frame chính gần nhóm phổ biến nhưng vẫn nghiệm thu biên nhỏ.

Breakpoint chuẩn có phải 768, 1024 và 1440 không?

Không. Đây là các mốc quen thuộc, không phải tiêu chuẩn bắt buộc. Breakpoint nên xuất hiện khi nội dung hoặc component cần đổi bố cục. Bạn có thể dùng token framework để nhất quán, nhưng phải kéo thử với nội dung thật và điều chỉnh. Đừng thêm breakpoint cho từng thiết bị; số lượng quá nhiều làm CSS khó bảo trì và tăng ma trận kiểm thử.

Có cần vẽ thiết kế web cho mọi kích thước không?

Không cần vẽ hàng chục frame, nhưng phải mô tả quy tắc giữa các frame. Bàn giao thường gồm mobile, tablet khi có trạng thái riêng, desktop, component state và ghi chú responsive. Những vùng phức tạp như navigation, bảng, dashboard, hero hoặc form cần ví dụ bổ sung. Developer vẫn phải kiểm tra mọi chiều rộng, còn designer cần review bản chạy thay vì chỉ duyệt ảnh chụp đúng preset.

Ảnh hero nên xuất kích thước bao nhiêu?

Không có một kích thước chung vì slot, tỷ lệ và focal point khác nhau. Hãy xác định kích thước hiển thị lớn nhất, chuẩn bị file đủ sắc nét cho mật độ cao, nén và cung cấp nhiều candidate qua srcset/CDN. Với mobile có thể cần art direction hoặc crop riêng thay vì tải cùng ảnh desktop khổng lồ. Luôn khai báo tỷ lệ/width–height và kiểm tra chữ overlay trên ảnh ở từng viewport.

Mô hình ba lớp có liên quan gì đến responsive?

Trong cách giải thích phổ biến, lớp trình bày chịu trách nhiệm giao diện responsive, lớp nghiệp vụ xử lý logic và lớp dữ liệu lưu/truy xuất thông tin. Tuy nhiên, dữ liệu từ lớp sau vẫn tác động layout: tên dài, trạng thái trống, lỗi hoặc quyền khác nhau có thể làm component thay đổi. Vì thế designer và front-end cần thống nhất giới hạn dữ liệu với back-end, không kiểm thử giao diện chỉ bằng nội dung mẫu lý tưởng.

Kết luận: thiết kế một dải kích thước, không thiết kế ba ảnh

Bộ frame 360/390, 768 và 1280/1440 CSS px là điểm bắt đầu tốt; 320 và 1920 là hai biên kiểm thử hữu ích. Nhưng chất lượng không nằm ở việc chọn đúng một con số. Nó nằm ở quy tắc container, grid, wrap, breakpoint, max-width, dữ liệu biên và cách component thay đổi trong toàn dải viewport.

Hãy chốt frame cùng developer, dùng CSS pixel làm ngôn ngữ chung, thêm breakpoint tại điểm nội dung vỡ và review bản chạy trên thiết bị thật. Luôn lưu ma trận viewport và dữ liệu kiểm thử để lần cập nhật sau không lặp lại cùng lỗi. Nếu dự án của bạn đã có file UI nhưng chưa rõ grid, breakpoint, tablet state hoặc tài liệu handoff, RiverLee có thể rà component và đề xuất hệ responsive trước khi bước vào phát triển. Liên hệ 0962.334.807 để đánh giá phạm vi; nếu mục tiêu chỉ là học kỹ thuật CSS, hãy bắt đầu từ bài responsive đã liên kết ở đầu bài.