Helpex - Trao đổi & giúp đỡ Đăng nhập

Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools

Gần đây, nhóm của tôi được giao nhiệm vụ cung cấp một phiên bản giới hạn của Lucidchart để nhúng vào bên trong một ứng dụng khác. Bởi vì Lucidchart sẽ chỉ đại diện cho một phần nhỏ trong tổng số chức năng hiển thị cho người dùng, chúng tôi muốn đảm bảo rằng chúng tôi không làm giảm thời gian tải tổng thể.

Tổng ngân sách thời gian của chúng tôi để tải ứng dụng và hiển thị nội dung do người dùng tạo là 2 giây . Đó là khoảng một nửa thời gian tải trung bình của ứng dụng đầy đủ của chúng tôi.

Khoảng một tháng sau, chúng tôi đã hoàn thành mục tiêu đó. Đây là cách chúng tôi đã làm điều đó.

Tiến độ đo lường đáng tin cậy

Thời gian tải của một ứng dụng web phức tạp phụ thuộc vào nhiều yếu tố khác nhau bên ngoài nội dung thực tế mà bạn gửi đến trình duyệt. Các yếu tố này bao gồm:

  • Thông lượng mạng
  • Độ trễ và độ tin cậy của mạng
  • Trạng thái bộ nhớ cache của trình duyệt
  • Nguồn CPU có sẵn

