Tăng tốc độ tải trang: Quy trình đo–sửa–đo

Tăng tốc độ tải trang hiệu quả không bắt đầu bằng việc cài thêm một tiện ích hoặc cố đẩy điểm PageSpeed lên mức tuyệt đối. Cách làm đáng tin cậy hơn là xác định đúng trang cần kiểm tra, lưu số liệu ban đầu, xử lý nguyên nhân có ảnh hưởng lớn rồi đo lại trong cùng điều kiện.

Với trang chủ, báo cáo PageSpeed có thể cung cấp manh mối về hình ảnh đầu trang, tài nguyên chặn hiển thị, JavaScript, phông chữ, bộ nhớ đệm và thời gian phản hồi máy chủ. Tuy nhiên, mỗi phát hiện chỉ nên được xem là một giả thuyết kỹ thuật cho đến khi được kiểm tra trên website thực tế.

Bài viết này không công bố điểm số hoặc mức cải thiện cụ thể của hasontech.vn vì không có báo cáo đo trước và sau kèm bằng chứng trong dữ liệu được cung cấp. Thay vào đó, nội dung tập trung vào quy trình có thể kiểm chứng, giúp tránh biến một kết quả thử nghiệm đơn lẻ thành tuyên bố thiếu căn cứ.

Hiểu đúng báo cáo PageSpeed trước khi tối ưu

PageSpeed thường cung cấp hai nhóm dữ liệu khác nhau. Việc phân biệt chúng giúp bạn không sửa website dựa trên một con số thiếu ngữ cảnh.

Dữ liệu thực tế và dữ liệu thử nghiệm

• Dữ liệu thực tế của người dùng: phản ánh trải nghiệm đã được ghi nhận trên trình duyệt Chrome trong một khoảng thời gian tổng hợp. Dữ liệu có thể không xuất hiện nếu URL hoặc toàn bộ website chưa có đủ mẫu.
• Dữ liệu thử nghiệm: được tạo trong một lần chạy mô phỏng với cấu hình thiết bị và mạng xác định. Nhóm dữ liệu này phù hợp để chẩn đoán nhưng có thể dao động giữa các lần đo.

Không nên dùng một lần kiểm tra trên máy tính để kết luận trải nghiệm của toàn bộ người dùng di động. Kết quả còn chịu ảnh hưởng bởi vị trí máy chủ, tuyến mạng, bộ nhớ đệm, thiết bị, tài nguyên bên thứ ba và trạng thái hệ thống tại thời điểm đo.

Nếu khách hàng chính ở Việt Nam, điều kiện kiểm tra nên đại diện cho người truy cập tại Việt Nam. Với website phục vụ tập trung tại Hà Nội hoặc Thành phố Hồ Chí Minh, vị trí máy chủ kiểm thử và khoảng cách đến máy chủ gốc cũng cần được ghi lại để tránh so sánh hai lần đo ở hai khu vực khác nhau.

Ba chỉ số Core Web Vitals cần theo dõi

Chỉ số	Ngưỡng được xem là tốt	Ý nghĩa
LCP	Không quá 2,5 giây	Thời gian hiển thị phần nội dung lớn nhất trong vùng nhìn thấy
INP	Không quá 200 mili giây	Khả năng phản hồi khi người dùng tương tác
CLS	Không quá 0,1	Mức độ dịch chuyển bố cục ngoài dự kiến

Các ngưỡng này được đánh giá theo dữ liệu thực tế ở phân vị thứ 75. Trong môi trường thử nghiệm, Total Blocking Time thường được dùng để chẩn đoán tác vụ JavaScript kéo dài, nhưng không đồng nghĩa hoàn toàn với INP.

Ngoài ba chỉ số trên, các tín hiệu như TTFB, FCP, tổng dung lượng tài nguyên và chuỗi yêu cầu mạng giúp truy tìm nguyên nhân. Chúng không nên được đọc tách rời khỏi cấu trúc thực tế của trang.

Bạn có thể đối chiếu cách sử dụng nhiều công cụ kiểm tra tốc độ website để tránh phụ thuộc vào một báo cáo duy nhất.

Thiết lập số liệu gốc trước khi sửa website

Một vòng tối ưu chỉ có giá trị khi có số liệu gốc để so sánh. Trước khi thay đổi mã nguồn, cấu hình máy chủ hoặc nội dung, hãy xác định rõ phạm vi đo.

Chọn đúng nhóm URL

