Phân tích trên thiết bị di động trong PageSpeed Insights

PageSpeed Insights phân tích một trang để xem trang có tuân theo các đề xuất của chúng tôi về cách đảm bảo một trang có thể hiển thị trong chưa đầy một giây trên mạng di động hay không. Nghiên cứu đã chỉ ra rằng bất kỳ sự chậm trễ nào lâu hơn một giây đều sẽ khiến người dùng làm gián đoạn luồng suy nghĩ của họ, từ đó tạo ra trải nghiệm kém. Mục tiêu của chúng tôi là thu hút người dùng tương tác với trang và mang lại trải nghiệm tối ưu, bất kể thiết bị hoặc loại mạng.

Không dễ dàng để đáp ứng ngân sách một lần thứ hai. May mắn thay, chúng tôi không phải hiển thị toàn bộ trang trong phạm vi ngân sách này, thay vào đó, chúng tôi phải phân phối và hiển thị nội dung trong màn hình đầu tiên (ATF) trong chưa đầy một giây, cho phép người dùng bắt đầu tương tác với trang sớm nhất có thể. Sau đó, trong khi người dùng đang diễn giải trang nội dung đầu tiên, phần còn lại của trang có thể được phân phối dần trong nền.

Thích ứng với mạng di động có độ trễ cao

Việc đáp ứng tiêu chí ATF một giây trên thiết bị di động đặt ra những thách thức chưa từng có trên các mạng khác. Người dùng có thể truy cập trang web của bạn qua nhiều mạng 2G, 3G và 4G khác nhau. Độ trễ mạng cao hơn đáng kể so với kết nối có dây và chiếm một phần đáng kể trong ngân sách 1000 mili giây của chúng tôi để hiển thị nội dung ATF.

4G là loại mạng phổ biến trên thế giới, bạn nên dự kiến rằng phần lớn người dùng sẽ truy cập trang của bạn trên mạng 4G. Vì lý do này, chúng tôi phải giả định rằng mỗi yêu cầu mạng sẽ mất trung bình 100 mili giây.

Vì lẽ đó, bây giờ hãy cùng tìm hiểu ngược lại. Nếu chúng ta xem xét trình tự giao tiếp thông thường giữa trình duyệt và máy chủ, thì 300 mili giây trong thời gian đó đã bị hao tổn mạng dùng hết: tra cứu DNS để phân giải tên máy chủ (ví dụ: google.com) thành địa chỉ IP, trả về mạng để thực hiện bắt tay TCP và kết nối TLS không bắt buộc. Việc này sẽ khiến chúng tôi mất 700 mili giây.

Cung cấp trải nghiệm kết xuất hình ảnh chưa đến một giây

Sau khi trừ đi độ trễ mạng, chúng tôi chỉ còn 700 mili giây trong ngân sách và vẫn còn rất nhiều việc phải làm: máy chủ phải hiển thị phản hồi, mã ứng dụng phía máy khách phải thực thi, còn trình duyệt phải bố cục và hiển thị nội dung. Do đó, các tiêu chí sau đây sẽ giúp chúng tôi duy trì được mức ngân sách này:

(1) Máy chủ phải kết xuất phản hồi (< 200 mili giây)
Thời gian phản hồi của máy chủ là thời gian mà máy chủ cần để trả về HTML ban đầu, không tính đến thời gian truyền tải mạng. Vì chúng ta chỉ có rất ít thời gian, nên bạn nên duy trì thời gian ở mức tối thiểu, lý tưởng nhất là trong vòng 200 mili giây, và thậm chí là ít hơn nữa!
(2) Số lần chuyển hướng cần được giảm thiểu
Việc chuyển hướng HTTP bổ sung có thể làm tăng thêm 1 hoặc 2 lượt trọn vòng mạng (hai lượt nếu cần phải tra cứu thêm DNS), làm phát sinh độ trễ thêm hàng trăm mili giây trên mạng 4G. Vì lý do này, chúng tôi đặc biệt khuyến khích các quản trị viên trang web nên giảm thiểu số lượng và tốt nhất là loại bỏ các lệnh chuyển hướng hoàn toàn – điều này đặc biệt quan trọng đối với tài liệu HTML (tránh chuyển hướng "m chấm" khi có thể).
(3) Cần giảm thiểu số lượt trả về đến lần kết xuất đầu tiên

