Thiết kế ưu tiên di động (mobile-first) là gì? Bản kiểm 22 điểm cho trang web Việt 2026

70,4% lượt truy cập tại Việt Nam đến từ điện thoại (DataReportal Digital 2026 Vietnam), nhưng vẫn còn khoảng một phần ba trang web Việt xây cho máy tính bàn trước rồi "ép" thu nhỏ xuống — kết quả là tải chậm trên điện thoại, nút bấm quá nhỏ, dấu tiếng Việt vỡ ở 320px. Bài này định nghĩa mobile-first (ưu tiên di động) chính xác là gì, khác cách làm tự thích nghi màn hình thế nào, kèm bản kiểm 22 điểm thực dụng theo 5 nhóm, và số liệu chứng minh từ hayweb.vn (Lighthouse di động 88 đến 92, LCP 2,0 đến 3,0 giây, Mozilla A+ 120).

Thiết kế ưu tiên di động (mobile-first) là gì? Định nghĩa chính xác cho trang web Việt 2026

Mobile-first (ưu tiên di động) là cách xây trang web bắt đầu từ màn hình nhỏ nhất (375px — iPhone SE, điện thoại Android phổ thông) rồi mở rộng dần lên các cỡ màn hình lớn hơn qua quy tắc theo độ rộng tối thiểu (min-width). Đây là một phương pháp thiết kế, không chỉ là kỹ thuật CSS. Ngược với kiểu "làm cho điện thoại sau cùng" — tức xây cho máy tính bàn xong rồi mới ép xuống — cách ưu tiên di động buộc người thiết kế và lập trình phải đặt nội dung cốt lõi lên trước ngay từ đầu.

Mobile-first khác gì cách thiết kế tự thích nghi (responsive)

Thiết kế tự thích nghi (responsive) là kết quả — trang web tự co giãn theo mọi kích thước màn hình. Ưu tiên di động là phương pháp để đạt kết quả đó: viết kiểu hiển thị mặc định cho điện thoại trước, sau đó dùng quy tắc min-width để mở rộng lên máy tính bảng và máy tính bàn. Một trang web có thể tự thích nghi mà không phải ưu tiên di động, nếu kiểu hiển thị bắt đầu từ máy tính bàn rồi dùng max-width để thu nhỏ xuống. Khác biệt này quan trọng về tốc độ: kiểu hiển thị ưu tiên di động nhẹ hơn vì trình duyệt trên điện thoại không phải tải những quy tắc của máy tính bàn không cần thiết, trong khi kiểu bắt đầu từ máy tính bàn bắt trình duyệt điện thoại tải hết rồi mới ghi đè — kết quả là vẽ trang chậm hơn và xê dịch bố cục nhiều hơn trên các máy tầm trung phổ biến ở Việt Nam như Samsung A30/A50 hay Oppo A18.

Vì sao 70,4% lượt truy cập là điện thoại lại quan trọng với bạn

Theo DataReportal Digital 2026 Vietnam (truy xuất 2026-02), 70,4% lượt truy cập tại Việt Nam đến từ thiết bị di động — cao hơn mức trung bình toàn cầu. Decision Lab Vietnam Connected Consumer Q4 2025 (truy xuất 2026-01) bổ sung: 92% người dùng Việt sở hữu điện thoại thông minh, trong đó 61% dùng điện thoại làm thiết bị chính để vào internet. Google áp dụng lập chỉ mục ưu tiên di động 100% từ 2023 — nghĩa là robot Google đọc và lập chỉ mục phiên bản điện thoại của trang web để quyết định thứ hạng, không phải phiên bản máy tính bàn. Nếu phiên bản điện thoại thiếu nội dung hoặc chậm hơn, thứ hạng giảm theo — ngay cả khi bản máy tính bàn hoàn hảo.

Lịch sử ưu tiên di động — từ Luke Wroblewski 2009 đến Google 2026

Luke Wroblewski đặt ra khái niệm ưu tiên di động năm 2009 và hệ thống hóa trong cuốn "Mobile First" (2011). Ethan Marcotte song song phát triển thiết kế tự thích nghi (A List Apart, 2010). Hai khái niệm này bổ sung nhau: Marcotte cho nền tảng kỹ thuật CSS co giãn, Wroblewski cho phương pháp thiết kế đặt điện thoại lên trước. Google biến ưu tiên di động từ một khuyến nghị thành yếu tố xếp hạng khi ra mắt lập chỉ mục ưu tiên di động (thử nghiệm 2018, áp dụng toàn bộ 2023). Đến 2026, khi AI Overviews và các công cụ tìm kiếm AI đều kiểm tra bản hiển thị trên điện thoại trước khi trích nội dung, ưu tiên di động không còn là lựa chọn tùy ý — nó là điều kiện để xuất hiện trong kết quả tìm kiếm cho người dùng Việt dùng điện thoại.