Không nên chỉ kiểm tra trang chủ rồi suy rộng cho toàn bộ website. Tối thiểu cần xem xét các mẫu trang có cấu trúc khác nhau:

• Trang chủ có banner, menu, nội dung giới thiệu và nhiều liên kết nội bộ.
• Trang dịch vụ hoặc landing page có hình ảnh lớn và biểu mẫu.
• Bài viết dài có nhiều ảnh, mục lục hoặc nội dung nhúng.
• Trang chuyển đổi quan trọng như đăng ký, liên hệ hoặc đặt hàng.

Nếu nhiều URL dùng chung một mẫu giao diện, có thể chọn một URL đại diện. Khi vấn đề nằm ở mẫu trang, một thay đổi đúng chỗ sẽ có tác động rộng hơn so với chỉnh từng bài riêng lẻ.

Ghi lại điều kiện kiểm tra

Mỗi lần đo nên lưu các thông tin sau:

• URL chính xác và phiên bản giao thức được kiểm tra.
• Thời điểm đo.
• Thiết bị di động hay máy tính.
• Vị trí và cấu hình kiểm thử nếu công cụ cho phép lựa chọn.
• Trạng thái đăng nhập, cookie và bộ nhớ đệm.
• Chỉ số chính cùng danh sách phát hiện kỹ thuật.
• Ảnh chụp, tệp xuất báo cáo hoặc đường dẫn báo cáo có thể mở lại.
• Phiên bản mã nguồn hoặc thời điểm triển khai tương ứng.

Nên chạy nhiều lần trong cùng điều kiện và sử dụng giá trị trung vị để giảm ảnh hưởng của biến động ngẫu nhiên. Không so sánh lần đo di động trước khi sửa với lần đo máy tính sau khi sửa.

Kiểm tra URL chuẩn và chuyển hướng

Trước khi phân tích hiệu suất, cần chắc chắn công cụ đang đo đúng URL cuối cùng. Chuỗi chuyển hướng từ HTTP sang HTTPS, từ phiên bản có www sang không www hoặc qua nhiều đường dẫn trung gian có thể tạo thêm độ trễ.

Quy trình kiểm tra chuyển hướng HTTP sang HTTPS giúp xác nhận người dùng và trình thu thập dữ liệu được đưa đến đúng phiên bản trang bằng đường đi ngắn, nhất quán.

Cách ưu tiên các phát hiện ảnh hưởng lớn

Danh sách đề xuất trong PageSpeed không phải danh sách công việc bắt buộc. Một cảnh báo có mức tiết kiệm ước tính cao chưa chắc là nguyên nhân chính của trải nghiệm kém trên mọi thiết bị.

Có thể ưu tiên theo bốn tiêu chí:

1. Ảnh hưởng đến nội dung đầu tiên người dùng cần thấy: hình ảnh LCP, tiêu đề chính, menu và nút hành động thường quan trọng hơn nội dung cuối trang.
2. Phạm vi tác động: lỗi trong giao diện dùng chung có thể ảnh hưởng nhiều URL hơn lỗi chỉ xuất hiện trong một bài viết.
3. Mức độ kiểm soát: tài nguyên do website tự quản lý thường dễ tối ưu hơn mã nhúng từ dịch vụ bên ngoài.
4. Rủi ro khi thay đổi: trì hoãn JavaScript hoặc loại bỏ CSS có thể làm hỏng menu, biểu mẫu, bộ lọc và theo dõi chuyển đổi.

Một thứ tự xử lý thực tế thường là:

• Khắc phục lỗi chức năng, chuyển hướng và phản hồi máy chủ bất thường.
• Tối ưu tài nguyên LCP và nội dung trong vùng nhìn thấy đầu tiên.
• Giảm tài nguyên chặn hiển thị.
• Hạn chế tác vụ JavaScript dài và mã bên thứ ba không cần thiết.
• Ổn định kích thước ảnh, quảng cáo và khối nội dung để giảm CLS.
• Tối ưu các tài nguyên nằm dưới màn hình đầu tiên.

Nếu phần tử LCP là ảnh banner, hãy xử lý chính ảnh đó trước khi nén hàng loạt các ảnh nhỏ ở cuối trang. Nếu LCP là một khối văn bản, nguyên nhân có thể nằm ở phông chữ, CSS hoặc thời gian phản hồi máy chủ chứ không phải hình ảnh.