Do cách TCP ước tính dung lượng kết nối (tức là Khởi động chậm TCP), kết nối TCP mới không thể sử dụng ngay toàn bộ băng thông hiện có giữa ứng dụng và máy chủ. Do đó, máy chủ có thể gửi tối đa 10 gói TCP trên một kết nối mới (~14KB) trong khứ hồi đầu tiên và sau đó phải đợi ứng dụng xác nhận dữ liệu này trước khi có thể tăng cửa sổ tắc nghẽn và tiếp tục phân phối thêm dữ liệu.

Ngoài ra, điều quan trọng cần lưu ý là giới hạn 10 gói (IW10) là bản cập nhật gần đây cho tiêu chuẩn TCP: bạn nên đảm bảo rằng máy chủ của mình được nâng cấp lên phiên bản mới nhất để tận dụng thay đổi này. Nếu không, giới hạn có thể sẽ là 3-4 gói!

Do hành vi của TCP, bạn cần phải tối ưu hoá nội dung của mình để giảm thiểu số lượt trả về cần thiết nhằm phân phối dữ liệu cần thiết nhằm thực hiện lượt hiển thị trang đầu tiên. Lý tưởng nhất, nội dung ATF nên nằm trong dưới 98KB – điều này cho phép trình duyệt vẽ trang chỉ sau ba lần trọn vòng để có nhiều ngân sách thời gian cho độ trễ phản hồi của máy chủ và hiển thị ứng dụng.

(4) Tránh chặn JavaScript và CSS bên ngoài trong nội dung trong màn hình đầu tiên

Trước khi có thể hiển thị một trang cho người dùng, trình duyệt phải phân tích cú pháp trang đó. Nếu gặp một tập lệnh bên ngoài không đồng bộ hoặc bị chặn trong quá trình phân tích cú pháp, thì nó phải dừng và tải tài nguyên đó xuống. Mỗi lần như vậy, trình phân tích cú pháp sẽ thêm một lượt khứ hồi mạng, do đó sẽ trì hoãn thời gian hiển thị trang đầu tiên.

Do đó, JavaScript và CSS cần để hiển thị vùng trong màn hình đầu tiên phải nằm trong dòng và JavaScript hoặc CSS cần thiết để thêm chức năng bổ sung vào trang phải được tải sau khi nội dung ATF đã được phân phối.

(5) Thời gian dự trữ cho bố cục và hiển thị trình duyệt (200 mili giây)
Quá trình phân tích cú pháp HTML, CSS và thực thi JavaScript tốn nhiều thời gian và tài nguyên máy khách! Tuỳ thuộc vào tốc độ của thiết bị di động và độ phức tạp của trang, quá trình này có thể mất hàng trăm mili giây. Bạn nên dành 200 mili giây cho chi phí cho trình duyệt.
(6) Tối ưu hoá thời gian thực thi và kết xuất JavaScript
Các tập lệnh phức tạp và mã không hiệu quả có thể mất hàng chục, hàng trăm mili giây để thực thi – hãy sử dụng các công cụ cho nhà phát triển tích hợp sẵn trong trình duyệt để phân tích và tối ưu hoá mã của bạn. Để biết thêm thông tin, hãy xem khoá học tương tác về Công cụ cho nhà phát triển Chrome của chúng tôi.

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

