Không có cách nào nhanh hơn để làm chậm một trang web (ý định chơi chữ) hơn là sử dụng một loạt mã JavaScript trên đó. Khi sử dụng JavaScript, bạn phải trả giá cho nó bằng hiệu suất của các dự án không dưới bốn lần. Đây là cách mã JavaScript của trang web tải hệ thống của người dùng:
- Đang tải một tập tin qua mạng.
- Phân tích cú pháp và biên dịch mã nguồn đã giải nén sau khi tải xuống.
- Thực thi mã JavaScript.
- Tiêu thụ bộ nhớ.
Sự kết hợp này hóa ra .
Và chúng tôi đưa ngày càng nhiều mã JS vào các dự án của mình. Khi các tổ chức hướng tới các trang web được cung cấp bởi các khung và thư viện như React, Vue và các trang khác, chúng tôi đang làm cho chức năng cốt lõi của các trang web phụ thuộc rất nhiều vào JavaScript.
Tôi đã thấy rất nhiều trang web rất nặng sử dụng khung JavaScript. Nhưng tầm nhìn của tôi về vấn đề này rất thiên vị. Thực tế là các công ty tôi làm việc tìm đến tôi chính xác vì họ đang phải đối mặt với những vấn đề phức tạp trong lĩnh vực hiệu suất trang web. Do đó, tôi bắt đầu tò mò về mức độ phổ biến của vấn đề này và về loại "hình phạt" mà chúng tôi phải trả khi chọn một hoặc một khung khác làm cơ sở cho một trang web nhất định.
Dự án đã giúp tôi tìm ra điều này. .
Dữ liệu
Dự án Lưu trữ HTTP theo dõi tổng cộng 4308655 liên kết đến các trang web dành cho máy tính để bàn thông thường và 5484239 liên kết đến các trang web dành cho thiết bị di động. Trong số nhiều số liệu liên quan đến các liên kết này là danh sách các công nghệ được tìm thấy trên các trang web tương ứng. Điều này có nghĩa là chúng tôi có thể lấy mẫu hàng nghìn trang web sử dụng các khung và thư viện khác nhau, đồng thời tìm hiểu về lượng mã chúng gửi cho khách hàng và lượng tải mà mã này tạo ra trên hệ thống của người dùng.
Tôi đã thu thập dữ liệu của tháng 2020 năm XNUMX, đây là dữ liệu gần đây nhất mà tôi có quyền truy cập.
Tôi quyết định so sánh dữ liệu Lưu trữ HTTP tổng hợp trên tất cả các trang web với dữ liệu từ các trang web được tìm thấy bằng React, Vue và Angular, mặc dù tôi cũng cân nhắc sử dụng tài liệu nguồn khác.
Để làm cho nó thú vị hơn, tôi cũng đã thêm các trang web sử dụng jQuery vào tập dữ liệu nguồn. Thư viện này vẫn còn rất phổ biến. Nó cũng giới thiệu một cách tiếp cận khác để phát triển web so với mô hình Ứng dụng một trang (SPA) do React, Vue và Angular cung cấp.
Các liên kết trong Lưu trữ HTTP đại diện cho các trang web được phát hiện là đang sử dụng các công nghệ đáng quan tâm
Khung hoặc thư viện
Liên kết đến các trang web di động
Liên kết đến các trang web thông thường
jQuery
4615474
3714643
Phản ứng
489827
241023
quang cảnh
85649
43691
có góc cạnh
19423
18088
Những hi vọng và ước mơ
Trước khi chúng tôi chuyển sang phân tích dữ liệu, tôi muốn nói về những gì tôi muốn hy vọng.
Tôi tin rằng trong một thế giới lý tưởng, các khuôn khổ sẽ vượt ra ngoài việc đáp ứng nhu cầu của các nhà phát triển và cung cấp một số lợi ích cụ thể cho người dùng bình thường làm việc với các trang web của chúng tôi. Hiệu suất chỉ là một trong những lợi ích đó. Đây là nơi khả năng truy cập và bảo mật phát huy tác dụng. Nhưng đây chỉ là điều quan trọng nhất.
Vì vậy, trong một thế giới lý tưởng, một số loại khuôn khổ sẽ giúp dễ dàng tạo một trang web hiệu suất cao. Điều này nên được thực hiện do thực tế là khuôn khổ cung cấp cho nhà phát triển một cơ sở tốt để xây dựng một dự án hoặc do thực tế là nó áp đặt các hạn chế đối với sự phát triển, đưa ra các yêu cầu đối với nó làm phức tạp quá trình phát triển của một thứ gì đó. ra là chậm.
Các khuôn khổ tốt nhất nên làm cả hai: đưa ra một cơ sở tốt và áp đặt các hạn chế đối với công việc, cho phép bạn đạt được kết quả tốt.
Phân tích các giá trị trung bình của dữ liệu sẽ không cung cấp cho chúng tôi thông tin chúng tôi cần. Và, trên thực tế, cách tiếp cận này khiến chúng ta không chú ý . Thay vào đó, tôi lấy tỷ lệ phần trăm từ dữ liệu tôi có. Đây là 10, 25, 50 (trung vị), 75, 90 phần trăm.
Tôi đặc biệt quan tâm đến phần trăm thứ 10 và 90. Phần trăm thứ 10 đại diện cho hiệu suất tốt nhất (hoặc ít nhất gần bằng tốt nhất) cho một khung cụ thể. Nói cách khác, điều này có nghĩa là chỉ 10% trang web sử dụng một khung cụ thể đạt được cấp độ này hoặc cao hơn. Mặt khác, phân vị thứ 90 là mặt trái của đồng tiền - nó cho chúng ta thấy mọi thứ có thể trở nên tồi tệ như thế nào. Phần trăm thứ 90 là các trang web xếp sau—10% dưới cùng của các trang web có nhiều mã JS nhất hoặc thời gian xử lý mã của họ trên luồng chính lâu nhất.
Khối lượng mã JavaScript
Để bắt đầu, bạn nên phân tích kích thước của mã JavaScript được truyền bởi các trang web khác nhau qua mạng.
Lượng mã JavaScript (Kb) được chuyển đến thiết bị di động
phần trăm
10
25
50
75
90
Tất cả các trang web
93.4
196.6
413.5
746.8
1201.6
các trang jQuery
110.3
219.8
430.4
748.6
1162.3
trang Vue
244.7
409.3
692.1
1065.5
1570.7
các trang web góc
445.1
675.6
1066.4
1761.5
2893.2
Trang web phản ứng
345.8
441.6
690.3
1238.5
1893.6
Lượng mã JavaScript được gửi đến thiết bị di động
Lượng mã JavaScript (Kb) được chuyển sang thiết bị máy tính để bàn
phần trăm
10
25
50
75
90
Tất cả các trang web
105.5
226.6
450.4
808.8
1267.3
các trang jQuery
121.7
242.2
458.3
803.4
1235.3
trang Vue
248.0
420.1
718.0
1122.5
1643.1
các trang web góc
468.8
716.9
1144.2
1930.0
3283.1
Trang web phản ứng
308.6
469.0
841.9
1472.2
2197.8
Lượng mã JavaScript được gửi đến thiết bị máy tính để bàn
Nếu chúng ta chỉ nói về kích thước của mã JS mà các trang web gửi đến thiết bị, thì mọi thứ sẽ diễn ra như bạn mong đợi. Cụ thể, nếu một trong các khung được sử dụng, điều này có nghĩa là ngay cả trong một tình huống lý tưởng, khối lượng mã JavaScript của trang web sẽ tăng lên. Điều này không có gì đáng ngạc nhiên - bạn không thể biến một khung JavaScript thành cơ sở của một trang web và hy vọng rằng khối lượng mã JS của dự án sẽ rất thấp.
Điều đáng chú ý về dữ liệu này là một số khung và thư viện có thể được coi là điểm khởi đầu tốt hơn cho một dự án so với các khung và thư viện khác. Các trang web có jQuery trông đẹp nhất. Trên các phiên bản trang web dành cho máy tính để bàn, chúng chứa nhiều JavaScript hơn 15% so với tất cả các trang web và trên thiết bị di động, chúng chứa nhiều hơn 18%. (Phải thừa nhận rằng có một số lỗi dữ liệu ở đây. Thực tế là jQuery có mặt trên nhiều trang web, do đó, điều tự nhiên là các trang web đó có liên quan chặt chẽ hơn so với các trang web khác về tổng số trang web. Tuy nhiên, điều này không ảnh hưởng đến mức độ thô dữ liệu là đầu ra cho mỗi khung.)
Mặc dù khối lượng mã tăng 15-18% là một con số đáng chú ý, so sánh điều này với các khung và thư viện khác, người ta có thể kết luận rằng "thuế" do jQuery đánh là rất thấp. Các trang web góc trong phần trăm thứ 10 gửi nhiều dữ liệu hơn 344% tới máy tính để bàn so với tất cả các trang web và nhiều hơn 377% cho thiết bị di động. Các trang web phản ứng là nặng nhất tiếp theo, gửi nhiều mã hơn 193% tới máy tính để bàn so với tất cả các trang web và hơn 270% cho thiết bị di động.
Trước đó, tôi đã đề cập rằng mặc dù sử dụng một khung có nghĩa là một lượng mã nhất định sẽ được đưa vào dự án, nhưng khi bắt đầu làm việc với nó, tôi hy vọng rằng khung đó có thể hạn chế nhà phát triển bằng cách nào đó. Đặc biệt, chúng ta đang nói về việc giới hạn số lượng mã tối đa.
Thật thú vị, các trang web jQuery làm theo ý tưởng này. Mặc dù chúng nặng hơn một chút so với tất cả các trang web ở phân vị thứ 10 (15-18%), nhưng chúng nhẹ hơn một chút ở phân vị thứ 90, khoảng 3% trên cả máy tính để bàn và thiết bị di động. Điều này không có nghĩa là đây là một lợi ích rất đáng kể, nhưng có thể nói rằng ít nhất các trang web jQuery không có kích thước mã JavaScript quá lớn, ngay cả trong các phiên bản lớn nhất của chúng.
Nhưng điều tương tự không thể nói về các khuôn khổ khác.
Cũng giống như trường hợp của phân vị thứ 10, tại các trang web phân vị thứ 90 trên Angular và React khác với các trang web khác, nhưng thật không may, chúng lại khác theo chiều hướng xấu hơn.
Ở phần trăm thứ 90, các trang web Angular gửi nhiều dữ liệu hơn 141% đến thiết bị di động so với tất cả các trang web và nhiều hơn 159% cho máy tính để bàn. Các trang web React gửi nhiều hơn 73% cho máy tính để bàn so với tất cả các trang web và nhiều hơn 58% cho thiết bị di động. Kích thước mã của các trang React ở phân vị thứ 90 là 2197.8 KB. Điều này có nghĩa là các trang web đó gửi nhiều hơn 322.9 KB dữ liệu tới thiết bị di động so với các đối thủ cạnh tranh gần nhất dựa trên Vue. Khoảng cách giữa các trang web dành cho máy tính để bàn dựa trên Angular và React và các trang web khác thậm chí còn lớn hơn. Ví dụ: các trang web React dành cho máy tính để bàn gửi mã JS nhiều hơn 554.7 KB tới các thiết bị so với các trang web Vue tương đương.
Thời gian xử lý mã JavaScript trong luồng chính
Dữ liệu trên chỉ ra rõ ràng rằng các trang web sử dụng khung và thư viện đang được nghiên cứu chứa một lượng lớn mã JavaScript. Nhưng tất nhiên, đó chỉ là một phần trong phương trình của chúng tôi.
Sau khi mã JavaScript đã đến trình duyệt, nó cần được đưa vào trạng thái khả thi. Đặc biệt nhiều vấn đề là do những hành động đó phải được thực hiện bằng mã trong chuỗi trình duyệt chính. Chuỗi chính chịu trách nhiệm xử lý các hành động của người dùng, tính toán các kiểu, xây dựng và hiển thị bố cục trang. Nếu bạn áp đảo luồng chính bằng các tác vụ JavaScript, nó sẽ không có cơ hội hoàn thành các tác vụ còn lại kịp thời. Điều này dẫn đến sự chậm trễ và "phanh" trong công việc của các trang.
Cơ sở dữ liệu Lưu trữ HTTP có thông tin về thời gian xử lý mã JavaScript trong luồng chính của công cụ V8. Điều này có nghĩa là chúng tôi có thể thu thập dữ liệu này và tìm hiểu xem luồng chính cần bao nhiêu thời gian để xử lý JavaScript của các trang web khác nhau.
Thời gian của bộ xử lý (tính bằng mili giây) liên quan đến xử lý tập lệnh trên thiết bị di động
phần trăm
10
25
50
75
90
Tất cả các trang web
356.4
959.7
2372.1
5367.3
10485.8
các trang jQuery
575.3
1147.4
2555.9
5511.0
10349.4
trang Vue
1130.0
2087.9
4100.4
7676.1
12849.4
các trang web góc
1471.3
2380.1
4118.6
7450.8
13296.4
Trang web phản ứng
2700.1
5090.3
9287.6
14509.6
20813.3
Thời gian xử lý liên quan đến xử lý tập lệnh trên thiết bị di động
Thời gian của bộ xử lý (tính bằng mili giây) liên quan đến xử lý tập lệnh trên thiết bị máy tính để bàn
phần trăm
10
25
50
75
90
Tất cả các trang web
146.0
351.8
831.0
1739.8
3236.8
các trang jQuery
199.6
399.2
877.5
1779.9
3215.5
trang Vue
350.4
650.8
1280.7
2388.5
4010.8
các trang web góc
482.2
777.9
1365.5
2400.6
4171.8
Trang web phản ứng
508.0
1045.6
2121.1
4235.1
7444.3
Thời gian xử lý liên quan đến xử lý tập lệnh trên thiết bị máy tính để bàn
Ở đây bạn có thể thấy một cái gì đó rất quen thuộc.
Đối với những người mới bắt đầu, các trang web sử dụng jQuery chi tiêu ít hơn đáng kể cho việc xử lý JavaScript trên luồng chính so với các trang web khác. Ở phân vị thứ 10, so với tất cả các trang web, các trang web jQuery trên thiết bị di động dành nhiều thời gian hơn 61% để xử lý mã JS trên luồng chính. Trong trường hợp các trang web jQuery trên máy tính để bàn, thời gian xử lý tăng 37%. Ở phân vị thứ 90, các trang web jQuery đạt điểm rất gần với điểm tổng hợp. Cụ thể, các trang web jQuery trên thiết bị di động dành ít thời gian hơn 1.3% cho luồng chính so với tất cả các trang web và ít hơn 0.7% thời gian trên thiết bị máy tính để bàn.
Mặt khác trong xếp hạng của chúng tôi là các khung được đặc trưng bởi tải cao nhất trên luồng chính. Một lần nữa, đây là Angular và React. Sự khác biệt duy nhất giữa hai trang này là trong khi các trang Angular gửi nhiều mã tới trình duyệt hơn các trang React, thì các trang Angular chiếm ít thời gian CPU hơn để xử lý mã. Ít hơn nhiều.
Ở phân vị thứ 10, các trang web Angular dành cho máy tính để bàn dành nhiều thời gian hơn 230% cho mã JS xử lý luồng chính so với tất cả các trang web. Đối với các trang web dành cho thiết bị di động, con số này là 313%. Các trang web phản ứng là những trang hoạt động kém nhất. Trên máy tính để bàn, họ dành nhiều thời gian hơn 248% để xử lý mã so với tất cả các trang web và hơn 658% trên thiết bị di động. 658% không phải là một lỗi đánh máy. Ở phân vị thứ 10, các trang web React dành 2.7 giây thời gian xử lý mã của luồng chính.
Phần trăm thứ 90, khi so sánh với những con số khổng lồ này, ít nhất có vẻ tốt hơn một chút. So với tất cả các trang web, các dự án Angular dành nhiều thời gian hơn 29% cho thiết bị máy tính để bàn trong luồng chính và thêm 27% thời gian cho thiết bị di động. Trong trường hợp của các trang web React, các con số tương tự tương ứng là 130% và 98%.
Độ lệch phần trăm cho phần trăm thứ 90 trông đẹp hơn so với các giá trị tương tự cho phần trăm thứ 10. Nhưng ở đây, điều đáng ghi nhớ là những con số chỉ thời gian có vẻ khá đáng sợ. Giả sử 20.8 giây trên chuỗi di động chính cho một trang web được xây dựng bằng React. (Tôi nghĩ câu chuyện về những gì thực sự xảy ra trong thời gian này xứng đáng có một bài viết riêng).
Có một biến chứng tiềm ẩn ở đây (cảm ơn để thu hút sự chú ý của tôi đến tính năng này và để xem xét cẩn thận dữ liệu từ quan điểm này). Thực tế là nhiều trang web sử dụng một số công cụ giao diện người dùng. Đặc biệt, tôi đã thấy rất nhiều trang web sử dụng jQuery cùng với React hoặc Vue, vì những trang web đó đang chuyển từ jQuery sang các khung hoặc thư viện khác. Do đó, tôi nhấn vào cơ sở dữ liệu một lần nữa, lần này chỉ chọn những liên kết tương ứng với các trang web chỉ sử dụng React, jQuery, Angular hoặc Vue chứ không phải bất kỳ sự kết hợp nào của chúng. Đây là những gì tôi có.
Thời gian của bộ xử lý (tính bằng mili giây) liên quan đến việc xử lý tập lệnh trên thiết bị di động trong trường hợp các trang web chỉ sử dụng một khung hoặc chỉ một thư viện
phần trăm
10
25
50
75
90
Các trang web chỉ sử dụng jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Các trang web chỉ sử dụng Vue
944.0
1716.3
3194.7
5959.6
9843.8
Các trang web chỉ sử dụng Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Các trang web chỉ sử dụng React
2443.2
4620.5
10061.4
17074.3
24956.3
Thời gian của bộ xử lý liên quan đến việc xử lý tập lệnh trên thiết bị di động trong trường hợp các trang web chỉ sử dụng một khung hoặc chỉ một thư viện
Đầu tiên, một điều không có gì đáng ngạc nhiên: khi một trang web chỉ sử dụng một khung hoặc một thư viện, thì hiệu suất của trang web đó thường xuyên được cải thiện hơn là không. Mỗi công cụ hoạt động tốt hơn ở phân vị thứ 10 và 25. Nó có ý nghĩa. Trang web được tạo bằng một khung sẽ hoạt động tốt hơn trang web được tạo bằng hai hoặc nhiều khung hoặc thư viện.
Trên thực tế, hiệu suất của từng công cụ giao diện người dùng được nghiên cứu có vẻ tốt hơn trong mọi trường hợp, ngoại trừ một ngoại lệ gây tò mò. Điều làm tôi ngạc nhiên là ở phần trăm thứ 50 trở lên, các trang web sử dụng React hoạt động kém hơn khi React là thư viện duy nhất họ sử dụng. Nhân tiện, đây là lý do tôi trình bày dữ liệu này ở đây.
Điều này hơi kỳ lạ, nhưng tôi vẫn sẽ cố gắng tìm lời giải thích cho sự kỳ lạ này.
Nếu một dự án sử dụng cả React và jQuery, thì dự án đó có thể đang ở đâu đó trong quá trình chuyển đổi từ jQuery sang React. Có lẽ nó có một cơ sở mã nơi các thư viện này được trộn lẫn. Vì chúng ta đã thấy rằng các trang web jQuery dành ít thời gian hơn cho luồng chính so với các trang web React, nên điều này có thể cho chúng ta biết rằng việc triển khai một số chức năng trong jQuery giúp trang web hoạt động tốt hơn một chút.
Nhưng khi dự án chuyển từ jQuery sang React và dựa nhiều hơn vào React, mọi thứ đang thay đổi. Nếu trang web thực sự có chất lượng cao và các nhà phát triển trang web sử dụng React cẩn thận, thì mọi thứ sẽ ổn với một trang web như vậy. Nhưng đối với trang web React trung bình, việc sử dụng rộng rãi React có nghĩa là luồng chính đang chịu tải nặng.
Khoảng cách giữa thiết bị di động và máy tính để bàn
Một quan điểm khác mà tôi đã xem xét dữ liệu đã nghiên cứu là nghiên cứu xem khoảng cách lớn như thế nào giữa việc làm việc với các trang web trên thiết bị di động và máy tính để bàn. Nếu chúng ta nói về việc so sánh khối lượng mã JavaScript, thì việc so sánh như vậy không tiết lộ điều gì khủng khiếp. Tất nhiên, sẽ rất tuyệt nếu thấy số lượng mã có thể tải xuống nhỏ hơn, nhưng không có nhiều khác biệt về số lượng mã dành cho thiết bị di động và máy tính để bàn.
Nhưng nếu chúng ta phân tích thời gian cần thiết để xử lý mã, thì sẽ thấy rõ khoảng cách rất lớn giữa thiết bị di động và máy tính để bàn.
Tăng thời gian (phần trăm) liên quan đến xử lý tập lệnh trên thiết bị di động so với máy tính để bàn
phần trăm
10
25
50
75
90
Tất cả các trang web
144.1
172.8
185.5
208.5
224.0
các trang jQuery
188.2
187.4
191.3
209.6
221.9
trang Vue
222.5
220.8
220.2
221.4
220.4
các trang web góc
205.1
206.0
201.6
210.4
218.7
Trang web phản ứng
431.5
386.8
337.9
242.6
179.6
Mặc dù dự kiến sẽ có một số khác biệt về tốc độ xử lý mã giữa điện thoại và máy tính xách tay, nhưng những con số lớn như vậy cho tôi biết rằng các khung hiện đại không được nhắm mục tiêu đầy đủ vào các thiết bị có công suất thấp và chúng đang cố gắng thu hẹp khoảng cách mà chúng đã phát hiện ra. Ngay cả ở phần trăm thứ 10, các trang web React dành nhiều thời gian hơn 431.5% cho luồng chính trên thiết bị di động so với luồng chính trên máy tính để bàn. jQuery có khoảng cách nhỏ nhất, nhưng ngay cả ở đây, con số tương ứng là 188.2%. Khi các nhà phát triển trang web thực hiện các dự án của họ theo cách mà quá trình xử lý của họ đòi hỏi nhiều thời gian hơn của bộ xử lý (và điều đó xảy ra và nó chỉ trở nên tồi tệ hơn theo thời gian), chủ sở hữu của các thiết bị có công suất thấp phải trả tiền cho việc đó.
Kết quả
Các khung tốt sẽ cung cấp cho nhà phát triển nền tảng tốt để xây dựng các dự án web (về bảo mật, khả năng truy cập, hiệu suất) hoặc chúng nên có các hạn chế tích hợp khiến khó xây dựng thứ gì đó vi phạm các hạn chế đó.
Điều này dường như không áp dụng cho hiệu suất của các dự án web (và có lẽ không áp dụng cho ).
Điều đáng chú ý là chỉ vì các trang web React hoặc Angular dành nhiều thời gian CPU hơn để chuẩn bị mã hơn các trang web khác không nhất thiết có nghĩa là các trang web React sử dụng nhiều CPU hơn các trang web Vue khi chạy. Trên thực tế, dữ liệu chúng tôi đã xem xét nói rất ít về hiệu suất hoạt động của các khung và thư viện. Họ nói nhiều hơn về các cách tiếp cận phát triển mà, dù có ý thức hay không, những khuôn khổ này có thể thúc đẩy các lập trình viên. Chúng ta đang nói về tài liệu cho các framework, về hệ sinh thái của chúng, về các kỹ thuật phát triển chung.
Cũng cần đề cập đến một điều mà chúng tôi không phân tích ở đây, cụ thể là thiết bị dành bao nhiêu thời gian để thực thi mã JavaScript khi điều hướng giữa các trang của trang web. Lập luận có lợi cho SPA là một khi ứng dụng trang đơn được tải vào trình duyệt, về mặt lý thuyết, người dùng sẽ có thể mở các trang của trang web nhanh hơn. Kinh nghiệm của riêng tôi cho tôi biết rằng điều này là xa sự thật. Nhưng chúng tôi không có dữ liệu để làm rõ vấn đề này.
Điều rõ ràng là nếu bạn đang sử dụng một khung hoặc thư viện để tạo một trang web, thì bạn đang thỏa hiệp về việc tải dự án ban đầu và chuẩn bị sẵn sàng cho nó. Điều này áp dụng ngay cả với các kịch bản tích cực nhất.
Hoàn toàn có thể thực hiện một số thỏa hiệp trong những tình huống thích hợp, nhưng điều quan trọng là các nhà phát triển phải thực hiện những thỏa hiệp đó một cách có ý thức.
Nhưng chúng ta cũng có lý do để lạc quan. Tôi rất vui khi thấy các nhà phát triển Chrome đang làm việc chặt chẽ như thế nào với các nhà phát triển của một số công cụ giao diện người dùng mà chúng tôi đã xem xét nhằm nỗ lực giúp cải thiện hiệu suất của những công cụ đó.
Tuy nhiên, tôi là một người thực dụng. Các kiến trúc mới thường xuyên tạo ra các vấn đề về hiệu suất khi chúng giải quyết chúng. Và phải mất thời gian để sửa lỗi. Cũng như chúng ta không nên mong đợi sẽ giải quyết tất cả các vấn đề về hiệu suất, bạn không nên mong đợi điều này từ các phiên bản mới của các khung yêu thích của chúng tôi.
Nếu bạn muốn sử dụng một trong những công cụ giao diện người dùng được thảo luận trong bài viết này, điều này có nghĩa là bạn sẽ phải nỗ lực nhiều hơn để không làm tổn hại đến hiệu suất của dự án trong thời gian chờ đợi. Dưới đây là một số cân nhắc để xem xét trước khi bắt đầu một khuôn khổ mới:
- Kiểm tra bản thân với ý thức chung. Bạn có thực sự cần sử dụng khung đã chọn không? JavaScript thuần túy ngày nay có khả năng rất nhiều.
- Có giải pháp thay thế nhẹ hơn cho khung đã chọn (như Preact, Svelte hoặc thứ gì khác) có thể cung cấp cho bạn 90% khả năng của khung này không?
- Nếu bạn đang sử dụng một framework, hãy cân nhắc xem có thứ gì đó cung cấp các tùy chọn tiêu chuẩn tốt hơn, thận trọng hơn không (ví dụ: Nuxt.js thay vì Vue, Next.js thay vì React, v.v.).
- bạn sẽ làm gì Hiệu suất JavaScript?
- Làm thế nào có thể bạn một quy trình phát triển để làm cho việc đưa thêm mã JavaScript vào một dự án trở nên khó khăn hơn mức cần thiết?
- Nếu bạn đang sử dụng một khung để dễ phát triển, hãy xem xét gửi mã khung cho khách hàng. Có lẽ bạn có thể giải quyết tất cả các vấn đề trên máy chủ?
Thông thường những ý tưởng này đáng để xem xét, bất kể bạn đã chọn chính xác những gì để phát triển giao diện người dùng. Nhưng chúng đặc biệt quan trọng khi bạn đang thực hiện một dự án thiếu hiệu suất ngay từ đầu.
Gởi bạn đọc! Bạn thấy khung JavaScript lý tưởng như thế nào?
Nguồn: www.habr.com