Các bước tăng tốc độ tải trang thực tế

Tối ưu hình ảnh theo vị trí sử dụng

Hình ảnh thường là nhóm tài nguyên có dung lượng đáng kể, đặc biệt trên trang chủ và landing page. Tuy nhiên, tối ưu ảnh không chỉ là nén tệp.

• Xuất ảnh theo kích thước gần với kích thước hiển thị thực tế.
• Tạo nhiều phiên bản ảnh và dùng srcset để trình duyệt chọn tệp phù hợp với màn hình.
• Ưu tiên định dạng ảnh hiện đại khi hệ thống và trình duyệt mục tiêu hỗ trợ.
• Khai báo width và height, hoặc tỷ lệ khung hình, để trình duyệt giữ chỗ trước khi ảnh tải xong.
• Áp dụng tải lười cho ảnh nằm ngoài màn hình đầu tiên.
• Không tải lười ảnh LCP nếu việc đó khiến ảnh quan trọng được phát hiện muộn.
• Kiểm tra ảnh nền trong CSS vì chúng có thể được tải muộn hơn ảnh trong HTML.
• Tránh dùng một ảnh dung lượng lớn cho cả máy tính và điện thoại khi bố cục hai thiết bị khác nhau.

Với trang đích, hướng dẫn về cách chọn kích thước và tối ưu ảnh landing page giúp cân bằng độ sắc nét, tỷ lệ khung hình và dung lượng truyền tải.

Giảm CSS chặn hiển thị

CSS cần thiết cho màn hình đầu tiên nên được tải sớm, trong khi phần không cần ngay có thể trì hoãn. Các hướng xử lý gồm:

• Loại bỏ CSS không còn được sử dụng sau khi kiểm tra trên các mẫu trang.
• Tách CSS theo thành phần hoặc theo loại trang thay vì gửi toàn bộ thư viện cho mọi URL.
• Thu gọn tệp khi quy trình triển khai cho phép.
• Hạn chế nhiều lớp CSS ghi đè lẫn nhau.
• Chỉ đưa phần CSS thực sự quan trọng vào HTML nếu cách làm đó không khiến mã lặp lại quá nhiều hoặc khó bảo trì.

Không nên xóa CSS chỉ vì công cụ đánh dấu là chưa được dùng trong lần tải đầu. Menu mở rộng, hộp thoại, tab và trạng thái sau tương tác có thể cần các quy tắc chưa xuất hiện trong ảnh chụp ban đầu.

Kiểm soát JavaScript và tác vụ trên luồng chính

JavaScript quá nhiều có thể làm chậm quá trình hiển thị và phản hồi tương tác. Hãy bắt đầu bằng việc lập danh sách script đang tải, mục đích của từng script và trang nào thực sự cần chúng.

• Chỉ tải script theo loại trang hoặc tính năng cần sử dụng.
• Dùng defer cho script không cần chạy trước khi HTML được phân tích xong.
• Dùng async khi script độc lập và không phụ thuộc thứ tự thực thi.
• Chia nhỏ gói mã lớn nếu người dùng chỉ cần một phần chức năng ở lần tải đầu.
• Giảm tác vụ dài bằng cách chia công việc thành các phần nhỏ.
• Trì hoãn tiện ích trò chuyện, bản đồ, video nhúng hoặc mã theo dõi không thiết yếu cho đến khi phù hợp với mục đích sử dụng.
• Gỡ mã trùng lặp và thư viện không còn được dùng.

Sau mỗi thay đổi, phải kiểm tra lại menu, tìm kiếm, biểu mẫu, giỏ hàng, nút gọi điện, đo lường chuyển đổi và các chức năng phụ thuộc JavaScript.

Cải thiện máy chủ, bộ nhớ đệm và phân phối nội dung

Nếu tài liệu HTML ban đầu phản hồi chậm, tối ưu hình ảnh ở trình duyệt sẽ không giải quyết hoàn toàn vấn đề. Cần kiểm tra:

• Thời gian xử lý ứng dụng và truy vấn cơ sở dữ liệu.
• Bộ nhớ đệm toàn trang cho nội dung phù hợp.
• Bộ nhớ đệm trình duyệt cho tài nguyên tĩnh có phiên bản.
• Nén nội dung văn bản trong quá trình truyền.
• Số lượng chuyển hướng trước khi đến URL cuối.
• Vị trí máy chủ so với nhóm người dùng chính.
• Khả năng phân phối ảnh, CSS và JavaScript qua mạng phân phối nội dung nếu website phục vụ nhiều khu vực.

