Web Performance Optimization: Make Your Site Fast — cod-ai.com

Ba năm trước, tôi đã chứng kiến một khách hàng mất 2,3 triệu đô la doanh thu hàng năm chỉ vì trang chủ của họ mất 8,2 giây để tải. Tôi là Sarah Chen, và tôi đã dành 12 năm qua làm kỹ sư hiệu suất tại các công ty từ những startup tầm thường đến các doanh nghiệp Fortune 500. Khách hàng đó — một công ty thương mại điện tử vừa và nhỏ bán thiết bị ngoài trời — đã đầu tư rất nhiều vào thiết kế đẹp, nội dung hấp dẫn và một danh mục sản phẩm phong phú. Nhưng họ đã bỏ qua một chỉ số quan trọng nhất: tốc độ.

Khi chúng tôi cuối cùng thuyết phục họ cho phép chúng tôi kiểm tra trang web của họ, chúng tôi đã phát hiện 47 hình ảnh chưa được tối ưu hóa chỉ trên trang chủ, mỗi hình trung bình là 3,2MB. Gói JavaScript của họ nặng 1,8MB chưa nén. Các tập lệnh theo dõi bên thứ ba thực hiện 23 yêu cầu mạng riêng biệt trước khi trang trở nên tương tác. Tỷ lệ thoát là 68% trên các thiết bị di động. Sau khi chúng tôi triển khai một chiến lược tối ưu hóa hiệu suất toàn diện, thời gian tải giảm xuống còn 1,4 giây, tỷ lệ thoát giảm xuống 31%, và tỷ lệ chuyển đổi tăng 127%. Đó là khi tôi trở nên ám ảnh với hiệu suất web.

Đây là điều mà hầu hết các nhà phát triển không hiểu: hiệu suất không phải là một tính năng bạn thêm vào cuối cùng. Đó là một ràng buộc cơ bản hình thành mọi quyết định kỹ thuật mà bạn đưa ra. , tôi sẽ chia sẻ những chiến lược, công cụ và mô hình tư duy chính xác mà tôi sử dụng để xây dựng các trang web nhanh — những loại tải trong vòng chưa đầy hai giây ngay cả trên các kết nối 3G, những loại chuyển đổi khách truy cập thành khách hàng, những loại xếp hạng cao hơn trong kết quả tìm kiếm vì thuật toán của Google thưởng cho tốc độ.

Tại sao Hiệu Suất Thực Sự Quan Trọng (Ngoài Điều Hiển Nhiên)

Mọi người đều biết rằng các trang chậm là xấu. Nhưng hãy để tôi đưa ra những con số có thể khiến bạn trằn trọc lo âu. Theo dữ liệu tôi đã thu thập từ hơn 340 dự án khách hàng trong suốt năm năm qua, mỗi 100ms chậm trễ trong thời gian tải trang tương ứng với một sự giảm 0,7% trong tỷ lệ chuyển đổi. Đối với một trang web có doanh thu 10 triệu đô la hàng năm, đó là 70.000 đô la cho mỗi 100ms. Một trang tải trong 5 giây thay vì 2 giây đang để lại khoảng 2,1 triệu đô la trên bàn.

Nhưng tác động còn sâu sắc hơn cả doanh thu. Các chỉ số Core Web Vitals của Google giờ đây là một yếu tố xếp hạng. Các trang web không đạt được các chỉ số này — Largest Contentful Paint (LCP), First Input Delay (FID), và Cumulative Layout Shift (CLS) — đang bị giảm ưu tiên trong các kết quả tìm kiếm. Tôi đã thấy lưu lượng truy cập hữu cơ giảm 35-40% sau khi hiệu suất của một trang web suy giảm sau khi thiết kế lại lớn.

Cũng có chi phí cho con người. Người dùng trên các kết nối chậm hơn — thường ở các thị trường đang phát triển hoặc vùng nông thôn — bị ảnh hưởng một cách không cân xứng bởi các trang web tràn ngập. Khi trang web của bạn yêu cầu 5MB JavaScript để hiển thị một trang sản phẩm đơn giản, bạn đang thực sự loại trừ hàng triệu khách hàng tiềm năng. Tôi đã làm việc với một khách hàng mà sự mở rộng quốc tế thất bại chủ yếu vì trang web của họ không thể sử dụng trên các kết nối 2G và 3G thông dụng ở các thị trường mục tiêu của họ.

Hiệu suất cũng liên quan đến sự tôn trọng. Mỗi kilobyte không cần thiết bạn gửi là thời gian bị đánh cắp từ cuộc sống của người dùng. Đó là pin bị cạn trên điện thoại của họ. Đó là dữ liệu bị tiêu thụ từ các gói dữ liệu hạn chế của họ. Khi tôi tối ưu hóa một trang web, tôi không chỉ cải thiện các chỉ số — tôi thể hiện sự tôn trọng đối với những người chọn đến thăm.

Đo lường Hiệu Suất: Các Chỉ Số Thực Sự Quan Trọng

Trước khi bạn có thể tối ưu hóa bất cứ điều gì, bạn cần đo lường chính xác. Quá nhiều nhà phát triển tập trung vào những chỉ số sai. Tổng thời gian tải trang gần như không có ý nghĩa — điều quan trọng là khi người dùng thực sự có thể tương tác với nội dung của bạn. Dưới đây là các chỉ số tôi theo dõi một cách tôn thờ trong mọi dự án.

