Cách thức và lý do chúng tôi xây dựng Thông tin chi tiết về hiệu suất

Jack Franklin

Trong Chrome 102, bạn sẽ thấy một bảng điều khiển thử nghiệm mới là Thông tin chi tiết về hiệu suất trong Công cụ cho nhà phát triển. Trong bài đăng này, chúng ta sẽ thảo luận không chỉ về lý do chúng tôi hợp tác với một bảng điều khiển mới, mà còn cả những thách thức về mặt kỹ thuật và những quyết định chúng tôi đưa ra trong suốt quá trình này.

ALT_TEXT_HERE

Tại sao phải tạo một bảng điều khiển khác?

(Nếu bạn chưa xem, chúng tôi đã đăng một video về lý do tạo bảng điều khiển Thông tin chi tiết về hiệu suất và cách bạn có thể nhận thông tin chi tiết hữu ích về hiệu suất của trang web thông qua bảng điều khiển này.)

Bảng hiệu suất hiện tại là một tài nguyên hữu ích nếu bạn muốn xem tất cả dữ liệu về trang web của mình ở cùng một nơi, nhưng chúng tôi nhận thấy rằng bảng này có thể hơi khó hiểu. Nếu không phải là chuyên gia về hiệu suất, bạn sẽ khó biết chính xác điều cần tìm và những phần nào của bản ghi có liên quan.

Chuyển đến Bảng điều khiển thông tin chi tiết, nơi bạn vẫn có thể xem tiến trình theo dõi và kiểm tra dữ liệu, đồng thời nhận được danh sách tiện lợi về những thông tin mà DevTools coi là "Thông tin chi tiết" chính đáng để tìm hiểu. Thông tin chi tiết sẽ xác định các vấn đề như yêu cầu chặn kết xuất, thay đổi bố cục và các tác vụ dài, v.v. Tất cả những vấn đề này đều có thể ảnh hưởng tiêu cực đến hiệu suất tải trang của trang web và cụ thể là điểm số Core Web Vital (CWV) của trang web. Bên cạnh việc gắn cờ các vấn đề, Thông tin chi tiết về hiệu suất sẽ cung cấp cho bạn các đề xuất hữu ích để cải thiện điểm số CWV, cũng như cung cấp đường liên kết đến các tài nguyên và tài liệu khác.

Đường liên kết đến phần ý kiến phản hồi trong bảng điều khiển

Bảng điều khiển này đang trong giai đoạn thử nghiệm và chúng tôi mong nhận được ý kiến phản hồi của bạn! Vui lòng cho chúng tôi biết nếu bạn gặp lỗi hoặc có yêu cầu về tính năng mà bạn cho rằng sẽ giúp ích cho bạn khi cải thiện hiệu suất của trang web.

Cách chúng tôi xây dựng Thông tin chi tiết về hiệu suất

Giống như các công cụ phát triển khác, chúng tôi đã tạo Thông tin chi tiết về hiệu suất trong TypeScript và sử dụng thành phần web, được hỗ trợ bởi lit-html, để tạo giao diện người dùng. Điểm khác biệt của Performance Insights là giao diện người dùng chính là một phần tử canvas HTML và tiến trình được vẽ lên canvas này. Có rất nhiều vấn đề phức tạp liên quan đến việc quản lý canvas này: không chỉ vẽ đúng chi tiết ở đúng vị trí mà còn quản lý các sự kiện chuột (ví dụ: người dùng đã nhấp vào canvas ở đâu? Họ có nhấp vào một sự kiện mà chúng ta đã vẽ không?) và đảm bảo rằng chúng ta kết xuất lại canvas một cách hiệu quả.

Nhiều kênh trên một canvas

Đối với một trang web nhất định, chúng ta muốn hiển thị nhiều "đường dẫn", mỗi đường dẫn đại diện cho một danh mục dữ liệu khác nhau. Ví dụ: bảng Thông tin chi tiết sẽ hiển thị 3 kênh theo mặc định:

Chúng tôi dự kiến sẽ bổ sung thêm nhiều kênh khi tiếp tục ra mắt các tính năng trên bảng điều khiển.