Lập chỉ mục ưu tiên di động và các công cụ AI 2026

Mueller (Google) trong buổi hỏi đáp SEO tháng 6/2024 xác nhận: Google không phân biệt ưu tiên di động và tự thích nghi nếu nội dung tương đương nhau — điều quan trọng là bản điện thoại phải có đủ nội dung như bản máy tính bàn, không giấu nội dung quan trọng sau thẻ gập chỉ trên điện thoại. Ngoài Google, các công cụ AI đang tăng tại Việt Nam (ChatGPT, Perplexity, AI Hay) cũng đọc và trích nội dung từ bản điện thoại. Website có độ phản hồi tương tác kém — tỷ lệ đạt chuẩn của chỉ số INP tại Việt Nam khoảng 58% trên điện thoại so với 92% trên máy tính bàn theo Google web.dev — chỉ số INP (March 2026) (truy xuất 2026-04) — bị đánh giá trải nghiệm thấp hơn trong cả tìm kiếm thường lẫn khi AI trích nội dung.

Bản kiểm 22 điểm ưu tiên di động cho trang web Việt 2026 — 5 nhóm thực dụng

Bản kiểm dưới đây chia 5 nhóm theo thứ tự ưu tiên: nền tảng khung nhìn trước, vùng chạm sau, rồi chữ tiếng Việt, nút Zalo và số gọi đặc thù thị trường Việt, cuối cùng là ba chỉ số tốc độ. Mỗi điểm có hành động cụ thể — không có khuyến nghị chung chung.

Nhóm 1: Khung nhìn và bố cục (4 điểm)

Nền tảng — sai ở đây, mọi thứ phía trên đổ theo.

1. Thẻ khai báo khung nhìn đúng cú pháp. Thêm <meta name="viewport" content="width=device-width, initial-scale=1.0"> vào <head>. Không có thẻ này, trình duyệt điện thoại sẽ vẽ trang ở bề rộng máy tính bàn 980px rồi thu nhỏ lại — chữ bé, nút bé, người dùng bỏ trang ngay. Đây là điểm kiểm tra đầu tiên trong mọi lần rà soát điện thoại.

2. Bắt đầu chia màn hình từ 375px. Viết kiểu hiển thị ưu tiên di động: mặc định cho 375px, dùng @media (min-width: 768px) để mở rộng lên máy tính bảng, @media (min-width: 1024px) cho máy tính bàn. Làm ngược thứ tự sẽ tạo ra chuỗi ghi đè không kiểm soát được.

3. Không dùng max-width cứng cho khung chứa chính trên điện thoại. Khung chứa có max-width: 1200px mà thiếu width: 100% sẽ tràn ngang trên màn 375px. Cuộn ngang là lỗi trải nghiệm mà robot Google đánh dấu khi đọc bản điện thoại.

4. Kiểm tra tràn ngang toàn trang. Mở công cụ nhà phát triển của Chrome, bật chế độ giả lập thiết bị, kéo màn hình về 375px, bật hiện thanh cuộn. Bất kỳ chỗ cuộn ngang nào cũng cần sửa trước khi đưa lên. Lỗi phổ biến: ảnh thiếu max-width: 100%, bảng cố định chiều rộng, video nhúng không co giãn.

Xem thêm cách bản kiểm này nối với bản kiểm kỹ thuật SEO 30 điểm cho doanh nghiệp Việt 2026.

Nhóm 2: Vùng chạm và khoảng cách (5 điểm)

Kích thước — ngón tay người không nhỏ như con trỏ chuột.

Bộ hướng dẫn giao diện của Apple (truy xuất 2026-05) khuyến nghị vùng chạm tối thiểu 44pt (khoảng 48px), trong khi Material Design 3 (truy xuất 2026-05) quy định tối thiểu 48dp với khoảng cách 8dp giữa các vùng chạm. Hai chuẩn này gặp nhau ở ngưỡng 48px — nhỏ hơn là chạm nhầm, khó chịu, người dùng rời trang. Tại thị trường Việt, đây là lỗi phổ biến nhất trên trang bán hàng của doanh nghiệp nhỏ vì người thiết kế thường xem thử trên màn máy tính bàn 1920px rồi tưởng nút đã đủ lớn.

