Trước khi đi sâu vào chi tiết tối ưu hiệu suất JavaScript, chúng ta hãy hiểu rộng hơn về vấn đề này bằng cách trả lời những câu hỏi sau: JavaScript được coi là hiệu suất cao và JavaScript phù hợp với phạm vi rộng của chỉ số hiệu suất web như thế nào?
Sắp đặt Sân khấu
Trước hết, hãy hiểu những điều sau: nếu bạn đang testing riêng trên thiết bị máy tính, bạn sẽ loại trừ hơn 50% người dùng của mình.
Xu hướng này sẽ chỉ tiếp tục phát triển vì các thiết bị Android dưới 100 đô la ngày càng nhiều lên. Kỷ nguyên của máy tính là thiết bị chính để truy cập Internet đã qua và hàng tỷ người dùng internet tiếp theo sẽ truy cập các trang web của bạn chủ yếu thông qua thiết bị di động.
Testing trong chế độ Chome DevTool’s device không thế thay thế cho việc testing trong thiết bị thực. Sử dụng CPU và điều chỉnh mạng có ích, nhưng về cơ bản nó là một thứ khác. Hãy Test trên các thiết bị thực tế.
Mặc dù hình ảnh này chỉ bao gồm thời gian phân tích cú pháp và biên dịch của JS chứ không phải hiệu suất chung, nhưng nó có tương quan chặt chẽ và có thể được coi là một chỉ báo về hiệu suất JS.
Vậy chính xác thì Hiệu suất JS Code là gì?
Bây giờ chúng ta đã biết nền tảng mục tiêu của là gì, lời câu hỏi tiếp theo: Hiệu suất JS code là gì?
Mặc dù không có phân loại tuyệt đối nào xác định hiệu suất code, nhưng chúng ta có một mô hình hiệu suất lấy người dùng làm trung tâm mà chúng ta có thể tham khảo:: The RAIL model.
Respond
Nếu ứng dụng của bạn phản hồi một hành động của người dùng trong dưới 100 mili giây, người dùng sẽ coi phản hồi là ngay lập tức.
Điều này áp dụng cho các phần tử có thể chạm được, nhưng không áp dụng khi cuộn hoặc kéo.
Animate
Trên màn hình 60Hz, chúng tôi muốn nhắm mục tiêu 60 khung hình / giây không đổi khi tạo hoạt ảnh và cuộn.
Điều đó dẫn đến khoảng 16ms mỗi khung hình.
Trong số ngân sách 16 mili giây đó, bạn thực tế có 8–10 mili giây để thực hiện tất cả công việc, phần còn lại do nội bộ trình duyệt và các phương án khác đảm nhận.
Idle work
Hãy đảm bảo chia nó thành nhiều phần nhỏ hơn để cho phép luồng chính phản ứng với đầu vào của người dùng. Bạn không nên có tác vụ làm chậm quá trình nhập của người dùng hơn 50 mili giây.
Load
Bạn nên nhắm mục tiêu tải trang dưới 1000 mili giây.
Mọi thứ đã kết thúc và người dùng của bạn bắt đầu trở nên khó chịu.
Đây là một mục tiêu khá khó để đạt được trên thiết bị di động vì nó liên quan đến việc trang có tính tương tác, chứ không chỉ để nó được vẽ trên màn hình và có thể cuộn được. Trong thực tế, nó thậm chí còn ít hơn:
Trong thực tế, hãy nhắm đến mốc thời gian tương tác 5 giây. Đó là những gì Chrome sử dụng trong quá trình kiểm tra Lighthouse.
Bây giờ chúng ta đã biết các số liệu, hãy cùng xem một số thống kê:
- 53% lượt truy cập bị bỏ qua nếu một trang web trên thiết bị di động mất hơn ba giây để tải
- 1 trong số 2 người mong đợi một trang tải trong vòng chưa đầy 2 giây
- 77% trang web di động mất hơn 10 giây để tải trên mạng 3G
- 19 giây là thời gian tải trung bình cho các trang web di động trên mạng 3G.
- Ứng dụng trở nên tương tác trong 8 giây trên máy tính để bàn (sử dụng cáp) và 16 giây trên thiết bị di động (Moto G4 qua 3G)
- Ở mức trung bình, các nhà phát triển đã vận chuyển 410KB JS được nén cho các trang của họ.
Cảm thấy đủ thất vọng? Tốt. Hãy bắt đầu làm việc và sửa chữa web. ✊
Context is Everything
Bạn có thể nhận ra rằng mấu chốt là thời gian cần thiết để load trang web của bạn. Cụ thể là thời gian tải xuống, phân tích cú pháp, biên dịch và thực thi JavaScript. Không có cách nào khác ngoài việc tải ít JavaScript hơn và tải thông minh hơn.
Nhưng còn công việc thực tế mà code của bạn thực hiện ngoài việc khởi động trang web thì sao? Phải có một số tăng hiệu suất ở đó, phải không?
Trước khi bạn đi sâu vào tối ưu hóa mã của mình, hãy xem xét những gì bạn đang xây dựng. Bạn đang xây dựng một framework hoặc một thư viện VDOM? Mã của bạn có cần thực hiện hàng nghìn thao tác mỗi giây không? Bạn có đang tạo một thư viện quan trọng về thời gian để xử lý đầu vào của người dùng và hoặc animation không?
Nếu không, bạn có thể dành thời gian và năng lượng của mình đến một nơi nào đó có tác động hơn.
Không phải là viết mã hiệu quả không quan trọng, nhưng nó thường tạo ra ít hoặc không có tác động trong kế hoạch tổng thể của mọi thứ, đặc biệt là khi nói về vi mô.
Vì vậy, trước khi bạn tranh luận về Stack Overflow về các vòng lặp .map so với .forEach so với for bằng cách so sánh kết quả từ JSperf.com, hãy đảm bảo bạn nhìn thấy rừng chứ không chỉ cây. 50k ops/s nghe có vẻ tốt hơn 50 lần so với 1k ops/s trên giấy, nhưng nó sẽ không tạo ra sự khác biệt trong hầu hết các trường hợp.
Parsing, Compiling and Executing
Về cơ bản, vấn đề của hầu hết các JS không hoạt động không phải là tự code đó, mà là tất cả các bước phải được thực hiện trước khi mã bắt đầu thực thi.
Chúng ta đang nói về mức độ trừu tượng ở đây. CPU trong máy tính của bạn chạy mã máy. Hầu hết mã bạn đang chạy trên máy tính của mình ở định dạng nhị phân đã biên dịch. Có nghĩa là, tất cả những điều trừu tượng ở cấp độ hệ điều hành sang một bên, nó chạy tự nhiên trên phần cứng của bạn.
JavaScript không được biên dịch trước. Nó đến (qua một mạng tương đối chậm) dưới dạng mã có thể đọc được trong trình duyệt của bạn, cho tất cả các mục đích, là “Hệ điều hành” cho chương trình JS của bạn.
Trước tiên, mã đó cần được phân tích cú pháp — nghĩa là, đọc và biến thành một cấu trúc máy tính có thể lập chỉ mục có thể được sử dụng để biên dịch. Sau đó, nó được biên dịch thành mã bytecode và cuối cùng là mã máy, trước khi thiết bị / trình duyệt của bạn thực thi.
Một điều rất quan trọng khác cần đề cập là JavaScript là một luồng và chạy trên luồng chính của trình duyệt. Điều này có nghĩa là chỉ một tiến trình có thể chạy tại một thời điểm. Nếu dòng thời gian hiệu suất DevTools của bạn chứa đầy các đỉnh màu vàng, CPU của bạn đang chạy ở mức 100%, bạn sẽ có các khung hình dài / giảm, cuộn nhanh và tất cả các loại nội dung khó chịu khác.
Vì vậy, có tất cả công việc này cần được thực hiện trước khi JS của bạn bắt đầu hoạt động.
Phân tích cú pháp và biên dịch chiếm tới 50% tổng thời gian thực thi JS trong công cụ V8 của Chrome.
Có hai điều bạn nên chú ý trong phần này:
- Mặc dù không nhất thiết phải tuyến tính, nhưng thời gian phân tích cú pháp JS sẽ chia tỷ lệ với kích thước gói. Bạn gửi càng ít JS càng tốt.
- Mỗi framework JS mà bạn sử dụng (React, Vue, Angular, Preact…) là một cấp độ trừu tượng khác (trừ khi nó là được biên dịch trước, như Svelte). Nó không chỉ tăng kích thước gói của bạn mà còn làm chậm mã của bạn vì bạn không nói chuyện trực tiếp với trình duyệt.
Có nhiều cách để giảm thiểu điều này, chẳng hạn như sử dụng nhân viên dịch vụ để thực hiện các công việc trong nền và trên một chuỗi khác, sử dụng asm.js để viết mã dễ dàng biên dịch hơn cho hướng dẫn máy, nhưng đó là cả một chủ đề riêng.
Những gì bạn có thể làm là tránh sử dụng các JS animation framework cho mọi thứ và đọc kỹ những gì kích hoạt giao điện và bố cục. Chỉ sử dụng các thư viện khi hoàn toàn không có cách nào để triển khai hoạt ảnh bằng cách sử dụng chuyển tiếp và hoạt ảnh CSS thông thường.
Mặc dù có thể đang sử dụng CSS transition, thuộc tính tổng hợp và requestAnimationFrame(), chúng vẫn đang chạy trong JS, trên chuỗi chính. Bạn cần đảm bảo rằng tất cả JS của bạn sẽ được thực thi trong thời gian dưới 8ms mỗi khung hình để giữ cho các hoạt ảnh mượt mà.
Mặt khác, CSS animations and transitions đang chạy ngoài luồng chính — trên GPU, nếu được triển khai hiệu quả, nó không gây ra chuyển tiếp/chuyển dòng.
Lưu ý các animations chạy khi tải trang hoặc tương tác với người dùng, điều này cung cấp cho các ứng dụng web của bạn một khoảng trống cần thiết để thở.
Bundle Sizes are Everything
Ngày này là thời của các gói – bundles. Đã qua thời của Bower và hàng tá các thẻ <script>.
Giờ đây, tất cả chỉ là việc cài đặt npm – cài đặt bất thứ gì bạn tìm thấy trên NPM, gộp chúng lại với Webpack trong một tệp JS khổng lồ 1MB duy nhất.
Hãy thử vận chuyển ít JS hơn. Bạn có thể không cần toàn bộ thư viện Lodash cho dự án của mình.
Bạn có nhất thiết phải sử dụng framework JS không? Nếu có, bạn đã cân nhắc sử dụng thứ gì đó khác ngoài React, chẳng hạn như Preactor hoặc HyperHTML, có kích thước nhỏ bằng 1/20 của React ? Bạn có cần TweenMax cho hoạt ảnh cuộn lên đầu không?
Sự tiện lợi của npm và các thành phần biệt lập trong các khuôn khổ đi kèm với một nhược điểm:
- Phản ứng đầu tiên của các developer đối với một vấn đề đã trở thành ném nhiều JS hơn vào nó.
- Khi tất cả những gì bạn có là một cái búa, mọi thứ trông giống như một cái đinh.
Khi bạn đã cắt tỉa xong cỏ dại và gửi ít JS hơn, hãy thử gửi JS thông minh hơn. Vận chuyển những gì bạn cần, khi bạn cần.
Webpack 3 có các tính năng tuyệt vời được gọi là tách mã và nhập động.
Thay vì gói tất cả các module JS của bạn thành một gói app.js nguyên khối, nó có thể tự động tách mã bằng cú pháp import() và tải nó một cách không đồng bộ.
Kết luận
Điều tôi muốn bạn thu được từ bài viết này là JS đắt và nên được sử dụng một cách tiết kiệm.
Đảm bảo bạn kiểm tra hiệu suất trang web của mình trên các thiết bị cấp thấp, trong điều kiện mạng thực. Trang web của bạn sẽ tải nhanh và tương tác càng sớm càng tốt.
Điều này có nghĩa là vận chuyển ít JS hơn và vận chuyển nhanh hơn bằng mọi cách cần thiết.
Mã của bạn phải luôn được rút gọn, chia thành các gói nhỏ hơn, dễ quản lý và được tải không đồng bộ bất cứ khi nào có thể. Về phía máy chủ, hãy đảm bảo nó đã bật HTTP/2 để truyền song song nhanh hơn và nén gzip / Brotli để giảm đáng kể kích thước truyền JS của bạn.