Chính sách bộ nhớ đệm cần phù hợp với loại nội dung. Không nên lưu bản cũ quá lâu đối với trang cá nhân hóa, giỏ hàng hoặc dữ liệu thay đổi liên tục.

Tối ưu phông chữ

Phông chữ có thể trì hoãn việc hiển thị văn bản hoặc làm bố cục thay đổi sau khi tệp tải xong.

• Chỉ giữ các kiểu chữ và độ đậm thực sự được dùng.
• Ưu tiên định dạng phông chữ phù hợp với trình duyệt hiện đại.
• Tải trước đúng tệp quan trọng, tránh tải trước toàn bộ thư viện.
• Dùng chiến lược hiển thị để nội dung không bị ẩn quá lâu.
• Chọn phông chữ dự phòng có đặc điểm kích thước gần với phông chữ chính để giảm dịch chuyển bố cục.

Ổn định bố cục để giảm CLS

CLS không chỉ liên quan đến tốc độ tải tệp. Chỉ số này phản ánh việc nội dung bị đẩy khỏi vị trí khi người dùng đang đọc hoặc chuẩn bị tương tác.

Các nguyên nhân thường gặp gồm ảnh không khai báo kích thước, banner được chèn phía trên nội dung, phông chữ thay đổi kích thước, khối quảng cáo không giữ chỗ và thanh thông báo xuất hiện đột ngột.

Giải pháp là dành sẵn không gian cho thành phần động, cập nhật nội dung trong vùng đã định trước và tránh chèn thêm thành phần phía trên nội dung hiện có sau khi trang bắt đầu hiển thị.

Quy trình đo–sửa–đo để xác minh kết quả

Một vòng kiểm chứng nên được thực hiện theo trình tự rõ ràng:

1. Đo số liệu gốc: lưu báo cáo của từng URL, thiết bị và điều kiện kiểm tra.
2. Xác định nguyên nhân: dùng sơ đồ tải tài nguyên, phần tử LCP, tác vụ JavaScript và thông tin máy chủ để tìm điểm nghẽn.
3. Chọn một nhóm thay đổi liên quan: chẳng hạn chỉ tối ưu ảnh đầu trang hoặc chỉ điều chỉnh cách tải script.
4. Kiểm tra trên môi trường thử nghiệm: xác nhận giao diện, tương tác và theo dõi chuyển đổi vẫn hoạt động.
5. Triển khai có kiểm soát: ghi lại thời điểm và phiên bản thay đổi.
6. Đo lại trong cùng điều kiện: dùng cùng URL, loại thiết bị, vị trí và cách xử lý bộ nhớ đệm.
7. Theo dõi dữ liệu thực tế: chờ dữ liệu người dùng được tổng hợp thay vì kết luận chỉ từ một lần kiểm tra thử nghiệm.
8. Giữ hoặc hoàn tác thay đổi: dựa trên hiệu suất, độ ổn định và tác động kinh doanh.

Một kết quả đủ bằng chứng cần có gì?

Khi công bố mức cải thiện, hồ sơ nên bao gồm:

Thành phần bằng chứng	Nội dung cần ghi nhận
Phạm vi	URL, mẫu trang và thiết bị được kiểm tra
Số liệu trước sửa	Báo cáo gốc có thời điểm và điều kiện đo
Thay đổi	Tệp, cấu hình hoặc thành phần đã được điều chỉnh
Số liệu sau sửa	Báo cáo đo lại trong điều kiện tương đương
Kiểm tra chức năng	Kết quả kiểm tra menu, biểu mẫu, chuyển đổi và hiển thị
Thời gian theo dõi	Khoảng thời gian đủ để xem dữ liệu thực tế sau triển khai

Nếu thiếu báo cáo trước sửa, không thể xác định chính xác thay đổi đã tạo ra bao nhiêu phần cải thiện. Nếu điều kiện hai lần đo khác nhau, chỉ nên xem kết quả là tín hiệu tham khảo.

Những sai lầm cần tránh khi tối ưu tốc độ

Chạy theo điểm số thay vì trải nghiệm

Điểm PageSpeed là dữ liệu chẩn đoán, không phải mục tiêu kinh doanh độc lập. Một trang có điểm cao nhưng nội dung thiếu hữu ích, điều hướng khó hiểu hoặc biểu mẫu lỗi vẫn không đáp ứng tốt nhu cầu người dùng.