Ý tưởng ban đầu của chúng tôi là mỗi kênh sẽ hiển thị <canvas> riêng, để thành phần hiển thị chính trở thành nhiều phần tử canvas xếp chồng theo chiều dọc. Điều này sẽ đơn giản hoá quá trình kết xuất ở cấp độ kênh vì mỗi kênh có thể kết xuất riêng biệt và sẽ không có nguy cơ kết xuất bản nhạc bên ngoài giới hạn của kênh đó, nhưng rất tiếc, phương pháp này có 2 vấn đề lớn:

Các phần tử canvas tốn kém để (hiển thị lại); việc có nhiều canvas tốn kém hơn so với một canvas, ngay cả khi canvas đó lớn hơn. Việc kết xuất bất kỳ lớp phủ nào trên nhiều kênh (ví dụ: các đường dọc để đánh dấu các sự kiện như thời gian FCP) sẽ trở nên phức tạp: chúng tôi phải kết xuất trên nhiều canvas và đảm bảo tất cả đều hiển thị cùng nhau và căn chỉnh đúng cách.

Việc sử dụng một canvas cho toàn bộ giao diện người dùng đồng nghĩa với việc chúng ta cần tìm cách đảm bảo mỗi kênh hiển thị ở đúng toạ độ và không tràn sang kênh khác. Ví dụ: nếu một kênh cụ thể có chiều cao 100px, thì chúng ta không thể cho phép kênh đó hiển thị nội dung có chiều cao 120px và tràn sang kênh bên dưới. Để giải quyết vấn đề này, chúng ta có thể sử dụng clip. Trước khi kết xuất từng kênh, chúng ta vẽ một hình chữ nhật đại diện cho cửa sổ kênh hiển thị. Điều này đảm bảo rằng mọi đường dẫn được vẽ ngoài các giới hạn này sẽ bị canvas cắt bớt.