5. Vùng chạm tối thiểu 48 x 48px. Áp dụng cho tất cả nút, liên kết, biểu tượng, ô nhập. Dùng min-height: 48px; min-width: 48px — không chỉ kích thước nhìn thấy mà cả vùng bấm được. Nút "Đặt lịch" 12 x 40px trông gọn trên máy tính bàn nhưng là cực hình khi chạm trên Samsung A50.

6. Khoảng cách giữa các vùng chạm tối thiểu 8px. Hai nút sát nhau = người dùng chạm nhầm liên tục. Dùng gap trong Flexbox/Grid hoặc margin để giữ khoảng cách. Đặc biệt quan trọng với trình đơn trên điện thoại và danh sách liên kết.

7. Nút kêu gọi chính rộng hết màn hình trên điện thoại. Nút "Liên hệ", "Đặt lịch", "Mua ngay" nên chiếm trọn bề ngang màn hình điện thoại — dễ chạm, thứ bậc rõ ràng, không cần nhắm chính xác.

8. Không dùng thao tác chỉ chạy khi rê chuột. Màn hình cảm ứng không có trạng thái rê chuột. Trình đơn sổ xuống chỉ mở khi rê chuột = không dùng được trên điện thoại. Chuyển sang mở bằng chạm — cách phổ biến là nút ba vạch hoặc khối gập mở ra.

9. Chiều cao ô nhập tối thiểu 48px. Ô chữ, ô chọn, ô nhập dài đều phải đủ cao để chạm chính xác mà không cần phóng to. Thuộc tính font-size: 16px trên ô nhập còn ngăn iOS tự phóng to ngoài ý muốn khi người dùng chạm vào ô. Xem thêm cách bảy mô hình liên kết nội bộ hub-spoke và pillar cũng áp dụng nguyên tắc phân cấp tương tự cho thứ bậc nội dung.

Nhóm 3: Chữ tiếng Việt (4 điểm)

Dấu — font không hiện đủ dấu tiếng Việt thì nội dung vô nghĩa.

Tiếng Việt có 6 thanh điệu và các dấu phụ (â, ê, ô, ơ, ư, ă, đ) — tổng cộng hơn 130 ký tự đặc thù trong bảng mã Latin mở rộng. Font không đỡ đủ bảng mã = chữ hiện sai hoặc mất dấu, đặc biệt rõ trên màn hình nhỏ mật độ điểm ảnh cao như Samsung A30/A50 hay iPhone 11/12. Theo Mozilla MDN — khung nhìn CSS và thiết kế tự thích nghi (truy xuất 2026-05), cỡ chữ thân bài nhỏ hơn 16px là lỗi phổ biến gây tự phóng to trên iOS và xê dịch bố cục.

10. Cỡ chữ thân bài tối thiểu 16px trên điện thoại. Nhỏ hơn 16px = trình duyệt Safari trên iOS tự phóng to khi người dùng chạm vào ô nhập, phá vỡ trải nghiệm ngay. Dùng font-size: 16px làm mốc cho body — không phải 14px hay 15px.

11. Giãn dòng tối thiểu 1,5 cho chữ thân bài. Tiếng Việt có dấu trên và dưới ký tự — giãn dòng 1,2 mặc định của nhiều bộ thiết lập CSS cắt mất dấu, chữ khó đọc trên điện thoại. Đặt line-height: 1.5 tối thiểu, 1,6 đến 1,7 cho đoạn dài.

12. Chọn font đỡ đầy đủ dấu tiếng Việt. Trên Google Fonts có Be Vietnam Pro, Nunito, Source Sans 3 — đỡ đủ bảng Latin mở rộng. Thử hiện các ký tự "ổ ậ ử ữ ỡ ặ ệ" ở 16px trên cả Android và iOS trước khi chốt font chính thức. Xem thêm tiêu chuẩn nội dung chuẩn SEO 2026 về tiêu chuẩn nội dung kết hợp.

13. Tải trước font quan trọng. Thêm <link rel="preload" as="font" href="font.woff2" crossorigin> cho font chính. Không tải trước = font hiện trễ làm chữ nhảy = xê dịch bố cục tăng rõ rệt, nhất là trên mạng 4G yếu phổ biến ở các tỉnh ngoài Hà Nội và TP.HCM.

