Một lập trình viên mới chuyển sang SEO kỹ thuật thường mở vài công cụ kiểm tra tốc độ website cùng lúc. Kết quả mỗi nơi một khác, người mới dễ hoang mang không biết tin ai. Từng đứng đúng chỗ đó, mới nhận ra vấn đề không nằm ở công cụ dở, mà ở việc chưa hiểu từng công cụ đang đo cái gì.
Biết code là một lợi thế lớn. Đọc được đoạn JavaScript chặn render, hiểu vì sao một request gọi API bị chậm, đó là thứ dân SEO thuần không có sẵn. Nhưng lợi thế đó chỉ phát huy khi chọn đúng công cụ, và đọc đúng con số nó đưa ra.
Lập trình viên chuyển sang làm SEO kỹ thuật cần công cụ đo lường chính xác
Dân code khi đọc báo cáo tốc độ có một điểm mạnh rõ rệt. Họ nhìn vào waterfall, tức biểu đồ liệt kê từng file, từng request tải về theo thứ tự thời gian, và biết ngay chỗ nào đang nghẽn. Người làm content hay marketing thuần thường chỉ nhìn con số điểm cuối, ví dụ 65 hay 90, mà không hiểu vì sao nó ra như vậy.
Nhưng đây cũng là chỗ dễ vấp. Vì quen kiểu benchmark hiệu năng code chạy một lần lấy một số, nhiều bạn mang tư duy đó áp thẳng vào SEO kỹ thuật. Vấn đề là các công cụ đo tốc độ không đo cùng một kiểu dữ liệu. Có công cụ mô phỏng tức thời trên máy chủ ảo, gọi là lab data, tức dữ liệu phòng thí nghiệm, không phải người dùng thật đang trải nghiệm. Có công cụ khác lấy dữ liệu thật từ trình duyệt Chrome của hàng triệu người dùng, gọi là field data. Hai loại này thường lệch nhau, đôi khi lệch khá xa.
Một dự án bán lẻ giày thể thao từng gặp tình huống này: điểm Lighthouse, một dạng lab data, báo 92, nhìn rất đẹp. Nhưng dữ liệu field từ Search Console lại cho thấy phần lớn người dùng thật trải nghiệm ở mức trung bình, không hề tốt như con số phòng thí nghiệm. Lý do nằm ở chỗ lab test chạy trên mạng ổn định, máy cấu hình mạnh, còn người dùng thật phần nhiều vào bằng 4G chập chờn, máy đời cũ. Không phân biệt được hai loại dữ liệu này, người mới rất dễ báo cáo sai cho khách hàng hoặc cho sếp.
Một cách hay áp dụng là đo ít nhất ba lần, ở ba khung giờ khác nhau trong ngày, trước khi kết luận bất cứ điều gì. Một lần đo giữa đêm khi máy chủ rảnh rỗi không nói lên được trải nghiệm của người dùng vào giờ cao điểm.
Những công cụ kiểm tra tốc độ website phổ biến
Có hai nhóm công cụ kiểm tra tốc độ website hay dùng, chia theo mục đích. Nhóm đầu đo chi tiết theo từng thành phần của trang. Nhóm sau đo tổng thể, kèm gợi ý sửa.
GTmetrix và WebPageTest thuộc nhóm đầu. Hai công cụ này vẽ ra waterfall đầy đủ: file CSS nào tải trước, ảnh nào nặng nhất, script bên thứ ba nào, như mã theo dõi quảng cáo, khung chat trực tuyến, đang kéo dài thời gian tải. WebPageTest còn cho chọn địa điểm máy chủ test và loại thiết bị, giả lập gần với người dùng thật ở từng khu vực. Với dân code, đây là công cụ hợp gu nhất, vì đọc waterfall cũng giống đọc log debug, chỉ khác ngữ cảnh.
Google PageSpeed Insights thuộc nhóm thứ hai. Công cụ này chấm điểm tổng thể, đồng thời liệt kê từng vấn đề kèm hướng khắc phục cụ thể, ví dụ nén ảnh, hoãn tải đoạn JavaScript chưa cần dùng ngay. Điểm hay là nó gộp cả lab data lẫn field data, cụ thể là dữ liệu CrUX mà Google thu thập từ người dùng Chrome thật, trong cùng một báo cáo. Nói dễ hiểu, nó vừa cho biết trang chạy nhanh hay chậm trên giấy, vừa cho biết người dùng thật có thấy nhanh hay không.
Ba chỉ số hay gặp nhất khi đọc mấy báo cáo này, liệt kê lại cho dễ nhớ:
- LCP, thời gian hiển thị phần nội dung lớn nhất trên màn hình, ví dụ ảnh banner hay đoạn tiêu đề. Dưới 2,5 giây được xem là tốt.
- INP, độ trễ khi người dùng bấm, chạm vào trang mà giao diện phản hồi lại. Số càng thấp, thao tác càng mượt.
- CLS, mức độ trang bị xô lệch bố cục khi đang tải, kiểu ảnh chưa load xong làm chữ nhảy chỗ. Số càng gần 0 càng ổn định.
Gần đây nhiều công cụ còn tích hợp thêm lớp AI để gợi ý sửa lỗi tự động, thay vì chỉ liệt kê vấn đề rồi để người dùng tự mò. Có một bài viết riêng về công cụ AI đang hỗ trợ dân SEO nhìn vào tech stack theo góc nhìn developer, ai quan tâm mảng này đọc thêm cũng hay. Dù công cụ có thêm AI hay không, nguyên tắc chọn vẫn giữ nguyên: cần ít nhất một công cụ đo chi tiết theo thành phần, thêm một công cụ chấm điểm tổng thể kèm gợi ý. Chỉ dùng một công cụ duy nhất rất dễ thiếu góc nhìn.
Cách lập trình viên áp dụng kết quả vào tối ưu SEO kỹ thuật
Có báo cáo trong tay rồi, bước tiếp theo là biết sửa cái gì trước. Sai lầm thường gặp nhất ở các bạn mới là sửa theo đúng thứ tự liệt kê trên báo cáo, từ trên xuống dưới, thay vì theo mức ảnh hưởng thực tế tới người dùng.
Ưu tiên đúng nghĩa là nhìn vào chỉ số ảnh hưởng lớn nhất trước, thường là LCP và thời gian phản hồi máy chủ, hay gọi tắt là TTFB. Một ảnh banner nặng ba, bốn megabyte chưa nén thường gây hại nhiều hơn hẳn vài dòng CSS thừa. Sửa cái nặng ký trước, hiệu quả thấy rõ ngay lần đo tiếp theo.
Một dự án shop thời trang từng đo LCP ban đầu ở mức 4,8 giây, với người dùng đó là khoảng thời gian đủ để họ sốt ruột thoát trang trước khi ảnh sản phẩm kịp hiện ra. Chỉ bằng cách resize lại ảnh sản phẩm về đúng kích thước hiển thị và bật lazy load, tức ảnh nằm dưới màn hình chỉ tải khi người dùng cuộn tới, con số đó tụt xuống còn hơn hai giây. Không cần đụng vào code phức tạp, chỉ cần đúng thứ tự ưu tiên.
Sau nhiều dự án mới rút ra một điều: tốc độ dễ tối ưu hơn hẳn nếu nền móng website được dựng chuẩn ngay từ đầu. Site nào ngay từ lúc thiết kế website bán hàng đã tính toán kỹ cấu trúc ảnh và cách tải script, sau này thường chỉ cần chỉnh vài chỗ nhỏ là đạt tốc độ tốt. Ngược lại, site dựng ẩu từ đầu thì sửa tốc độ giống như vá một cái áo rách nhiều chỗ, vá xong chỗ này lại lòi ra chỗ khác.
Với những site có tích hợp thêm tính năng AI ở giao diện, như chatbot gợi ý sản phẩm hay ô tìm kiếm thông minh, việc giữ tốc độ càng cần để ý kỹ. Có một bài viết bàn kỹ hơn về việc frontend engineer giữ tốc độ không thành điểm yếu khi tích hợp AI, các bạn tham khảo thêm nếu site đang đi hướng đó. Nguyên tắc chung là thêm tính năng gì cũng đo lại tốc độ ngay sau đó, đừng đợi đến cuối dự án mới kiểm tra.
Sai lầm thứ hai hay gặp là tối ưu xong không đo lại, cứ nghĩ sửa rồi là xong việc. Mỗi lần sửa nên đo lại bằng đúng công cụ và đúng điều kiện của lần đo trước, để so sánh cho công bằng. Đổi công cụ đo giữa hai lần dễ khiến người mới tưởng nhầm là mình sửa sai, trong khi chỉ là hai công cụ đang đo theo hai chuẩn khác nhau.
Việc chọn công cụ đo tốc độ cũng có nét giống chuyện so sánh Power BI với Tableau cho việc phân tích dữ liệu từng bàn tới: không có công cụ nào đúng tuyệt đối cho mọi trường hợp, quan trọng là hiểu nó đang đo cái gì rồi chọn đúng cái phù hợp với việc đang làm.
Một site đạt trọn 100 điểm Lighthouse chưa chắc người dùng thật thấy nhanh hơn site 85 điểm, nếu field data chưa từng được nhìn tới. Điểm số đẹp trên báo cáo chỉ có ý nghĩa khi đối chiếu được với trải nghiệm thật của người dùng, và đó mới là thứ một lập trình viên làm SEO kỹ thuật nên bám vào qua từng dự án, thay vì chạy theo con số tuyệt đối.