canvasContext.beginPath();
canvasContext.rect(
    trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();

Chúng ta cũng không muốn mỗi bản nhạc phải biết vị trí của nó theo chiều dọc: mỗi bản nhạc sẽ tự kết xuất như thể nó đang kết xuất ở (0, 0) và chúng ta có một thành phần cấp cao hơn (mà chúng ta gọi là TrackManager) để quản lý vị trí chung của bản nhạc. Bạn có thể thực hiện việc này bằng translate. Phương thức này dịch canvas theo vị trí (x, y) đã cho. Ví dụ:

canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide

Mặc dù vị trí được đặt mã rect 0, 0, nhưng bản dịch tổng thể được áp dụng sẽ khiến hình chữ nhật hiển thị tại 0, 10. Điều này cho phép chúng ta làm việc trên cơ sở kênh như thể chúng ta đang kết xuất tại (0, 0) và yêu cầu trình quản lý kênh dịch khi kết xuất từng kênh để đảm bảo từng kênh được kết xuất chính xác bên dưới kênh trước đó.

Canvas ngoài màn hình cho các bản nhạc và điểm nổi bật

Việc kết xuất Canvas tương đối tốn kém và chúng tôi muốn đảm bảo rằng bảng Thông tin chi tiết luôn hoạt động mượt mà và thích ứng khi bạn sử dụng. Đôi khi, bạn không thể tránh việc phải kết xuất lại toàn bộ canvas: ví dụ: nếu bạn thay đổi mức thu phóng, chúng ta phải bắt đầu lại và kết xuất lại mọi thứ. Việc kết xuất lại canvas đặc biệt tốn kém vì bạn không thể chỉ kết xuất lại một phần nhỏ mà cần phải xoá sạch toàn bộ canvas và vẽ lại. Điều này không giống như việc kết xuất lại DOM, trong đó các công cụ có thể tính toán công việc tối thiểu cần thiết và không xoá mọi thứ rồi bắt đầu lại.

Một vấn đề về hình ảnh mà chúng tôi gặp phải là làm nổi bật. Khi bạn di chuột qua các chỉ số trong ngăn, chúng tôi sẽ làm nổi bật các chỉ số đó trên dòng thời gian. Tương tự, nếu bạn di chuột qua một Thông tin chi tiết về một sự kiện nhất định, chúng tôi sẽ vẽ đường viền màu xanh dương xung quanh sự kiện đó.

Tính năng này được triển khai trước tiên bằng cách phát hiện thao tác di chuyển chuột qua một phần tử kích hoạt thành phần được làm nổi bật, sau đó vẽ trực tiếp điểm làm nổi bật đó lên canvas chính. Vấn đề xảy ra khi chúng ta phải xoá phần đánh dấu: lựa chọn duy nhất là vẽ lại mọi thứ! Không thể chỉ vẽ lại khu vực được làm nổi bật (không phải không có thay đổi lớn về cấu trúc), nhưng việc vẽ lại toàn bộ canvas chỉ vì chúng ta muốn xoá đường viền màu xanh dương xung quanh một mục có vẻ như là quá mức. Hình ảnh cũng bị trễ nếu bạn di chuột nhanh qua nhiều mục để kích hoạt nhiều điểm nổi bật liên tiếp.

Để khắc phục vấn đề này, chúng ta chia giao diện người dùng thành hai canvas ngoài màn hình: canvas "chính", nơi các bản nhạc hiển thị và canvas "điểm nổi bật", nơi các điểm nổi bật được vẽ. Sau đó, chúng tôi kết xuất bằng cách sao chép các canvas đó vào một canvas duy nhất hiển thị trên màn hình cho người dùng. Chúng ta có thể sử dụng phương thức drawImage trên ngữ cảnh canvas, có thể lấy một canvas khác làm nguồn.

Việc này có nghĩa là việc xoá một điểm nổi bật sẽ không khiến canvas chính được vẽ lại: thay vào đó, chúng ta có thể xoá canvas trên màn hình, sau đó sao chép canvas chính vào canvas hiển thị. Việc sao chép canvas có chi phí thấp, còn bản vẽ thì có chi phí cao; vì vậy, bằng cách di chuyển các điểm nổi bật sang một canvas riêng biệt, chúng ta tránh được chi phí đó khi bật và tắt các điểm nổi bật.

Phân tích cú pháp dấu vết được kiểm tra toàn diện

Một trong những lợi ích của việc xây dựng một tính năng mới từ đầu là bạn có thể xem xét các lựa chọn kỹ thuật đã thực hiện trước đó và cải thiện. Một trong những điều chúng tôi muốn cải thiện là tách mã thành hai phần gần như hoàn toàn khác biệt:

Phân tích cú pháp tệp theo dõi và lấy dữ liệu cần thiết. Kết xuất một nhóm bản nhạc.

Việc tách riêng quá trình phân tích cú pháp (phần 1) với công việc trên giao diện người dùng (phần 2) đã giúp chúng tôi xây dựng một hệ thống phân tích cú pháp vững chắc; mỗi dấu vết được chạy thông qua một loạt Trình xử lý chịu trách nhiệm về các vấn đề khác nhau: LayoutShiftHandler tính toán tất cả thông tin chúng ta cần cho Layout Shifts và NetworkRequestsHandler chỉ xử lý việc rút các yêu cầu mạng. Việc có bước phân tích cú pháp rõ ràng này, trong đó chúng ta có các trình xử lý khác nhau chịu trách nhiệm cho các phần khác nhau của dấu vết cũng rất có lợi: việc phân tích cú pháp dấu vết có thể trở nên rất phức tạp và giúp bạn có thể tập trung vào một vấn đề tại một thời điểm.

Chúng tôi cũng có thể kiểm thử toàn diện việc phân tích cú pháp dấu vết bằng cách ghi lại trong DevTools, lưu và sau đó tải các bản ghi đó vào trong bộ kiểm thử. Điều này rất tuyệt vì chúng ta có thể kiểm thử bằng các dấu vết thực tế và không tạo ra một lượng lớn dữ liệu dấu vết giả có thể trở nên lỗi thời.

Kiểm thử ảnh chụp màn hình giao diện người dùng canvas

Tiếp tục về chủ đề kiểm thử, chúng ta thường kiểm thử các thành phần giao diện người dùng bằng cách hiển thị các thành phần đó vào trình duyệt và đảm bảo các thành phần đó hoạt động như mong đợi; chúng ta có thể gửi các sự kiện nhấp để kích hoạt bản cập nhật và xác nhận rằng DOM mà các thành phần tạo ra là chính xác. Phương pháp này hoạt động hiệu quả với chúng ta nhưng không hiệu quả khi xem xét việc kết xuất vào canvas; không có cách nào để kiểm tra canvas và xác định nội dung được vẽ trên đó! Vì vậy, phương pháp kết xuất rồi truy vấn thông thường của chúng ta là không phù hợp.

Để có phạm vi kiểm thử, chúng tôi đã chuyển sang kiểm thử ảnh chụp màn hình. Mỗi lần kiểm thử sẽ kích hoạt một canvas, kết xuất bản nhạc mà chúng ta muốn kiểm thử, sau đó chụp ảnh màn hình của phần tử canvas. Sau đó, ảnh chụp màn hình này được lưu trữ trong cơ sở mã của chúng ta và các lần chạy kiểm thử trong tương lai sẽ so sánh ảnh chụp màn hình được lưu trữ với ảnh chụp màn hình mà chúng tạo ra. Nếu ảnh chụp màn hình khác nhau thì kiểm thử sẽ không thành công. Chúng tôi cũng cung cấp một cờ để chạy kiểm thử và buộc cập nhật ảnh chụp màn hình khi chúng tôi đã thay đổi nội dung kết xuất một cách có chủ đích và cần cập nhật kiểm thử.

Kiểm thử ảnh chụp màn hình không hoàn hảo và hơi thô; bạn chỉ có thể kiểm thử toàn bộ thành phần hiển thị như dự kiến, thay vì các xác nhận cụ thể hơn. Ban đầu, chúng tôi đã sử dụng quá nhiều các kiểm thử này để đảm bảo mọi thành phần (HTML hoặc canvas) đều hiển thị chính xác. Điều này làm chậm đáng kể bộ kiểm thử của chúng tôi và dẫn đến các vấn đề trong đó các chỉnh sửa giao diện người dùng nhỏ, gần như không liên quan (chẳng hạn như thay đổi màu sắc tinh tế hoặc thêm một số lề giữa các mục) khiến nhiều ảnh chụp màn hình không thành công và cần cập nhật. Chúng tôi hiện đã giảm quy mô sử dụng ảnh chụp màn hình và chỉ sử dụng ảnh chụp màn hình cho các thành phần dựa trên canvas. Sự cân bằng này đã mang lại hiệu quả cho chúng tôi từ trước đến nay.

Kết luận

Việc xây dựng bảng điều khiển mới Thông tin chi tiết về hiệu suất là một trải nghiệm rất thú vị và mang tính giáo dục đối với nhóm. Chúng ta đã tìm hiểu rất nhiều về tệp theo dõi, cách làm việc với canvas và nhiều nội dung khác. Chúng tôi hy vọng bạn sẽ thích sử dụng bảng điều khiển mới và rất mong nhận được ý kiến phản hồi của bạn.

Để tìm hiểu thêm về bảng điều khiển Thông tin chi tiết về hiệu suất, hãy xem bài viết Thông tin chi tiết về hiệu suất: Nhận thông tin chi tiết hữu ích về hiệu suất của trang web.

Tải các kênh xem trước xuống

Hãy cân nhắc sử dụng Chrome Canary, Dev hoặc Beta làm trình duyệt phát triển mặc định. Các kênh xem trước này cho phép bạn sử dụng các tính năng mới nhất của DevTools, kiểm thử các API nền tảng web tiên tiến và giúp bạn tìm thấy vấn đề trên trang web của mình trước khi người dùng phát hiện ra!

Liên hệ với nhóm Công cụ của Chrome cho nhà phát triển

Hãy sử dụng các lựa chọn sau để thảo luận về các tính năng, bản cập nhật mới hoặc bất kỳ nội dung nào khác liên quan đến Công cụ cho nhà phát triển.