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 tôi sẽ thảo luận không chỉ về lý do chúng tôi đang nghiên cứu một bảng điều khiển mới, mà còn về những thách thức kỹ thuật mà chúng tôi phải đối mặt và những quyết định mà chúng tôi đã đưa ra trong quá trình này.

ALT_TEXT_HERE

Tại sao nên xây dựng một bảng điều khiển khác?

(Nếu chưa xem, bạn có thể xem video của chúng tôi về lý do chúng tôi xây dựng 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 được 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 điều khiển hiệu suất hiện tại là một nguồn tài nguyên hữu ích nếu bạn muốn xem tất cả dữ liệu cho trang web của mình ở một nơi, nhưng chúng tôi cảm thấy rằng bảng điều khiển 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 khó có thể biết chính xác những gì cần tìm và những phần nào trong bản ghi có liên quan.

Truy cập vào bảng điều khiển Thông tin chi tiết. Tại đây, bạn vẫn có thể xem dòng thời gian của dấu vết và kiểm tra dữ liệu, đồng thời xem danh sách thuận tiện về những "Thông tin chi tiết" chính mà DevTools cho là đá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 hiển thị, sự thay đổi bố cục và các tác vụ dài (chỉ là một vài ví dụ). 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. Ngoài 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 những đề xuất hữu ích để cải thiện điểm CWV, đồng thời 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 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 rất 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 phải lỗi hoặc có yêu cầu về tính năng mà bạn cho rằng sẽ giúp bạn khi làm việc về hiệu suất của trang web.

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

Giống như phần còn lại của Công cụ cho nhà phát triển, chúng tôi đã tạo Thông tin chi tiết về hiệu suất bằng 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 Thông tin chi tiết về hiệu suất là giao diện người dùng chính là phần tử HTML canvas và dòng thời gian được vẽ trên canvas này. Phần lớn sự phức tạp đến từ 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 bản nhạc trên một canvas

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

Khi tiếp tục bổ sung các tính năng vào bảng điều khiển này, chúng tôi hy vọng sẽ có thêm nhiều bản nhạc được thêm vào.

Ban đầu, chúng tôi nghĩ rằng mỗi bản nhạc này sẽ kết xuất <canvas> riêng, để khung hiển thị chính sẽ 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 độ đường đua, vì mỗi đường đua có thể kết xuất riêng biệt và không có nguy cơ đường đua kết xuất bên ngoài ranh giới của nó, nhưng không may là phương pháp này có hai vấn đề lớn:

Các phần tử canvas tốn kém để kết xuất (kết xuất lại); việc có nhiều canvas sẽ tốn kém hơn một canvas, ngay cả khi canvas đó lớn hơn. Việc kết xuất mọi lớp phủ trải dài trên nhiều bản nhạc (ví dụ: đường kẻ dọc để đánh dấu các sự kiện như thời gian hiển thị nội dung đầu tiên) trở nên phức tạp: chúng ta phải kết xuất trên nhiều canvas và đảm bảo tất cả các lớp phủ đó đều được kết xuất 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 có nghĩa là chúng ta cần tìm ra cách đảm bảo mỗi bản nhạc hiển thị ở đúng toạ độ và không tràn vào một bản nhạc khác. Ví dụ: nếu một bản nhạc cụ thể có chiều cao 100 px, chúng tôi không thể cho phép bản nhạc đó hiển thị nội dung có chiều cao 120 px và tràn vào bản nhạc 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 phụ đề, chúng ta sẽ vẽ một hình chữ nhật đại diện cho cửa sổ phụ đề hiển thị. Điều này đảm bảo rằng mọi đường dẫn được vẽ bên ngoài các ranh giới này sẽ bị khung hiển thị cắt bớt.

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

Chúng tôi cũng không muốn mỗi bản nhạc phải biết vị trí theo chiều dọc của nó: mỗi bản nhạc sẽ tự hiển thị như thể đang hiển thị ở (0, 0) và chúng tôi có một thành phần cấp cao hơn (mà chúng tôi gọi là TrackManager) để quản lý vị trí tổng thể của bản nhạc. Bạn có thể thực hiện việc này bằng translate. Lệnh này sẽ dịch canvas theo một vị trí (x, y) nhất định. 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ù chế độ cài đặt mã rect đặt 0, 0 làm vị trí, nhưng bản dịch tổng thể được áp dụng sẽ khiến hình chữ nhật được kết xuất tại 0, 10. Điều này cho phép chúng ta làm việc trên cơ sở theo dõi như thể đang kết xuất tại (0, 0) và để trình quản lý theo dõi dịch khi kết xuất từng bản nhạc để đảm bảo mỗi bản nhạc được kết xuất chính xác bên dưới bản nhạc 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 bảng điều khiển Thông tin chi tiết vẫn hoạt động mượt mà và phản hồi nhanh khi bạn làm việc với bảng điều khiển này. Đô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ỏ của canvas; bạn cần xoá toàn bộ canvas và vẽ lại. Điều này khác với việc kết xuất lại DOM, trong đó các công cụ có thể tính toán lượng 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 điểm mà chúng tôi gặp phải vấn đề về hình ảnh là tính năng 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 cho một sự kiện nhất định, chúng tôi sẽ vẽ một đường viền màu xanh dương xung quanh sự kiện đó.

Tính năng này được triển khai lần đầu bằng cách phát hiện chuyển động của chuột trên một phần tử kích hoạt điểm đánh dấu, sau đó vẽ điểm đánh dấu đó trực tiếp lên canvas chính. Vấn đề của chúng tôi là khi 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 vùng có điểm đánh dấu (nếu không có những 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 cần thiết. Ngoài ra, hiệu ứng này cũng bị trễ về mặt hình ảnh nếu bạn di chuyển 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 tôi 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 được kết xuất) và canvas "điểm nổi bật" (nơi các điểm nổi bật được vẽ). Sau đó, chúng ta kết xuất bằng cách sao chép những canvas đó vào canvas duy nhất mà người dùng nhìn thấy trên màn hình. Chúng ta có thể sử dụng phương thức drawImage trên một ngữ cảnh canvas, có thể lấy một canvas khác làm nguồn.

Khi làm như vậy, việc xoá một điểm đánh dấu sẽ không khiến khung hiển thị chính được vẽ lại: thay vào đó, chúng ta có thể xoá khung hiển thị trên màn hình, rồi sao chép khung hiển thị chính vào khung hiển thị có thể nhìn thấy. Hành động sao chép một canvas có chi phí thấp, còn hành động vẽ thì tốn kém; vì vậy, bằng cách di chuyển phần đánh dấu sang một canvas riêng, chúng ta sẽ tránh được chi phí đó khi bật và tắt phần đánh dấu.

Phân tích cú pháp dấu vết được kiểm thử 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ể suy nghĩ về các lựa chọn kỹ thuật đã thực hiện trước đó và cải thiện chúng. Một trong những điều chúng tôi muốn cải thiện là chia mã của mình thành hai phần hoàn toàn riêng biệt:

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

Việc tách biệt quá trình phân tích cú pháp (phần 1) với công việc liên quan đến giao diện người dùng (phần 2) cho phé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 tôi cần cho Layout Shifts và NetworkRequestsHandler chỉ giải quyết việc kéo 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ó nhiều trình xử lý chịu trách nhiệm cho các phần khác nhau của dấu vết, cũng mang lại lợi ích: 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à việc có thể tập trung vào một vấn đề tại một thời điểm sẽ giúp ích.

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 Công cụ cho nhà phát triển, lưu lại rồi tải chúng vào như một phần của bộ kiểm thử. Điều này rất hữu ích vì chúng ta có thể kiểm thử bằng các dấu vết thực và không cần 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 cho giao diện người dùng canvas

Vẫn xoay quanh 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 kết xuất chúng vào trình duyệt và đảm bảo chúng hoạt động như mong đợi; chúng ta có thể gửi các sự kiện nhấp để kích hoạt các bản cập nhật và khẳng định rằng DOM mà các thành phần tạo ra là chính xác. Cách tiếp cận này phù hợp với chúng tôi 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ẽ ở đó! 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 không phù hợp.

Để có thể kiểm thử một số thành phần, chúng tôi đã chuyển sang kiểm thử bằng ảnh chụp màn hình. Mỗi 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 sẽ đượ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 đã 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ì quy trình kiểm thử sẽ không thành công. Chúng tôi cũng cung cấp một cờ để chạy thử nghiệm và buộc cập nhật ảnh chụp màn hình khi chúng tôi cố ý thay đổi quá trình kết xuất và cần cập nhật thử nghiệm.

Kiểm thử bằng ảnh chụp màn hình không phải là phương pháp hoàn hảo và có phần thô sơ; bạn chỉ có thể kiểm thử để đảm bảo toàn bộ thành phần hiển thị như mong đợi, thay vì các câu khẳng định cụ thể hơn. Ban đầu, chúng tôi đã mắc lỗi khi sử dụng quá nhiều phương pháp 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 đó những tinh chỉnh nhỏ, gần như không liên quan đến giao diện người dùng (chẳng hạn như thay đổi nhỏ về màu sắc hoặc thêm một số khoảng 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 cập nhật. Giờ đây, chúng tôi đã giảm bớt việc 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 cho đến nay.

Kết luận

Việc xây dựng bảng điều khiển Thông tin chi tiết về hiệu suất mới 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 này 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 truy cập vào 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 các vấn đề trên trang web của mình trước khi người dùng tìm thấy!

Liên hệ với nhóm Chrome DevTools

Hãy sử dụng các lựa chọn sau để thảo luận về các tính năng mới, nội dung cập nhật 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.