Skip to content
EasyAlo
9 phút đọc

Hiệu năng là một phần của thiết kế

Tốc độ không phải phần dọn dẹp sau khi giao diện đã hoàn tất. Đó là một chuỗi quyết định về nội dung, hình ảnh, font, chuyển động và mã nguồn, bắt đầu ngay từ bản thiết kế đầu tiên.

Nhóm sản phẩm so sánh thời gian tải, Core Web Vitals và ngân sách dung lượng trên máy tính và điện thoại
web · performance

Người dùng không tách giao diện ra khỏi tốc độ. Điều họ cảm nhận là nội dung chính hiện lên sớm hay muộn, nút bấm có phản hồi ngay hay đứng im, và trang có bị nhảy đúng lúc họ vừa định chạm hay không.

Vì vậy hiệu năng không thể chỉ là một vòng tối ưu ở cuối dự án. Đến thời điểm đó, hình ảnh, font, animation và cấu trúc trang đã trở thành quyết định thương hiệu; việc cắt bớt một thành phần nặng lúc ấy khó hơn nhiều so với việc đặt giới hạn ngay từ đầu.

1. Chuyển chỉ số kỹ thuật thành cảm nhận của người dùng

Core Web Vitals cho chúng ta một ngôn ngữ chung để mô tả ba cảm nhận: nội dung chính có hiện kịp không, thao tác có được phản hồi không và bố cục có ổn định không. Ngưỡng “tốt” hiện nay là LCP dưới 2,5 giây, INP dưới 200 mili giây và CLS dưới 0,1, tính ở phân vị thứ 75 của lượt xem.

Những con số này chỉ phát huy tác dụng khi gắn với một màn hình và một hành vi cụ thể. LCP của trang sản phẩm thường là ảnh hoặc khối tiêu đề lớn. INP kém thường do bộ lọc phải chạy quá nhiều mã. Còn CLS xuất hiện khi banner, font hay ảnh về muộn và đẩy trượt chính nút mà người dùng sắp bấm.

  • LCP: thời điểm nội dung chính hiện ra, không phải lúc mọi tài nguyên tải xong.
  • INP: độ trễ người dùng cảm nhận sau mỗi tương tác, tính suốt cả phiên.
  • CLS: mức xê dịch ngoài ý muốn của phần nội dung đang hiển thị.

2. Đặt hạn mức trước khi chọn giải pháp

Hạn mức hiệu năng là một giới hạn được đặt ra có chủ đích: dung lượng ảnh đầu trang, tổng JavaScript, số bộ font hoặc thời gian mục tiêu trên một cấu hình thiết bị và đường mạng đại diện. Nó buộc cả đội trao đổi bằng những đánh đổi thật: muốn thêm video nền thì phải bỏ gì, hoặc dời gì xuống tải sau?

Không có con số nào đúng cho mọi website. Trang nội dung, cửa hàng trực tuyến và ứng dụng nghiệp vụ có trọng tâm khác nhau. Hãy chọn 3–5 trang quan trọng, đo hiện trạng hoặc chọn một đối chuẩn tốt, rồi đặt hạn mức đủ chặt để nó thật sự chi phối được quyết định.

  • Trang chủ: nội dung hiện ra đầu tiên và đường dẫn tới hành động chính.
  • Trang danh sách: tốc độ phản hồi khi lọc, sắp xếp và chuyển trang.
  • Trang chi tiết: ảnh chính, các biến thể và thao tác thêm vào giỏ.
  • Biểu mẫu: tốc độ nhập liệu, kiểm tra dữ liệu và phản hồi sau khi gửi.
Hạn mức chỉ có tác dụng khi được kiểm tra trong lúc build hoặc trước khi phát hành. Một con số nằm trong tài liệu mà không chi phối được quyết định nào thì mới chỉ là mong muốn.

3. Năm quyết định thiết kế ảnh hưởng trực tiếp đến tốc độ

Phần lớn vấn đề không bắt đầu từ một đoạn mã “chậm”, mà từ một quyết định hình ảnh không kèm giới hạn nào: hero dùng video 4K, sáu kiểu font, animation chạy theo thao tác cuộn. Mỗi lựa chọn đều có cái giá về tải, về xử lý và về độ ổn định của bố cục.

