Core Web Vitals Mastery – Hành trình tối ưu Web Performance

“Cái đẹp của UI chỉ tồn tại khi người dùng còn kiên nhẫn chờ đợi. 5 giây là quá đủ để sự kiên nhẫn đó tan biến”

Chào mọi người, mình là Toàn Anh, hiện tại đang là Senior Frontend Developer tại công ty Supremetech. Mình đã từng đối mặt với một ứng dụng web mà tốc độ tải trang chủ trên di động hơn 5 giây – một con số thảm họa, đe dọa trực tiếp đến trải nghiệm người dùng.

Với thực chiến của mình, mình sẽ chia sẻ cách mà mình sử dụng để hạ con số đó xuống dưới 2 giây. Và lý giải Vì sao Web Performance: Yếu tố quyết định sống còn mà mọi FrontEnd Developer cần biết. Mình tin rằng chất lượng của một website được đo lường bằng trải nghiệm của người dùng.

Bối cảnh

Một website cho doanh nghiệp đang gặp vấn đề nghiêm trọng với tốc độ tải trang chủ, đặc biệt trên thiết bị di động.

• Thời gian ghi nhận được khoảng 5 giây mới hiển thị nội dung
• Gần 8 giây người dùng mới có thể tương tác được.

Nếu là người dùng, bạn có quay lại website này? Nếu là chủ của doanh nghiệp đó, bạn sẽ cảm thấy thế nào?

Phân tích và xác định vấn đề

Trước khi can thiệp vào code hay có bất kỳ sự cải tiến nào, mình đều bắt đầu với việc thu thập hiệu suất thông qua các công dụ đo lường phổ biến như Lighthouse hay PageSpeed Insight. Có 3 tiêu chí mà mình tập trung ưu tiên kiểm tra và xử lý.

Largest Contentful Paint (LCP)

Largest Contentful Paint là chỉ số xác định thời gian cần thiết để phần tử nội dung lớn nhất hiển thị trên màn hình (như hình ảnh, video hoặc một đoạn văn bản). Thông thường, đại đa số trường hợp là hình ảnh hoặc video nằm trong “Above the Fold” – phần màn hình hiển thị đầu tiên khi trang tải xong mà chưa cuộn xuống.

Chỉ số: Tốt: dưới 2.5 giây – Trung bình: từ 2.5 giây đến 4 giây – Kém: trên 4 giây

Time to Interactive (TTI)

Time to Interactive là chỉ số xác định thời gian để trang web mà người dùng có thể tương tác được. Thông thường nguyên nhân chủ yếu là do kích thước tài nguyên lớn (hình ảnh, CSS hay Javascript) làm tăng thời gian tải tài nguyên, chặn quá trình hiển thị trang web.

Chỉ số: Tốt: dưới 3.8 giây – Trung bình: từ 3.8 giây đến 7.3 giây – Kém: trên 7.3 giây

Cumulative Layout Shift (CLS)

Cumulative Layout Shift Là chỉ số xác định sự ổn định của giao diện trang web khi tải, nó đo lường sự thay đổi bố cục bất ngờ xảy ra. Thông thường sẽ do những nội dung xuất hiện sau (hình ảnh trước và sau khi tải), đẩy các phần tử khác ở trang xuống.

Chỉ số: Tốt: dưới 0.1 (10%) – Trung bình: từ 0.1 đến 0.25 giây – Kém: trên 0.25 giây

Triển khai các giải pháp kỹ thuật

Tối ưu Javascript: Từ Monolithic sang Modular

Kỹ thuật:

• Coding splitting và Lazy-loading: Chia nhỏ Javascript code thành các chunks nhỏ hơn cho mỗi trang và chỉ tải khi cần thiết (thay vì Monolithic tải toàn bộ code javascript cùng một lúc)
• Dynamic imports: kết hợp với React.lazy và Suspense (hoặc tương đương trong Angular/Vue) để chỉ tải module code khi thực sự cần thiết.

Tối ưu hình ảnh: Giảm kích thước và Lazy-loading image

Hình ảnh là kẻ thù số một của Performance nếu không được quản lý đúng cách

Kỹ thuật:

• Lazy-loading images: Hãy trì hoãn lại việc tải những hình ảnh không nằm trong khung nhìn ban đầu “Below the Fold” thông qua thuộc tính loading=lazy của <img> hoặc Intersection Observer API
• Tối ưu định dạng và kích thước: Chuyển sang các định dạng phù hợp và có kích thước nhẹ hơn như .webp. Sử dụng thuộc tính srcset và sizes của <img> để trình duyệt chọn phiên bản của hình ảnh phù hợp với viewport của thiết bị.
• Ngăn chặn Layout Shift: Luôn định nghĩa kích thước (width và height) cho tất cả hình ảnh và video, mục đích để “giữ chỗ” để khi hình ảnh và video tải xong sẽ xuất hiện không làm các phần tử khác nhảy lên/xuống.

Tối ưu Rendering: Ưu tiên các nội dung xuất hiện đầu tiên

Việc tải các tài nguyên làm chặn quá trình hiển thị, nhất là các tài nguyên không nằm ở “Above the Fold”

Kỹ thuật:

• Inlining Critical CSS: Có thể trích xuất CSS cần thiết cho phần “Above the Fold” và nhúng nó trực tiếp vào HTML.
• Resource Hinting: Sử dụng Resource Hinting như <link rel=”preload”> để ưu tiên tải các tài nguyên cần thiết cho LCP.

Kết quả

Sau khi trải qua quá trình tối ưu này với khoảng 60 pages của website doanh nghiệp như bối cảnh mình nói, kết quả:

• Từ ~50/60 pages có điểm Performance chưa tới 50, bây giờ tất cả các pages đã có điểm vượt ngưỡng 90.
• Các chỉ số LCP, TTI và CLS từ đỏ (kém) đã hoá xanh (tốt).

Điều đúc kết lại

Hiệu suất là một quy trình không phải làm một lần mà cần đo đạc và cải tiến với chu kỳ nhất định của website

Đặt trải nghiệm của người dùng để quyết định mọi kỹ thuật trong lúc viết code, phải tự hỏi “Code như này có làm tăng trải nghiệm người dùng không, có làm khách hàng hài lòng không?”

Hãy nhớ, công việc của chúng ta không phải làm cho code chạy được, mà là làm cho nó chạy hiệu quả.

Chúc các bạn code nhanh và tối ưu hiệu suất website càng nhanh hơn!