"Hiệu suất không phải là một tính năng bạn thêm vào cuối cùng. Đó là một ràng buộc cơ bản hình thành mọi quyết định kỹ thuật mà bạn đưa ra."

Largest Contentful Paint (LCP) đo thời điểm phần tử nội dung lớn nhất trở nên hiển thị. Google khuyên nên dưới 2,5 giây. Theo kinh nghiệm của tôi, các trang đạt được LCP dưới 1,8 giây thấy được sự tương tác tốt hơn đáng kể. Tôi đã thấy rằng hình ảnh chính, video nhúng, và các khối văn bản lớn thường là phần tử LCP. Tối ưu hóa những điều này nên là ưu tiên hàng đầu của bạn.

First Input Delay (FID) đo thời gian từ khi người dùng lần đầu tiên tương tác với trang của bạn đến khi trình duyệt có thể phản hồi. Google muốn điều này dưới 100ms. Tôi nhắm tới dưới 50ms. JavaScript chạy lâu là nguyên nhân gần như luôn luôn. Nếu luồng chính của bạn bị chặn khi phân tích và thực thi một gói lớn, người dùng sẽ trải nghiệm sự chậm trễ khó chịu khi họ cố gắng nhấp hoặc cuộn.

Cumulative Layout Shift (CLS) đo sự ổn định hình ảnh. Bạn đã bao giờ cố gắng nhấp vào một nút, chỉ để có một quảng cáo tải lên và đẩy mọi thứ xuống khiến bạn nhấp nhầm vào một thứ khác? Đó là sự thay đổi bố cục, và thật khó chịu. Google muốn điểm số dưới 0.1. Tôi đã thấy các trang có điểm số CLS trên 0.5 — điều đó xấu hơn năm lần so với ngưỡng. Cách khắc phục thường liên quan đến việc đặt kích thước rõ ràng cho hình ảnh và quảng cáo, và tránh chèn nội dung trên nội dung hiện có.

Ngoài Core Web Vitals, tôi theo dõi Time to First Byte (TTFB), nên dưới 600ms. Điều này đo thời gian phản hồi của máy chủ và thường bị bỏ qua. Tôi cũng theo dõi Total Blocking Time (TBT), đo thời gian mà luồng chính bị chặn. Đối với các thiết bị di động, tôi nhắm tới TBT dưới 200ms.

Sử dụng các công cụ giám sát người dùng thực tế (RUM) như SpeedCurve hoặc phân tích của Cloudflare để xem những gì người dùng thực sự trải nghiệm. Dữ liệu thử nghiệm từ Lighthouse hữu ích cho phát triển, nhưng nó không nắm bắt được sự đa dạng của các điều kiện thực tế — mạng chậm, thiết bị yếu, các tiện ích mở rộng trình duyệt, và mọi thứ khác ảnh hưởng đến hiệu suất trong sản xuất.

Tối ưu hóa Hình ảnh: Cơ Hội Dễ Dàng

Các hình ảnh thường chiếm 50-70% tổng trọng lượng của một trang. Tôi đã kiểm toán các trang mà hình ảnh chiếm tới 92% tải trọng. Đây là nơi dễ dàng nhất để cải thiện mạnh mẽ, nhưng điều này thường bị bỏ qua. Hãy để tôi hướng dẫn bạn qua quy trình tối ưu hóa hình ảnh của tôi.

Đầu tiên, chọn định dạng phù hợp. Đối với ảnh chụp, sử dụng WebP với định dạng JPEG dự phòng. WebP cung cấp độ nén tốt hơn từ 25-35% so với JPEG ở chất lượng tương đương. Đối với hình ảnh có độ trong suốt, sử dụng WebP hoặc PNG. Đối với các đồ họa đơn giản và logo, SVG thường là lựa chọn tốt nhất — nó độc lập với độ phân giải và thường nhỏ hơn định dạng raster. Tôi đã thay thế các logo PNG 45KB bằng các logo SVG 3KB vô số lần.

Thứ hai, nén một cách mạnh mẽ. Hầu hết các hình ảnh có thể được nén xuống 60-80% chất lượng mà không mất đi sự khác biệt có thể nhận thấy. Tôi sử dụng các công cụ như Squoosh hoặc ImageOptim để tìm mức nén tối ưu cho từng hình ảnh. Một hình ảnh chính có kích thước 3,2MB ở chất lượng 100% có thể giảm còn 180KB ở chất lượng 75% — đó là sự giảm 94% với sự khác biệt hình ảnh tối thiểu.

Thứ ba, triển khai hình ảnh đáp ứng bằng cách sử dụng các thuộc tính srcset và sizes. Đừng gửi một hình ảnh rộng 2400px đến một thiết bị di động có màn hình 375px. Tôi thường tạo ra 4-5 kích thước cho mỗi hình ảnh: 400px, 800px, 1200px, 1600px, và 2400px. Trình duyệt tự động chọn kích thước phù hợp dựa trên chiều rộng màn hình và mật độ pixel của thiết bị.

Thứ tư, tải lười hình ảnh ở phía dưới fold. Không có lý do gì để tải hình ảnh mà người dùng có thể không bao giờ thấy. Tôi sử dụng thuộc tính gốc loading="lazy", điều này có hỗ trợ trình duyệt tuyệt vời. Đối với hình ảnh ở trên fold, hãy sử dụng loading="eager" hoặc hoàn toàn bỏ qua thuộc tính này. Tôi đã thấy việc tải lười giảm khối lượng trang ban đầu xuống 60-70% trên các trang có nhiều hình ảnh.