Thiết kế tốt không đồng nghĩa với việc loại bỏ hết chuyển động hay chỉ dùng ảnh nhỏ. Đó là biết chỗ nào cần gây ấn tượng, chỗ nào cần phản hồi tức thì, rồi dồn hạn mức vào đúng những chỗ đó.

  • Hình ảnh: chốt khung cắt, kích thước hiển thị, định dạng và mức nén trước khi đưa lên CMS.
  • Chữ: giảm số họ font và số trọng lượng; preload đúng file thật sự xuất hiện ở màn hình đầu.
  • Bố cục: giữ sẵn tỷ lệ cho ảnh, quảng cáo và nội dung về sau để trang không bị nhảy.
  • Chuyển động: ưu tiên transform và opacity, tắt hiệu ứng ngoài màn hình và tôn trọng reduced motion.
  • Thành phần bên thứ ba: chỉ tải chat, heatmap hay quảng cáo khi giá trị chúng mang lại lớn hơn cái giá phải trả.

4. Đo trong phòng lab và đo ngoài thực tế

Lighthouse và devtools giúp tái hiện vấn đề trong điều kiện kiểm soát được, rất tiện để phát hiện ảnh quá nặng, mã chặn luồng chính hay bố cục thiếu kích thước. Nhưng một lần chạy không thể đại diện cho thiết bị, đường mạng và thói quen sử dụng của tất cả người dùng.

Dữ liệu thực tế, chẳng hạn Chrome UX Report hoặc số đo từ người dùng thật, cho biết trải nghiệm ở phân vị thứ 75 trong một khoảng thời gian. Khi hai nguồn cho kết quả khác nhau, hãy dùng số liệu trong lab để chẩn đoán và số liệu thực tế để quyết định nên xử lý vấn đề nào trước.

  • Đo theo từng mẫu trang và từng loại thiết bị, thay vì chỉ nhìn điểm trung bình toàn site.
  • Đo trước và sau mỗi thay đổi lớn về giao diện, nội dung hay thành phần bên thứ ba.
  • Lưu cả con số lẫn bối cảnh: phiên bản, mạng, thiết bị, URL và thời điểm.

5. Đưa hiệu năng vào nhịp làm việc của đội ngũ

Ở giai đoạn discovery, hãy chốt trang nào và hành vi nào là quan trọng. Ở khâu thiết kế, ghi rõ tài sản, trạng thái tải và vùng giữ chỗ. Trong quá trình phát triển, để hệ thống tự kiểm tra hạn mức. Trước phát hành, đo trên thiết bị thật. Sau phát hành, theo dõi dữ liệu người dùng.

Nhưng quan trọng nhất vẫn là có người đứng ra quyết định. Khi chỉ số xấu đi, cả đội cần biết ai có thẩm quyền hoãn một script marketing, yêu cầu nén lại ảnh hay đổi cách hiển thị, thay vì để vấn đề treo lơ lửng giữa thiết kế, kỹ thuật và nội dung.

Đích đến không phải điểm 100 trên mọi công cụ, mà là giữ cho những trải nghiệm quan trọng luôn nhanh và ổn định, ngay cả khi nội dung, chiến dịch và sản phẩm liên tục thay đổi.

Checklist hiệu năng trước khi phát hành

  • Đã xác định phần tử LCP và cách tải nó trên từng mẫu trang.
  • Ảnh đã đúng kích thước, tỷ lệ, định dạng và mức nén.
  • Font chỉ giữ lại những bộ và những trọng lượng thật sự sử dụng.
  • Ảnh, embed và nội dung tải muộn đều có vùng giữ chỗ.
  • Các tương tác chính đã được thử trên một điện thoại tầm trung.
  • Mọi script bên thứ ba đều có người sở hữu và lý do kinh doanh rõ ràng.
  • Có số đo trong lab trước khi phát hành và kế hoạch theo dõi dữ liệu thật sau đó.

Nguồn tham khảo

Bước tiếp theo

Biến góc nhìn thành hành động.