Nhóm 4: Nút Zalo, bấm để gọi và thanh cố định (4 điểm)

Chuyển đổi — có lượt truy cập điện thoại mà thiếu nút liên hệ đúng kiểu là lãng phí.

Zalo là kênh liên hệ ưu tiên của phần lớn khách hàng doanh nghiệp nhỏ tại Việt Nam trên điện thoại — không gắn nút Zalo là bỏ qua kênh chốt đơn chính của thị trường. Cú pháp đúng cho liên kết Zalo: https://zalo.me/0XXXXXXXXX với số điện thoại 10 chữ số (không dùng mã định danh Zalo vì có thể đổi) — liên kết này mở thẳng cuộc trò chuyện trong ứng dụng Zalo trên cả Android và iOS.

14. Thanh cố định dưới màn hình trên điện thoại với Zalo và số gọi. Thanh cố định ở đáy, cao 56 đến 64px, tối đa 3 thao tác: liên kết tel: (gọi điện), zalo.me (nhắn Zalo), tùy chọn thêm "Đặt lịch". Thanh không được che nội dung chính — thêm padding-bottom: 64px cho body để tránh đè, kèm env(safe-area-inset-bottom) cho iPhone có khuyết màn hình.

15. Bấm để gọi đúng định dạng tel:. <a href="tel:+84XXXXXXXXX"> — không dùng JavaScript gắn vào sự kiện bấm. Giao thức tel: sẵn có chạy thẳng, không cần tải JavaScript, đáng tin hơn trên mạng yếu. Thêm sự kiện đo lường GA4 qua gtag('event', 'click_to_call') để đếm lượt chuyển đổi.

16. Liên kết Zalo đúng định dạng. https://zalo.me/0XXXXXXXXX với số điện thoại 10 số — mở thẳng cuộc trò chuyện trong ứng dụng. Ngoài ra có thể dùng zalo://chat?phone=0XXXXXXXXX cho liên kết Zalo gốc, nhưng cần dự phòng quay về bản HTTPS cho trường hợp chưa cài ứng dụng.

17. Thanh cố định không gây xê dịch bố cục. Thanh hiện ngay khi tải xong (không chờ JavaScript) = không đẩy nội dung. Nếu dùng JavaScript để hiện thanh sau khi cuộn, dùng position: fixed + bottom: 0 + z-index hợp lý, không chèn phần tử vào giữa dòng chảy nội dung.

Thanh cố định dưới màn hình trên điện thoại có hại thứ hạng không? Không hại nếu không che nội dung chính. Hình phạt của Google cho cửa sổ chen ngang (theo buổi hỏi đáp SEO của Mueller tháng 6/2024) chỉ áp cho cửa sổ bật lên che nội dung chính ngay khi người dùng vừa vào trang — không áp cho thanh điều hướng cố định ở đáy với chiều cao hợp lý (dưới 72px). Cách dùng thanh cố định Zalo và số gọi đã được áp rộng rãi tại Việt Nam trên hàng nghìn trang web doanh nghiệp nhỏ mà không có báo cáo bị phạt nào từ Google.

Nhóm 5: Tốc độ — ba chỉ số LCP, INP, CLS (5 điểm)

Tốc độ — tải nội dung chính quá 4 giây trên điện thoại = Google không xếp hạng, người dùng không chờ.

Tốc độ tải nội dung chính trên điện thoại tại Việt Nam kém hơn đáng kể so với máy tính bàn do mạng không đều và máy tầm trung phổ biến (vi xử lý yếu hơn, ít bộ nhớ hơn). Sau tháng 3/2026, Google cân bằng trọng số chỉ số phản hồi tương tác (INP) ngang với tốc độ tải nội dung chính (LCP) — trang chỉ đạt LCP mà INP kém vẫn bị đánh giá "cần cải thiện". Xem chi tiết thay đổi tại Core Web Vitals March 2026: LCP 2 giây và INP 200ms.

18. LCP (tốc độ tải nội dung chính) tối đa 2,5 giây trên điện thoại (mục tiêu tốt: tối đa 2,0 giây). Phần tử tải nội dung chính thường là ảnh đầu trang hoặc tiêu đề H1. Cách tối ưu: nén ảnh sang WebP/AVIF, thêm loading="eager" và fetchpriority="high" cho ảnh này, không tải trễ ảnh ở màn hình đầu. Ảnh đầu trang trên điện thoại không cần rộng quá 600px.