Tốc độ là một phần của trải nghiệm trang. Nội dung liên quan, khả năng truy cập, tính ổn định, bảo mật và khả năng hoàn thành tác vụ vẫn cần được ưu tiên đồng thời.

Cài nhiều tiện ích có chức năng trùng nhau

Nhiều lớp nén, gộp tệp, tạo bộ nhớ đệm hoặc tải lười có thể xung đột. Hậu quả thường là giao diện sai, script chạy không đúng thứ tự hoặc người dùng nhận phiên bản nội dung cũ.

Mỗi chức năng nên có một nơi chịu trách nhiệm rõ ràng. Sau khi bật tính năng mới, cần kiểm tra xem máy chủ, hệ quản trị nội dung hoặc lớp phân phối nội dung đã làm cùng việc hay chưa.

Tải lười mọi tài nguyên

Tải lười phù hợp với nội dung ngoài màn hình đầu tiên, nhưng có thể gây tác dụng ngược nếu áp dụng cho logo, ảnh banner chính hoặc tài nguyên cần hiển thị ngay. Hãy xác định phần tử LCP trước khi quyết định trì hoãn ảnh.

Xóa mã dựa trên một báo cáo duy nhất

Một đoạn mã chưa dùng trong lần tải đầu có thể phục vụ trạng thái sau đăng nhập, cửa sổ bật lên, biểu mẫu hoặc thao tác trên thiết bị khác. Trước khi xóa, cần kiểm tra nhiều mẫu trang và luồng tương tác.

Hy sinh chất lượng nội dung để giảm dung lượng

Không nên xóa hình ảnh minh họa cần thiết, nội dung hướng dẫn hoặc chức năng hỗ trợ người dùng chỉ để tăng điểm. Mục tiêu là phân phối tài nguyên hiệu quả hơn, không phải biến trang thành phiên bản thiếu thông tin.

Việc tối ưu kỹ thuật quá mức cũng có thể tạo rủi ro tương tự tối ưu nội dung quá đà. Danh sách dấu hiệu tối ưu hóa website quá mức giúp nhận biết khi các thay đổi bắt đầu làm giảm tính tự nhiên hoặc trải nghiệm sử dụng.

Câu hỏi thường gặp

Điểm PageSpeed bao nhiêu là đủ?

Không có một điểm duy nhất phù hợp với mọi website. Nên ưu tiên Core Web Vitals, khả năng hoàn thành tác vụ và xu hướng cải thiện ổn định. Điểm thử nghiệm có thể dao động nên cần xem cùng dữ liệu thực tế và điều kiện đo.

Tại sao điểm tốc độ thay đổi dù website không cập nhật?

Kết quả có thể thay đổi do tải máy chủ, tuyến mạng, tài nguyên bên thứ ba, trạng thái bộ nhớ đệm hoặc điều kiện mô phỏng. Vì vậy, cần chạy nhiều lần trong cùng điều kiện và so sánh giá trị trung vị.

Có nên gộp toàn bộ CSS và JavaScript thành một tệp không?

Không phải lúc nào cũng nên. Một tệp lớn có thể buộc người dùng tải mã không cần cho trang hiện tại. Với giao thức web hiện đại, chia mã hợp lý theo chức năng hoặc loại trang thường hữu ích hơn việc gộp máy móc. Quyết định cuối cùng cần dựa trên sơ đồ tải tài nguyên và kết quả đo thực tế.

Tối ưu tốc độ có giúp tăng thứ hạng ngay không?

Không thể cam kết tăng thứ hạng chỉ bằng cải thiện tốc độ. Hiệu suất trang hỗ trợ trải nghiệm người dùng và khả năng sử dụng, nhưng kết quả tìm kiếm còn phụ thuộc vào mức độ liên quan, chất lượng nội dung, liên kết, khả năng thu thập dữ liệu và nhiều tín hiệu khác.

Bao lâu nên kiểm tra lại tốc độ website?

Nên kiểm tra sau các thay đổi có thể ảnh hưởng giao diện hoặc tài nguyên, chẳng hạn cập nhật giao diện, thêm mã theo dõi, thay banner, cài tính năng mới hoặc chuyển máy chủ. Ngoài ra, việc theo dõi định kỳ giúp phát hiện sự suy giảm do nội dung và mã bên thứ ba tích lũy theo thời gian.