Tôi đang sử dụng thư viện JavaScript, chẳng hạn như JQuery, có lời khuyên nào không?
Nhiều thư viện JavaScript, chẳng hạn như JQuery, được dùng để cải thiện trang nhằm bổ sung khả năng tương tác, ảnh động và các hiệu ứng khác. Tuy nhiên, nhiều hành vi trong số này có thể được thêm vào một cách an toàn sau khi nội dung ATF hiển thị. Điều tra việc di chuyển quá trình thực thi và tải JavaScript đó cho đến khi trang được tải.
Tôi đang sử dụng khung JavaScript để xây dựng trang, có lời khuyên nào không?
Nếu nội dung của trang được tạo bằng JavaScript phía máy khách, bạn nên điều tra việc chèn cùng dòng các mô-đun JavaScript có liên quan để tránh việc nhận thêm các lượt trọn vòng mạng. Tương tự, việc tận dụng tính năng hiển thị phía máy chủ có thể cải thiện đáng kể hiệu suất tải trang đầu tiên: hiển thị mẫu JS trên máy chủ, đưa kết quả vào cùng dòng với HTML, sau đó sử dụng mẫu phía máy khách khi ứng dụng được tải.
Làm cách nào để xác định một CSS quan trọng trên trang của tôi?
Trong Công cụ cho nhà phát triển Chrome, mở bảng Kiểm tra, rồi chạy báo cáo Hiệu suất trang web. Trong báo cáo được tạo, hãy tìm Xoá các quy tắc CSS không dùng đến. Bạn cũng có thể sử dụng bất kỳ công cụ hoặc tập lệnh nào của bên thứ ba để xác định những bộ chọn CSS được áp dụng trên mỗi trang.
Các phương pháp hay nhất này có thể được tự động hoá không?
Chắc chắn là được rồi. Có nhiều sản phẩm tối ưu hoá hiệu suất web (WPO) thương mại và nguồn mở có thể giúp bạn đáp ứng một số hoặc tất cả các tiêu chí nêu trên. Đối với các giải pháp nguồn mở, hãy xem Công cụ tối ưu hóa PageSpeed.
Làm cách nào để điều chỉnh máy chủ của tôi để đáp ứng những tiêu chí này?
Trước tiên, hãy đảm bảo rằng máy chủ của bạn đang chạy phiên bản hệ điều hành mới nhất. Để hưởng lợi từ kích thước cửa sổ tắc nghẽn ban đầu của TCP (IW10) tăng lên, bạn cần có nhân Linux 2.6.39 trở lên. Đối với các hệ điều hành khác, vui lòng tham khảo tài liệu.
Để tối ưu hoá thời gian phản hồi của máy chủ, hãy đo lường mã của bạn hoặc sử dụng một giải pháp giám sát ứng dụng để xác định nút thắt cổ chai của bạn – ví dụ: thời gian chạy tập lệnh, lệnh gọi cơ sở dữ liệu, yêu cầu RPC, kết xuất, v.v. Mục tiêu là hiển thị phản hồi HTML trong vòng 200 mili giây.
Còn Chính sách bảo mật nội dung thì sao?
Nếu đang sử dụng CSP, thì bạn có thể phải cập nhật chính sách mặc định.
Đầu tiên, thuộc tính CSS cùng dòng trên các phần tử HTML(ví dụ: Bạn nên tránh sử dụng < p style=...> nếu có thể, vì các mã này thường dẫn đến việc trùng lặp mã không cần thiết và bị chặn theo mặc định bằng CSP (bị tắt thông qua “nội tuyến không an toàn” trên “style-src”). Nếu bạn bật CSP, thì theo mặc định, CSP sẽ chặn tất cả thẻ tập lệnh cùng dòng. Nếu có JavaScript nội tuyến, bạn cần cập nhật chính sách CSP để sử dụng hàm băm tập lệnh hoặc nonces (hàm băm tập lệnh hoặc nonces) hoặc sử dụng “unsafe-inline” để cho phép tất cả tập lệnh cùng dòng thực thi. Nếu có kiểu cùng dòng, bạn cần cập nhật chính sách CSP để sử dụng hàm băm kiểu hoặc nonces (hàm băm kiểu cùng dòng) hoặc sử dụng "unsafe-inline" để cho phép xử lý tất cả khối kiểu cùng dòng.

Bạn vẫn còn thắc mắc? Vui lòng đặt câu hỏi và đưa ra ý kiến phản hồi trong nhóm thảo luận của chúng tôi tại mục pagespeed-insights-discuss.

Ý kiến phản hồi

Trang này có hữu ích không?