19. INP (độ phản hồi khi tương tác) tối đa 200 mili-giây (mục tiêu tốt: tối đa 100 mili-giây). INP đo thời gian phản hồi khi người dùng tương tác (chạm, bấm, gõ). Luồng xử lý chính bị nghẽn bởi JavaScript nặng = INP cao. Hãy hoãn JavaScript không thiết yếu, tránh tác vụ dài quá 50 mili-giây, ưu tiên xử lý sự kiện nhẹ. Đây là chỉ số kém nhất của phần lớn trang web Việt dùng máy chủ chia sẻ chung.

20. CLS (độ xê dịch bố cục) dưới 0,1 (mục tiêu tốt: dưới 0,05). Xê dịch bố cục phổ biến trên điện thoại: ảnh thiếu thuộc tính width/height, font đổi không có size-adjust, quảng cáo chèn vào sau khi tải. Cách sửa: luôn khai báo kích thước ảnh trong HTML, dùng font-display: optional hoặc swap kèm thuộc tính CSS size-adjust.

21. Tải trễ ảnh dưới màn hình đầu. Chỉ tải trễ ảnh nằm dưới màn hình đầu — không tải trễ ảnh đầu trang. Dùng loading="lazy" cho ảnh từ màn hình thứ hai trở xuống. Kết hợp với định dạng WebP/AVIF để giảm tối đa dữ liệu mạng trên điện thoại.

22. Thử thật trên những dòng điện thoại Việt phổ biến. Trình giả lập trong công cụ nhà phát triển không mô phỏng chính xác việc bóp vi xử lý, độ trễ mạng thật, cảm ứng đa điểm, hay những điểm khác lạ của Safari trên iOS. Hãy thử trên ít nhất Samsung A30/A50 (Android tầm trung, đại diện phân khúc 3 đến 5 triệu phổ biến nhất Việt Nam), iPhone 11/12 (iOS tầm trung), và Oppo A18 (Android phổ thông tầm 2 đến 3 triệu). Đạt trên ba máy này = đạt với phần lớn người dùng thật Việt Nam.

5 bước tự rà soát ưu tiên di động cho trang web hiện tại

Nếu trang web đang chạy và bạn cần đánh giá tình trạng ưu tiên di động hiện tại, 5 bước dưới đây làm được trong 30 đến 60 phút mà không cần công cụ trả phí.

Bước 1: Công cụ Chrome — chế độ giả lập thiết bị, thử 4 cỡ màn hình

Mở công cụ nhà phát triển của Chrome (F12), bấm biểu tượng giả lập thiết bị (Ctrl+Shift+M trên Windows), lần lượt thử 4 cỡ màn hình: 375px (iPhone SE, Android phổ thông), 414px (iPhone Pro Max, Android màn lớn), 360px (Samsung dòng A điển hình), 320px (trường hợp xấu nhất — vẫn còn máy cũ tại Việt Nam). Ở mỗi cỡ, kiểm tra: không cuộn ngang, chữ không bị cắt, nút đủ lớn để chạm, ảnh không vỡ. Ghi lại mọi bất thường — đây là mốc nền để so sánh sau khi sửa.

Bước 2: Chạy Lighthouse chế độ điện thoại và đo ba chỉ số tốc độ

Trong công cụ nhà phát triển mở thẻ Lighthouse, chọn chế độ điện thoại (nút Mobile, không phải Desktop), chạy đủ bốn nhóm Hiệu năng, Khả năng tiếp cận, Thực hành tốt và Tối ưu tìm kiếm. Mục tiêu tối thiểu: điểm hiệu năng ít nhất 85, LCP tối đa 2,5 giây, INP tối đa 200 mili-giây, CLS tối đa 0,1. Nhiều nhóm chỉ chạy Lighthouse chế độ máy tính bàn rồi báo điểm cao — đây là lỗi phổ biến vì điểm máy tính bàn thường cao hơn điện thoại 10 đến 20 điểm do mức bóp vi xử lý khác nhau. Bắt buộc chọn chế độ điện thoại khi rà soát.

Bước 3: PageSpeed Insights — dữ liệu thật của 28 ngày gần nhất

