Trong Chrome 102, bạn sẽ thấy một bảng điều khiển thử nghiệm mới có tên Thông tin chi tiết về hiệu suất trong Công cụ cho nhà phát triển của mình. Trong bài đăng này, chúng ta không chỉ thảo luận về lý do chúng tôi tham gia một hội đồng mới, mà còn cả những thách thức về kỹ thuật mà chúng tôi phải đối mặt cũng như những quyết định chúng tôi đã đưa ra trong quá trình thực hiện.
Tại sao nên xây một bảng điều khiển khác?
(Nếu bạn chưa xem qua, chúng tôi đã đăng một video về lý do cần xây dựng bảng điều khiển Thông tin chi tiết về hiệu suất và cách sử dụng bảng điều khiển này để nhận thông tin chi tiết hữu ích về hiệu suất của trang web.)
Bảng điều khiển hiệu suất hiện tại là 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 thấy rằng bạn có thể hơi choáng ngợp. Nếu không phải là một chuyên gia về hiệu suất thì bạn khó mà biết được chính xác nội dung cần tìm và những phần nào của 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 tiến trình theo dõi và kiểm tra dữ liệu, đồng thời nhận được một danh sách hữu ích về những dữ liệu mà Công cụ cho nhà phát triển coi là "Thông tin chi tiết" chính cần 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ị, thay đổi bố cục và thao tác mất nhiều thời gian, 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ố Chỉ số quan trọng chính của trang web (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 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 liệu và tài liệu khác.
Bảng điều khiển này đang trong giai đoạn thử nghiệm nên chúng tôi rất mong nhận được ý kiến đóng góp 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ó các yêu cầu về tính năng mà bạn cho rằng sẽ hữu ích khi cải thiện hiệu suất 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ư phần còn lại của Công cụ cho nhà phát triển, chúng tôi đã xây dựng Thông tin chi tiết về hiệu suất bằng TypeScript và sử dụng các thành phần web (được hỗ trợ bởi lit-html) để xây dựng giao diện người dùng. Điểm khác biệt trong 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. Rất nhiều sự phức tạp bắt nguồn từ việc quản lý canvas này: không chỉ vẽ đúng các chi tiết vào đú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 sự kiện chúng ta vẽ không?) và đảm bảo rằng chúng tôi 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 cụ thể, chúng tôi muốn hiển thị nhiều "kênh" và mỗi nhóm đại diện cho một danh mục dữ liệu khác nhau. Ví dụ: theo mặc định, bảng Thông tin chi tiết sẽ hiển thị 3 phần:
Khi tiếp tục giới thiệu các tính năng trong bảng điều khiển, chúng tôi dự kiến sẽ bổ sung thêm nhiều kênh.
Ý kiến ban đầu của chúng tôi là mỗi bản nhạc này hiển thị <canvas> riêng, để khung hiển thị chính trở thành nhiều phần tử canvas được xếp chồng theo chiều dọc. Phương pháp 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ể hiển thị riêng biệt và sẽ không có nguy cơ kết xuất kênh vượt ra ngoài giới hạn, nhưng rất tiếc, phương pháp này có hai vấn đề lớn:
Các phần tử canvas tốn kém khi 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 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) 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 đó đề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 tôi cần tìm ra cách đảm bảo từng kênh đều hiển thị ở đúng toạ độ và không tràn sang một kênh khác. Ví dụ: nếu một bản nhạc cụ thể cao 100px, chúng tôi không thể cho phép bản nhạc đó hiển thị nội dung có chiều cao 120px và để bản nhạc đó tràn vào 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ẽ bên ngoài các giới hạn này sẽ được canvas 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í của mình theo chiều dọc: mỗi bản nhạc phải tự hiển thị như thể đang kết xuất ở (0, 0) và chúng ta có một thành phần cấp cao hơn (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. Hàm này sẽ dịch ảnh in trên vải canvas theo một vị trí (x, y) cho trước. 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ù mã rect đặt 0, 0 làm vị trí, nhưng việc 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ở bản nhạc như thể chúng ta đang kết xuất tại (0, 0) và yêu cầu trình quản lý bản nhạc của chúng ta dịch khi nó kết xuất từng bản nhạc để đảm bảo từng bản nhạc được kết xuất chính xác dưới bản nhạc trước đó.
Ảnh in trên vải canvas ngoài màn hình cho bản nhạc và khoảnh khắc nổi bật
Quá trình 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 luôn mượt mà và phản hồi nhanh khi bạn làm việc. Đôi khi bạn không thể tránh việc 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 tôi phải bắt đầu lại và kết xuất lại mọi thứ. Quá trình 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 đó, mà phải xóa toàn bộ canvas rồi vẽ lại. Điều này không giống như tính năng hiển thị lại DOM, trong đó các công cụ có thể tính toán khối 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 khía cạnh mà chúng tôi gặp phải vấn đề về hình ảnh là việc đánh dấu. 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 và tương tự, nếu bạn di chuột qua một Thông tin chi tiết của 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 đó.
Trước tiên, tính năng này được triển khai 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 vùng sáng, sau đó vẽ vùng nổi bật đó trực tiếp vào 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 nơi có điểm đánh dấu (không phải là không có những thay đổi lớn về kiến trúc), mà là 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 khiến nó cảm thấy quá tốn kém. Hình ảnh cũng bị trễ nếu bạn nhanh chóng di chuột qua các mục khác nhau để 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 bản nhạc được hiển thị) và canvas "đánh dấu" (đánh dấu). Sau đó, chúng ta kết xuất bằng cách sao chép các canvas đó vào một canvas 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. Phương thức này có thể lấy một canvas khác làm nguồn.
Làm như vậy có nghĩa là việc xoá phần đánh dấu 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 rồi sao chép canvas chính vào canvas hiển thị. Việc sao chép ảnh in trên vải canvas rất rẻ, bản vẽ cũng tốn kém; vì vậy, bằng cách di chuyển các điểm nổi bật lên một canvas riêng biệt, chúng tôi tránh được chi phí đó khi bật và tắt tính năng đánh dấu.
Đã kiểm tra toàn diện quá trình phân tích cú pháp dấu vết
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 ngẫm về những lựa chọn kỹ thuật được đưa ra trước đây và tiến hành cải tiến. Một trong những điều chúng tôi muốn cải thiện là chia mã rõ ràng thành hai phần gần như hoàn toàn riêng 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 tập hợp các bản nhạc.
Việc tách biệt việc phân tích cú pháp (phần 1) với giao diện người dùng (phần 2) đã giúp chúng ta xây dựng được một hệ thống phân tích cú pháp vững chắc; mỗi dấu vết chạy qua một loạt Trình xử lý chịu trách nhiệm cho những 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 xử lý riêng các yêu cầu mạng. Việc triển khai bước phân tích rõ ràng này trong đó chúng tôi 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ể rất phức tạp và giúp việc có thể tập trung vào một mối quan ngại tại một thời điểm.
Chúng tôi cũng đã có thể kiểm tra toàn diện quá trình phân tích cú pháp theo dõi bằng cách ghi lại các bản ghi trong Công cụ cho nhà phát triển, lưu lại rồi tải chúng 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 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ả mạo có khả năng trở thành 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 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 chúng hoạt động như dự kiến; chúng tôi có thể điều phối các sự kiện nhấp chuột để 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 phù hợp với chúng ta nhưng lại gặp vấn đề khi xem xét kết xuất ảnh trên 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 tôi là không phù hợp.
Để có phạm vi kiểm thử nhất định, chúng tôi đã chuyển sang kiểm thử ảnh chụp màn hình. Mỗi hoạt động kiểm thử sẽ kích hoạt một canvas, kết xuất kênh mà chúng ta muốn kiểm thử, sau đó chụp ảnh màn hình phần tử canvas đó. Ảnh chụp màn hình này sau đó được lưu trữ trong cơ sở mã của chúng tôi và các lần chạy kiểm thử sau này 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 các ảnh chụp màn hình khác nhau, thử nghiệm sẽ không thành công. Chúng tôi cũng cung cấp cờ để chạy quy trình kiểm thử và buộc cập nhật ảnh chụp màn hình khi có chủ đích thay đổi kết xuất và cần cập nhật chương trình kiểm thử.
Thử nghiệm ảnh chụp màn hình không hoàn hảo và hơi chập chờn; bạn chỉ có thể kiểm thử để đảm bảo rằng toàn bộ thành phần hiển thị như dự kiến thay vì các câu nhận định cụ thể hơn. Ban đầu, chúng tôi có lỗi vì đã sử dụng quá nhiều chúng để đảm bảo mọi thành phần (HTML hoặc canvas) hiển thị chính xác. Điều này đã làm chậm bộ kiểm thử của chúng tôi đáng kể và dẫn đến các vấn đề khiến giao diện người dùng bị lỗi, gần như không có liên quan nếu điều chỉnh giao diện người dùng một chút, gần như không liên quan (chẳng hạn như thay đổi màu sắc khó thấy hoặc thêm một chút 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 phải cập nhật. Hiện chúng tôi đã thu hẹp lại việc sử dụng ảnh chụp màn hình và chỉ sử dụng chúng cho các thành phần dựa trên canvas. Cho đến nay, sự cân bằng này vẫn hoạt động hiệu quả.
Kết luận
Việc xây dựng bảng điều khiển mới cho Thông tin chi tiết về hiệu suất thực sự là một trải nghiệm rất thú vị và mang tính giáo dục cho nhóm. Chúng ta đã tìm hiểu rất nhiều về tệp theo dõi, cách xử lý canvas và nhiều kiến thức khác. Chúng tôi hy vọng bạn 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 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 cung cấp cho bạn quyền truy cập vào các tính năng mới nhất của Công cụ cho nhà phát triển, thử nghiệm API nền tảng web tiên tiến và tìm ra sự cố trên trang web của bạn trước khi người dùng của bạn làm điều đó!
Liên hệ với nhóm Công cụ của Chrome cho nhà phát triển
Sử dụng các lựa chọn sau đây để thảo luận về các tính năng mới và thay đổi trong bài đăng hoặc bất cứ vấn đề nào khác liên quan đến Công cụ cho nhà phát triển.
- Hãy gửi đề xuất hoặc phản hồi cho chúng tôi qua crbug.com.
- Báo cáo sự cố của Công cụ cho nhà phát triển bằng cách sử dụng phần Tuỳ chọn khác
> Trợ giúp > Báo cáo sự cố về Công cụ cho nhà phát triển trong Công cụ cho nhà phát triển. - Tweet tại @ChromeDevTools.
- Hãy để lại bình luận về tính năng mới trong video trên YouTube của Công cụ cho nhà phát triển hoặc video trên YouTube.