Để đo lường một cách đáng tin cậy mức độ hoạt động của một nỗ lực tối ưu hóa cụ thể, chúng tôi cần giảm tác động của những yếu tố đó lên hiệu suất được đo của chúng tôi. Để đạt được điều đó, quy trình đo điểm chuẩn của chúng tôi như sau:

  • Chạy trên phần cứng đã biết — máy tính xách tay phát triển Linux tiêu chuẩn (Lenovo P50, i7, RAM 32 GB, SSD)
  • Chạy khi khởi chạy Chrome mới
  • Trong Công cụ dành cho nhà phát triển của Chrome:

    1. Tắt bộ nhớ cache của trình duyệt
    2. Tiết kiệm băng thông thành “3G nhanh”
    3. Điều chỉnh tốc độ CPU để giảm tốc độ 4x

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools

    Việc điều chỉnh lại băng thông và CPU không chỉ mang lại kết quả thực tế hơn mà còn làm cho các phép đo kết quả đáng tin cậy hơn từ lần chạy thử nghiệm này đến lần chạy thử nghiệm tiếp theo. Mỗi lần chúng tôi muốn kiểm tra hiệu suất, chúng tôi đã chạy toàn bộ quy trình (tắt Chrome, khởi động nó, thiết lập công cụ dành cho nhà phát triển, tải trang) ba lần để đảm bảo rằng phép đo của chúng tôi không phải là ngoại lệ.

    Để đạt được thời gian tải 2 giây ở tốc độ tối đa, chúng tôi đặt mục tiêu là thời gian tải 9 giây trong bộ nhớ đệm lạnh, được điều chỉnh. Trong lần đo đầu tiên của chúng tôi, chúng tôi đã ở khoảng 13 giây.

    Cắt giảm chất béo

    Công cụ chính mà chúng tôi sử dụng để phân tích hiệu suất tải là tab Hiệu suất của Chrome DevTools, tab này trình bày chi tiết cả hoạt động mạng và CPU trên một biểu đồ:

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools
    Một cấu hình hiệu suất mẫu sử dụng tab Hiệu suất Chrome DevTools


    Điều đầu tiên chúng tôi thấy trong hồ sơ hiệu suất là chúng tôi đã dành khoảng 6,5 giây trong tổng ngân sách 9 giây của mình chỉ để tải xuống ứng dụng. Hầu như tất cả những thứ đó đều là Javascript.

    Lúc đầu, chúng tôi đã đạt được lợi nhuận nhanh chóng so với tổng trọng lượng mã bằng cách loại bỏ các phần phụ thuộc mà chúng tôi không cần. Ví dụ: chúng tôi biết rằng ứng dụng nhúng của chúng tôi không cần bất kỳ giao diện người dùng dựa trên Angular 1 cũ hơn của chúng tôi, vì vậy chúng tôi có thể xóa toàn bộ thời gian chạy Angular 1 khỏi gói phụ thuộc của bên thứ ba. Tổng cộng, chúng tôi đã cắt giảm một nửa sự phụ thuộc vào bên thứ ba của mình, để tiết kiệm khoảng 150KB được nén.

    Sau đó, chúng tôi xem xét mã ứng dụng cốt lõi của riêng mình. Chúng tôi đã sử dụng dự án source-map-explorer tuyệt vời để kiểm tra các gói Javascript đã biên dịch của mình. Công cụ này cung cấp cho bạn cái nhìn tổng quan trực quan về trọng lượng mã cuối cùng (chưa giải nén) đến từ mỗi tệp nguồn và thư mục.


    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools
    source-map-explorer cho phép bạn xem trọng lượng tải xuống của bạn bắt nguồn từ đâu.


    Kiểm tra xem trọng lượng mã của chúng tôi đến từ đâu, chúng tôi đã xác định một số phần tử giao diện người dùng mà chúng tôi không cần trong ứng dụng được nhúng của mình và cấu trúc lại các mô-đun TypeScript của chúng tôi để nhiều phần tử trong số đó không còn được yêu cầu trong mục tiêu xây dựng cụ thể này. Chỉ một vài kilobyte mỗi lần, chúng tôi từ từ loại bỏ hàng trăm kilobyte mã không cần thiết.

    Chúng tôi cũng nhận thấy rằng khá nhiều trọng lượng mã (chưa giải nén) của chúng tôi đến từ chỉ mục tìm kiếm của tất cả các hình dạng của Lucidchart. Vì chúng tôi không cần chỉ mục đó cho đến khi người dùng thực sự bắt đầu tìm kiếm các hình dạng, chúng tôi đã kéo nó ra thành một nội dung riêng biệt mà chúng tôi có thể tải xuống ngay khi tìm kiếm.

    Brotli để giải cứu

    Sau tất cả những điều đó, trọng lượng mã của chúng tôi đã giảm đáng kể và phần tải xuống trong thời gian khởi động bị điều chỉnh của chúng tôi đã giảm từ 6,5 giây xuống còn khoảng 5,1 giây. Nhưng để đạt được mục tiêu của mình, chúng tôi cần phải giảm bớt điều đó một chút nữa và chúng tôi không còn có một lượng lớn mã mà chúng tôi có thể bỏ qua hoặc dễ dàng trì hoãn.

    James Judd đề xuất chúng tôi thử sử dụng Brotli thay vì gzip để nén nội dung tĩnh của chúng tôi, vì gần như tất cả các trình duyệt được hỗ trợ của chúng tôi đều cung cấp hỗ trợ Brotli tốt.

    Brotli là một định dạng nén không mất dữ liệu mã nguồn mở được xây dựng bởi Google, nén khá chậm nhưng giải nén với tốc độ tương đương với gzip. Vì vậy, mặc dù bạn sẽ không bao giờ sử dụng Brotli để phân phát nội dung được tạo động, nhưng nó hoạt động thực sự tốt cho các nội dung Javascript và CSS.

    Trên thực tế, chúng tôi đã thấy tổng quy mô nội dung giảm 15-20% bằng cách sử dụng brotli thay vì gzip cho nội dung chính của chúng tôi, nâng tổng thời gian tải xuống của chúng tôi lên khoảng 4,5 giây và để lại 4,5 giây để thực sự phân tích cú pháp / biên dịch / thực thi các tập lệnh của chúng tôi, tải lên nội dung của người dùng và hiển thị nội dung đó cho họ trên màn hình.

    Giữ tất cả phần cứng bận rộn

    Có hai tài nguyên chính mà bạn chờ đợi khi ứng dụng của bạn đang tải: mạng và CPU. Sau khi công việc quan trọng của chúng tôi làm giảm tổng trọng lượng tải xuống, hồ sơ thời gian tải của chúng tôi trông giống như sau:

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools

    Sau khi tải xong phần tải chính của chúng tôi, chúng tôi đã dành khoảng 1,1 giây để phân tích cú pháp và đánh giá tập lệnh của mình, sau đó 1,8 giây nữa để xây dựng các lớp ứng dụng cốt lõi của chúng tôi. Sau đó, CPU hầu như không hoạt động trong khoảng 1,3 giây trước khi cuối cùng tải và hiển thị tài liệu của người dùng.

    Nó chỉ ra rằng một trong những điều đầu tiên mà các lớp ứng dụng của chúng tôi làm sau khi được khởi tạo là kiểm tra thư viện hình dạng nào cần thiết để hiển thị tài liệu hiện tại và tải xuống mã cho các hình dạng đó. Cùng lúc đó, chúng tôi bắt đầu tải xuống thư mục các phông chữ có sẵn cũng như các phông chữ cụ thể được sử dụng trên tài liệu.

    Trong khi chờ tải các nội dung đó xuống, CPU chỉ đứng yên vì ứng dụng của chúng ta chưa có đủ thông tin để thực hiện công việc của nó. Để cải tiến, chúng tôi đã tiến hành xử lý vừa đủ để biết nội dung nào trong số đó cần tải xuống, điều này cho phép mạng tiếp tục hoạt động trong khi chúng tôi khởi tạo phần còn lại của ứng dụng trên CPU.

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools

    Tuy nhiên, vẫn còn một khoảng cách có ý nghĩa, bởi vì bây giờ chúng tôi đã tải xuống đồng thời các phông chữ và thư viện hình dạng, chúng mất nhiều thời gian để tải xuống hơn trước. Chúng tôi quyết định có thể đưa một số thông tin phông chữ vào ứng dụng chính và sử dụng bộ nhớ trong trình duyệt (như IndexedDB) để hiếm khi cần tải xuống bất kỳ thông tin phông chữ nào.

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools

    Nói chung, điều này làm giảm thời gian CPU nhàn rỗi của chúng tôi từ 1,3 giây xuống còn khoảng 0,2 giây.

    Trì hoãn tất cả mọi thứ

    Vào thời điểm này, chúng tôi đã tiến gần đến mục tiêu hiệu suất tổng thể của mình. Nhưng chúng tôi vẫn còn một chặng đường nhỏ để đi, và không còn mục tiêu lớn, rõ ràng trên hồ sơ hiệu suất. Vì vậy, chúng tôi bắt đầu xem xét các mục tiêu nhỏ hơn.

    Chúng tôi đã kiểm tra mọi yêu cầu mạng được gửi đi trong quá trình khởi tạo ứng dụng của mình và xác định rằng gần như tất cả chúng đều có thể đợi. Đang tải một API YouTube nhỏ trong trường hợp người dùng đã nhúng video YouTube vào sơ đồ của họ? Hãy chờ cho đến khi chúng tôi thực sự xác minh rằng có một video YouTube. Kiểm tra danh sách các kênh Slack trong trường hợp chúng đã tích hợp với Slack để chia sẻ sơ đồ? Hãy đợi cho đến khi họ mở hộp thoại chia sẻ. Đang tải từ điển gạch nối? Hãy đợi cho đến khi người dùng thực sự bật dấu gạch nối. Đăng ký kênh tin nhắn trò chuyện trên sơ đồ? Nó có thể đợi cho đến vài giây sau khi tài liệu được tương tác.

    Sau đó, chúng tôi bắt đầu tìm kiếm các bit công việc của CPU mà chúng tôi có thể trì hoãn. Việc khởi tạo các phần tử giao diện người dùng như một số hộp thoại có thể đợi cho đến khi chúng hiển thị. Việc khởi tạo các lớp cung cấp dữ liệu cho các phần tử giao diện người dùng (ví dụ: “nút in đậm có được kích hoạt hay không”) có thể được hoãn lại cho đến khi chúng được truy cập lần đầu.

    Sự thành công

    Cuối cùng, chúng tôi đã thành công trong việc giảm thời gian tải điều tiết xuống mục tiêu 9 giây của chúng tôi.

    Con đường quan trọng: Tối ưu hóa thời gian tải với Chrome DevTools
    Các chú thích màu đỏ tóm tắt những yếu tố đóng góp chính cho thời gian tải cuối cùng


    Khi chúng tôi tắt tất cả điều chỉnh và chạy ứng dụng với tốc độ tối đa trong môi trường sản xuất, kết quả của nỗ lực của chúng tôi thật đáng kinh ngạc. Chúng tôi đã dễ dàng vượt qua mục tiêu 2 giây của mình. Và phần tốt nhất? Nhiều lợi ích trong số đó cũng dễ dàng áp dụng cho trải nghiệm trình chỉnh sửa đầy đủ của Lucidchart, làm giảm thời gian tải trung bình của chúng tôi tại lucidchart.com hơn 10%.

    TL; DR

    Cải thiện thời gian tải trên một ứng dụng web phức tạp thường yêu cầu cải tiến trong một số lĩnh vực khác nhau và các phép đo cẩn thận trong quá trình thực hiện có thể đảm bảo bạn đang đầu tư tốt.

    Cải thiện độ chính xác của các phép đo thời gian tải của bạn bằng cách sử dụng chúng trên phần cứng đã biết, với băng thông và tốc độ CPU được điều chỉnh.

    Giảm trọng lượng mã là rất quan trọng. Kiểm tra sự phụ thuộc của bên thứ ba cũng như mã của riêng bạn.

    Nén Brotli có thể mang lại mức tăng lớn về trọng lượng tải xuống cho các tài sản tĩnh như mã.

    Thực hiện các yêu cầu mạng càng sớm càng tốt, và không thường xuyên nhất có thể, để giảm thời gian CPU bị lãng phí khi chờ mạng.

    Trì hoãn nhiều công việc nhất có thể cho đến khi ứng dụng của bạn được tải và tương tác.

    Chúc may mắn ngoài kia!

    4 hữu ích 0 bình luận 4.9k xem chia sẻ

    Có thể bạn quan tâm

    loading