Google PageSpeed Insights hiển thị dữ liệu thật từ người dùng (báo cáo CrUX) trong 28 ngày gần nhất — quan trọng hơn dữ liệu đo mô phỏng của Lighthouse vì đo trên thiết bị và mạng thật. Nếu trang web chưa đủ lượt truy cập để có dữ liệu thật, hãy chạy bài đo mô phỏng thay thế. So sánh điểm điện thoại với máy tính bàn để hiểu khoảng cách: nếu điện thoại thấp hơn máy tính bàn trên 15 điểm, đó là dấu hiệu cần rà soát sâu tốc độ trên điện thoại.

Bước 4: Google Search Console — báo cáo trải nghiệm trên điện thoại

Mở Google Search Console mục Trải nghiệm để kiểm tra các lỗi "chữ quá nhỏ để đọc", "phần tử bấm được quá sát nhau", "nội dung rộng hơn màn hình", và xem URL nào bị đánh dấu Kém hoặc Cần cải thiện trên điện thoại. Dữ liệu này là dữ liệu thật từ lượt đọc của robot Google — gần nhất với cách Google đánh giá trang web bạn. Xuất danh sách URL có vấn đề và ưu tiên sửa theo lượt truy cập.

Bước 5: Thử thật trên 3 điện thoại Việt phổ biến

Lighthouse bóp vi xử lý giả lập nhưng không mô phỏng chính xác những điểm khác lạ của Safari trên iOS, cảm ứng đa điểm, hay cách hoạt động trên mạng 4G yếu. Hãy thử thật trên Samsung Galaxy A30/A50 (Android 2019 đến 2021, chiếm tỷ trọng lớn nhất phân khúc tầm trung Việt Nam), iPhone 11 hoặc iPhone 12 (iOS tầm trung phổ biến), và Oppo A18 (Android phổ thông ở tỉnh). Thao tác cụ thể: chạm mọi nút, điền biểu mẫu, cuộn toàn trang, thử bấm để mở Zalo và bấm để gọi. Nếu có lỗi chỉ xuất hiện trên máy thật mà không thấy trên trình giả lập = đó là lỗi nghiêm trọng cần sửa trước khi đưa lên.

5 sai lầm phổ biến nhất khi làm ưu tiên di động tại Việt Nam

Các sai lầm dưới đây xuất hiện thường xuyên khi rà soát trang web doanh nghiệp nhỏ tại Việt Nam — mỗi cái sửa được độc lập, không cần làm lại toàn bộ.

1. Xây cho máy tính bàn trước, thu nhỏ sau. Đây không phải ưu tiên di động — đây là kiểu "làm cho điện thoại sau cùng". Kết quả: kiểu hiển thị nặng vì phải ghi đè hàng chục quy tắc của máy tính bàn, bố cục vỡ ở những cỡ màn hình không ngờ tới, tốc độ kém hơn vì trình duyệt điện thoại tải cả phần kiểu của máy tính bàn không cần thiết. Kiểu ưu tiên di động bắt đầu từ phần nhỏ nhất, dùng quy tắc min-width để mở rộng — hoàn toàn ngược chiều.

2. Cỡ chữ ô nhập dưới 16px. Safari trên iOS tự phóng to vào bất kỳ ô nhập nào có cỡ chữ dưới 16px khi người dùng chạm — sau đó người dùng phải tự thu nhỏ lại. Kết quả: trải nghiệm bị gián đoạn, tỷ lệ rời trang tăng. Sửa một dòng CSS: input, select, textarea { font-size: 16px; }.

3. Chỉ thử trên trình giả lập, không thử máy thật. Trình giả lập không mô phỏng chính xác việc bóp vi xử lý thật, độ trễ mạng thật, cảm ứng đa điểm, hay những điểm khác lạ của Safari trên iOS. Kết quả: điểm Lighthouse trên máy đo đạt 90+ nhưng trải nghiệm thật trên Samsung A50 hoặc Oppo A18 vẫn chậm, bố cục vỡ ở chỗ không ngờ.

4. Thanh cố định che nội dung chính, thiếu padding-bottom. Thanh cố định 64px ở đáy che mất phần nội dung cuối trang — người dùng không đọc được nút kêu gọi cuối bài, không thấy liên kết chân trang. Robot Google đọc theo màn hình điện thoại cũng bị ảnh hưởng tương tự. Sửa: body { padding-bottom: 64px; } cộng thêm env(safe-area-inset-bottom) cho iPhone có khuyết màn hình.

