Bài viết dịch từ trang:
https://www.digitalocean.com/community/tutorials/how-to-use-chrome-dev-tools-to-find-performance-bottlenecks
Bài viết này viết về tab Audit hiện đã được thay bằng tab LightHouse. Do mình không tìm được bài viết chi tiết về cách sử dụng LightHouse nên mình sẽ dịch bài này. Audit và LightHouse khá là giống nhau nên các bạn có thể tham khảo.
Giới thiệu
Khi một người tiến bộ trong sự nghiệp phát triển phần mềm, có thể nảy sinh những mối quan tâm ngoài việc code. Trong thế giới phát triển web, không chỉ xây dựng phần mềm chức năng mà còn phải làm cho nó có hiệu suất cao để có thể liên tục mang lại trải nghiệm mong muốn trong khi vẫn sử dụng tài nguyên tối thiểu.
Thông thường, đây sẽ là một nhiệm vụ khá lớn vì người ta không thể đưa ra dự đoán về các thuộc tính tiêu thụ tài nguyên của một ứng dụng nếu không có các công cụ để mô phỏng và đo lường các thông số khác nhau.
Trong bài viết này, bạn sẽ khám phá một trong những công cụ sau: Chrome Dev Tools. Cụ thể, bạn sẽ học được tính tiện dụng của tab Audits và Performance trong việc đánh giá các ứng dụng web và phát hiện các vấn đề về hiệu suất.
Để làm cho bài kiểm tra này trở thành một bài kiểm tra thực tế, bạn sẽ thử nghiệm các kỹ thuật khác nhau để tìm ra các vấn đề về hiệu suất trên một trang web và giải quyết chúng. Hướng dẫn này khám phá trang web Scotch.io, nhưng các bước này có thể được áp dụng cho bất kỳ trang web nào.
Điều kiện tiên quyết
Cần cài đặt Google Chrome browser trước.
Bước 1 - Chuẩn bị trình duyệt
Khi cải thiện hiệu suất của một trang web hoặc ứng dụng web, có hai khía cạnh chính cần xem xét:
- Hiệu suất tải
- Hiệu suất thời gian chạy
Hướng dẫn này sẽ tập trung nhiều hơn vào Hiệu suất tải. Hiệu suất tải đề cập đến hiệu suất của trang khi nó đang tải. Mục tiêu chính là xác định các vấn đề về hiệu suất ảnh hưởng đến tốc độ ứng dụng và trải nghiệm người dùng tổng thể.
Để bắt đầu kiểm tra Hiệu suất tải, bạn sẽ bắt đầu bằng cách thiết lập kiểm tra (Audit).
Khởi chạy trình duyệt Chrome của bạn và mở một tab ở chế độ Ẩn danh bằng cách nhấn COMMAND + SHIFT + N trên macOS hoặc CTRL + SHIFT + N trên Windows hoặc Linux. Sau khi trình duyệt Ẩn danh được mở, hãy điều hướng đến trang web mà bạn muốn kiểm tra.
Tiếp theo, mở DevTools bằng cách nhấn COMMAND + OPTION + I trên macOS hoặc CTRL + SHIFT + I trên Windows hoặc Linux. Nếu bạn muốn thay đổi vị trí của bảng điều khiển DevTools, hãy nhấp vào ba chấm dọc trên thanh công cụ và thực hiện lựa chọn từ tùy chọn Dock Side.
Sau khi bạn hài lòng với vị trí bảng điều khiển, hãy chuyển sang tab Kiểm tra (Audits). Với sự trợ giúp của công cụ này, bạn sẽ tạo đường cơ sở để đo lường các thay đổi ứng dụng tiếp theo, cũng như nhận được thông tin chi tiết về những thay đổi nào sẽ cải thiện ứng dụng.
Lưu ý: Tab Kiểm tra có thể bị ẩn sau nút mũi tên Bảng khác (More Panels).
Mục tiêu chính của bạn ở đây là xác định các điểm nghẽn về hiệu suất trên trang Scotch.io và tối ưu hóa để có hiệu suất tốt hơn. Một nút thắt, trong kỹ thuật phần mềm, mô tả một tình huống mà dung lượng của một ứng dụng bị giới hạn bởi một component duy nhất.
Trong bước tiếp theo, bạn sẽ thực hiện kiểm tra để tìm kiếm các điểm nghẽn về hiệu suất.
Bước 2 - Thực hiện Kiểm tra
Khi thực hiện kiểm tra, bạn sẽ sử dụng một công cụ có tên là Lighthouse. Lighthouse là một công cụ tự động mã nguồn mở để cải thiện chất lượng của bất kỳ trang web nào trong các lĩnh vực hiệu suất, khả năng truy cập, các tính năng web và hơn thế nữa.
Trong tab Kiểm tra (Audits) của Chrome Dev Tools, hãy cấu hình công cụ kiểm tra (Audits). Cài đặt default như sau:
Thiết bị
Có tùy chọn chuyển đổi giữa Mobile và Desktop. Hơn một nửa lưu lượng truy cập web tính đến quý 3 năm 2018 là do Thiết bị di động tạo ra, vì vậy chúng tôi sẽ kiểm tra Scotch.io trên Mobile.
Kiểm tra (Audits)
Cài đặt này cho phép chúng ta chọn chất lượng của ứng dụng mà chúng tôi muốn đánh giá và cải thiện. Trong trường hợp này, hiệu suất là mối quan tâm chính, vì vậy bạn có thể bỏ chọn mọi tùy chọn khác.
Throttling
Tùy chọn này cho phép bạn mô phỏng các điều kiện duyệt web trên thiết bị di động. Bạn sẽ sử dụng tùy chọn Sim Simulated Fast 3G, 4x CPU Slowdown. Điều này thực sự sẽ không hiệu quả trong quá trình kiểm tra, nhưng nó sẽ giúp tính toán thời gian tải trang trong điều kiện thiết bị di động.
Xóa Lưu trữ
Điều này cho phép bạn xóa tất cả dữ liệu được lưu trong bộ nhớ cache và tài nguyên trang web thử nghiệm, để kiểm tra đối với khách lần đầu truy cập sẽ có trải nghiệm như nào, vì vậy hãy chọn tùy chọn này nếu nó chưa được chọn.
Sau khi định cấu hình kiểm tra như đã chỉ định ở trên, hãy ấn Generate report và đợi trong khi Audit chuẩn bị báo cáo chi tiết về hiệu suất của trang web.
Bước 3 - Phân tích Báo cáo đánh giá
Sau khi hoàn thành kiểm tra, báo cáo sẽ có dạng như sau:
Con số trong một vòng tròn ở trên cùng bên phải cho biết điểm hiệu suất tổng thể của trang web trên thang điểm từ 1–100. Chúng ta hiện có 55, điều này cho thấy rằng có một cơ hội để cải thiện cùng với các đề xuất được cung cấp để tăng điểm số và hiệu suất. Hãy chia báo cáo thành các phần và phân tích chúng riêng lẻ.
Trong phần Metrics, bạn sẽ tìm thấy thông tin chi tiết định lượng về các khía cạnh khác nhau về hiệu suất của trang web:
Ngay bên dưới phần Metrics là một nhóm ảnh chụp màn hình hiển thị các trạng thái giao diện người dùng khác nhau của trang từ thời điểm truy vấn ban đầu cho đến khi tải hoàn toàn:
Phần Diagnostics cung cấp cho bạn thông tin bổ sung về hiệu suất, thường chỉ ra các yếu tố xác định thời gian tải của trang web:
Cuối cùng, phần Audits đạt yêu cầu nêu bật các kiểm tra hiệu suất đã được trang web vượt qua:
Với bản báo cáo, bạn biết những vấn đề nào có thể cần được giải quyết.
Bước 4 - Giải quyết vấn đề trong phần Metrics
Trong ví dụ này, năm vấn đề về hiệu suất đã được đánh dấu. Trong bước này, chúng tôi sẽ khám phá các bản sửa lỗi có thể có:
First Meaningful Paint
First Meaningful Paint cho bạn biết khi nào nội dung chính của trang nhìn thấy được. Theo đánh giá, bạn sẽ mất khoảng 3,4 giây trước khi xem nội dung chính. Điều này có thể được xác nhận bằng cách nhấp vào button View Trace. Thao tác này sẽ đưa bạn đến tab Performance, nơi bạn có thể xem qua các trạng thái giao diện người dùng khác nhau trong thời gian tải để xác nhận điều gì xảy ra tại từng thời điểm cụ thể.
Lưu ý rằng đó là lúc nội dung trang được hiển thị.
Để cải thiện điều này, chúng tôi phải tối ưu hóa đường dẫn hiển thị quan trọng của trang / ứng dụng tổng thể. Điều này có nghĩa là chúng ta ưu tiên hiển thị nội dung theo mong muốn của người dùng nhằm tạo ra trải nghiệm tốt hơn và cải thiện hiệu suất. Điều này có thể được thực hiện bằng cách giảm số lượng tài nguyên quan trọng, độ dài đường dẫn quan trọng và số byte quan trọng.
Speed Index
Speed Index cho biết nội dung trang được hiển thị nhanh như thế nào. Quá trình này mất khoảng 7,2 giây như được hiển thị trên tab hiệu suất:
Một cách để khắc phục điều này, giống như trong số liệu đã kiểm tra trước đó, là tối ưu hóa đường dẫn hiển thị quan trọng. Cách thứ hai là tối ưu hóa hiệu quả nội dung. Điều này liên quan đến việc loại bỏ các bản tải xuống không cần thiết theo cách thủ công, tối ưu hóa mã hóa truyền tải thông qua nén và lưu vào bộ nhớ đệm bất cứ khi nào có thể để ngăn tải lại các tài nguyên không thay đổi.
First CPU Idle
Còn được gọi là First Interactive, First CPU Idle cho bạn biết khi nào trang trở nên tương tác tối thiểu (CPU không hoạt động đủ để xử lý thông tin nhập của người dùng, như nhấp chuột, vuốt, v.v.). Từ quá trình kiểm tra, quá trình này mất khoảng 6,5 giây. Giảm giá trị này xuống mức tối thiểu luôn tốt hơn:
Time to Interactive
Time to Interactive cho biết thời gian cần thiết để trang có thể tương tác hoàn toàn. Quá trình kiểm tra trong ví dụ này cho thấy 6,9 giây cho số liệu này. Tương tác trong ngữ cảnh này mô tả điểm mà:
- Trang đã hiển thị nội dung hữu ích.
- Trình xử lý sự kiện được gán cho hầu hết các phần tử hiển thị trên trang.
- Trang phản hồi các tương tác của người dùng trong vòng 50 mili giây.
Để khắc phục điều này, bạn cần loại bỏ những công việc JavaScript không cần thiết xảy ra trong quá trình tải trang. Điều này thường có thể đạt được bằng cách code splitting và lazy loading (Ai làm React nhớ cho cái này vào nhé), nén, rút gọn và bằng cách xóa code không sử dụng (bảo sao phải cài eslint) và bộ nhớ đệm không sử dụng.
Estimated Input Latency
Estimated Input Latency mô tả khả năng đáp ứng của ứng dụng đối với đầu vào của người dùng. Quá trình kiểm tra ghi lại khoảng 170 mili giây trên số liệu này. Các ứng dụng thường có 100 mili giây để phản hồi thông tin nhập của người dùng, tuy nhiên, mục tiêu cho Lighthouse là 50 mili giây. Lý do cho sự chênh lệch này là do Lighthouse sử dụng chỉ số proxy, là tính khả dụng của luồng chính để đánh giá chỉ số này thay vì đo lường trực tiếp.
Sau khi mất nhiều thời gian hơn thời gian quy định, ứng dụng có thể bị coi là chậm.
Để cải thiện số liệu này, bạn có thể sử dụng service worker thực hiện một số tính toán, để giải phóng luồng chính. Một biện pháp hữu ích khác là cấu trúc lại CSS selectors để đảm bảo chúng thực hiện ít phép tính hơn.
Bước 5 - Giải quyết các vấn đề trong phần Opportunities
Phần Opportunities liệt kê các tối ưu hóa có thể cải thiện hiệu suất:
Thông thường, khi các trang web tải, chúng sẽ kết nối với các nguồn khác (server) để nhận hoặc gửi dữ liệu. Để cải thiện hiệu suất như trong trường hợp này, cách tốt nhất là thông báo cho trình duyệt để thiết lập kết nối với các server như vậy sớm hơn trong quá trình hiển thị, do đó cắt giảm lượng thời gian chờ giải quyết các tra cứu DNS, chuyển hướng và một số lần quay lại và hơn thế nữa cho đến khi khách hàng nhận được phản hồi.
Để khắc phục điều này, bạn có thể thông báo cho trình duyệt về ý định sử dụng các tài nguyên đó bằng cách thêm thuộc tính rel vào các thẻ liên kết như được hiển thị bên dưới:
<link rel="preconnect" href="https://scotchresources.com">
Trên các kết nối an toàn, quá trình này vẫn có thể mất một chút thời gian, vì vậy nó phải được sử dụng trong vòng 10 giây, nếu không trình duyệt sẽ tự động đóng kết nối và tất cả công việc kết nối ban đầu sẽ trở nên lãng phí.
Top comments (0)