5. Tối ưu xong LCP rồi bỏ qua INP. Nhiều nhóm tối ưu xong tốc độ tải nội dung chính là nghĩ đã xong. INP đo độ phản hồi sau khi trang tải xong — JavaScript nặng chạy sau khi tải vẫn nghẽn luồng xử lý chính, INP vẫn kém dù LCP đã xanh. Sau tháng 3/2026, Google cân bằng trọng số INP ngang với LCP — thiếu một chỉ số là không đủ điều kiện "trải nghiệm trang tốt".

HAYWEB làm ưu tiên di động — tỷ lệ chất liệu gốc và số liệu thật

Không có công thức thần kỳ — chỉ có quy trình kiểm tra rõ ràng và số liệu đo được từ hayweb.vn, dưới sự điều phối của người sáng lập Nguyễn Thế Quyền:

• Lighthouse di động 88 đến 92 + LCP 2,0 đến 3,0 giây + INP dưới 200 mili-giây + CLS dưới 0,1 — đo bằng PageSpeed Insights 2026-06 theo quý
• Đạt cả 22 điểm trong bản kiểm ưu tiên di động — khung nhìn + vùng chạm + chữ tiếng Việt + nút Zalo + ba chỉ số tốc độ đầy đủ
• Bảo mật Mozilla A+ 120 (observatory-api.mdn.mozilla.net) giữ nguyên sau khi xây theo ưu tiên di động — chứng minh ưu tiên di động không phá vỡ các tiêu đề bảo mật
• Nút bấm để mở Zalo và bấm để gọi trên thanh cố định, đã thử thật trên Samsung A50 + iPhone 12 + Oppo A18 — phản hồi khi chạm dưới 100 mili-giây
• Dấu tiếng Việt ế-ổ-ậ-ử-ữ-ỡ hiện chuẩn ở 320px (trường hợp xấu nhất) — font Inter bản tiếng Việt + Be Vietnam Pro
• Công cụ AI (ChatGPT và Perplexity) trích dẫn hayweb.vn từ bản hiển thị trên điện thoại — lập chỉ mục ưu tiên di động nhận diện đúng thực thể

Quy trình cụ thể HAYWEB dùng:

1. Phác bố cục cho điện thoại 375px trước mọi quyết định, máy tính bàn là phần nâng cấp dần.
2. Viết kiểu hiển thị ưu tiên di động với quy tắc min-width — không có quy tắc max-width trong mã chạy thật.
3. Tự động chạy Lighthouse trong quy trình đưa lên — mỗi lần cập nhật mã phải đạt Lighthouse di động ít nhất 85, thấp hơn là chặn không cho gộp mã.
4. Thử thật trên Samsung dòng A + iPhone 11/12 + Oppo A18 trước mỗi lần phát hành.
5. Quy trình kiểm từng cấu hình qua nguồn gốc chuẩn (hướng dẫn của Apple + Material Design 3 + Mozilla MDN) trước khi đưa vào khuôn mẫu.

Bắt đầu làm ưu tiên di động thế nào sau khi đọc xong bài này?

Bước 1 — Kiểm tra ngay, miễn phí, không cần đăng ký: Dùng kiemtra.hayweb.vn để đo Lighthouse di động và ba chỉ số tốc độ của trang web bạn trong 30 giây. Bạn sẽ thấy ngay LCP, INP, CLS trên điện thoại — và biết điểm xuất phát để ưu tiên sửa.

Bước 2 — Đọc thêm cụm bài liên quan: Bài này nằm trong cụm nền tảng SEO. Đọc tiếp Core Web Vitals March 2026: LCP 2 giây và INP 200ms để hiểu cách đo và cải thiện từng chỉ số, và bản kiểm kỹ thuật SEO 30 điểm 2026 cho bức tranh kỹ thuật toàn diện hơn.

Bước 3 — Tư vấn trực tiếp với người sáng lập: Nếu bạn muốn đánh giá cụ thể trang web của mình và lộ trình ưu tiên di động phù hợp với ngân sách, liên hệ qua hayweb.vn/contact — người sáng lập Nguyễn Thế Quyền trả lời trực tiếp, không qua khâu bán hàng trung gian, không phí tư vấn ban đầu. Xem thêm dịch vụ thiết kế web HAYWEB nếu bạn đang cần làm trang web mới chuẩn ưu tiên di động từ đầu.