2009-07-28 20 views
10

Có khuôn khổ JavaScript khác nhau như jQuery, Dojo, MooTools, Google Web Toolkit (GWT), YUI vv Mà một trong những từ này là phù hợp cho các trang web hiệu suất cao?Khung JavaScript nào thường được sử dụng cho các trang web hiệu suất cao?

+0

Tùy thuộc vào những gì bạn đang làm với khung công tác. –

+0

GWT không phải là một khung javascript, đó là một khung công tác Java –

+3

GWT là khung javascript được viết bằng JAVA – Manthan

Trả lời

14

(Tuyên bố từ chối trách nhiệm đầy đủ: Tôi là nhà phát triển Dojo và đây là quan điểm không chính thức của tôi).

Tất cả các thư viện chính có thể được sử dụng trong các trường hợp tải cao. Có một số điều cần xem xét:

tải ban đầu

Các tải ban đầu ảnh hưởng đến thời gian phản hồi của bạn: từ yêu cầu một trang web để được đáp ứng và trong chế độ làm việc. những điều tầm thường để làm là:

  • nối tập tin nhiều JavaScript cùng (chỉ hoạt động cho các tập tin CSS quá)
  • giảm thiểu và/hoặc nén JavaScript

Ý tưởng là để gửi ít — tốt cho máy chủ và tốt cho khách hàng.

Điều ít tầm thường để làm:

  • cấu trúc chương trình của bạn theo cách như vậy nên nó là hoạt động mà không cần tất cả các module nạp

Ví dụ về thứ hai: phân chia module của bạn vào thiết yếu (ví dụ , logic cốt lõi) và không cần thiết (ví dụ: người trợ giúp: chú giải công cụ, gợi ý, người xác minh, cơ sở trợ giúp, nhiều "chất tăng cường dần dần" khác nhau, v.v.). Ý tưởng là thường xuyên có những thứ không quan trọng đối với người dùng thường xuyên, nhưng tốt cho những người dùng bình thường ⇒ họ có thể bị trì hoãn.

Chúng tôi có thể nạp các mô-đun cần thiết trước và tải phần còn lại một cách không đồng bộ. Ví dụ: nếu người dùng muốn chỉnh sửa đối tượng, chúng tôi cần hiển thị nó trước tiên, sau đó chúng tôi có vài trăm mili giây để tải phần còn lại: tra cứu bảng, gợi ý, v.v.

Rõ ràng nó giúp khi tải mô-đun không đồng bộ được khung được bạn hỗ trợ sử dụng. Dojo có sẵn thiết bị này.

Distribute file

Mọi người đều biết rằng do hạn chế trình duyệt trên số lượng tải song song từ cùng một trang web nó có lợi tải các tài nguyên (hình ảnh, CSS, Javascript) từ các miền khác nhau:

  • chúng tôi có thể tải xuống nhiều hơn song song, nếu đường dây của người dùng có đủ băng thông — những ngày này hầu như luôn đúng
  • chúng tôi có thể thiết lập máy chủ web được tối ưu hóa để phân phát tệp tĩnh: orkers, giữ-sống, async phục vụ, và vân vân
  • chúng ta có thể loại bỏ tất cả các tính năng không cần thiết chúng ta không cần khi phục vụ các tập tin tĩnh: phiên, cookies, và vân vân

Một thường bị bỏ qua tối ưu hóa trong JavaScript ứng dụng là sử dụng CDN:

  • trang web của bạn có thể được hưởng lợi từ sự phân bố địa lý của CDN (tập tin có thể được phục vụ từ máy chủ gần nhất/nhanh nhất)
  • dùng có thể đã yêu cầu tập tin trong bộ nhớ cache của cô, nếu họ được sử dụng bởi ứng dụng khác
  • cache trung gian/doanh nghiệp tăng khả năng đòi hỏi các file đã được lưu trữ
  • cuối cùng nhưng không kém phần quan: đây là những tập tin mà bạn không phục vụ — suy nghĩ về nó

Một lần nữa, Dojo hỗ trợ CDN cho một thời gian dài và được phân phối công khai bởi AOL CDNGoogle CDN. Sau này mang thực tế tất cả các bộ công cụ JavaScript phổ biến quá. Rõ ràng bạn có thể tạo CDN của riêng bạn và CDN- và ứng dụng Dojo riêng cho từng ứng dụng của bạn, nếu bạn cảm thấy bạn cần nó — nó là tầm thường và được ghi lại đầy đủ.

Truyền thông băng thông

Làm thế nào mà có thể khác nhau cho các bộ công cụ khác nhau? XHR là XHR.

Bạn cần phải giảm tải trên máy chủ của mình càng nhiều càng tốt. Phân tích tất cả lưu lượng truy cập và xem xét số lượng nội dung tĩnh/không thay đổi được gửi qua đường ống. Ví dụ, thông thường rất nhiều HTML là dư thừa trên nhiều trang: đầu trang, chân trang, menu, v.v. Bạn có thực sự cần tất cả những điều này để được gửi qua mọi thời gian?

Một giải pháp hiển nhiên là chuyển từ HTML tĩnh + "cải tiến dần dần" bằng JavaScript thành các ứng dụng JavaScript "một trang" thực. Một lần nữa, đây là một thường xuyên bị bỏ qua, nhưng tối ưu hóa bổ ích nhất.

Trong khi ý tưởng nghe có vẻ dễ dàng, trong thực tế nó không đơn giản như nó có vẻ. Ngay khi chúng ta đi từ một lớp lót đến ứng dụng, chúng ta có rất nhiều câu hỏi, và lớn nhất trong số đó là bao bì: thành phần của bạn là gì, thành phần nào được cung cấp bởi bộ công cụ và cách đóng gói và phân phối chúng.

Dojo cung cấp mô-đun, OOP tốt cho các lớp học chung, tiện ích (kết hợp HTML tùy chọn và hành vi có liên quan) và rất nhiều cơ sở để làm việc với chúng.Bạn có thể:

  • tải module theo yêu cầu chứ không phải là vào đầu
  • tải module không đồng bộ
  • tất cả phụ thuộc giữa các module tự động và tạo ra một "xây dựng" — một tập tin trong trường hợp đơn giản, hoặc nhiều hơn, nếu ứng dụng của bạn lớn và yêu cầu nhiều lớp
  • trong khi thực hiện "xây dựng" nó có thể nội tuyến tất cả các đoạn mã HTML cho tiện ích của bạn, tối ưu hóa CSS và rút gọn/nén JavaScript
  • Dojo có thể tự động tìm và khởi tạo các tiện ích trong lưu HTML của boilerplate đang
  • và nhiều hơn thế nữa

Tất cả các tính năng này giúp rất nhiều khi xây dựng các ứng dụng trên các mặt hàng. That's why I like Dojo.

Rõ ràng có nhiều cách để tối ưu hóa các trang web tải cao nhưng theo thực tế của tôi, đây là những cách cụ thể nhất cho khung JavaScript.

0

Vâng - như là một ví dụ stackoverflow dựa trên jQuery (và sử dụng liên kết google apis) - nó là một trong những thư viện nhanh nhất và phổ biến nhất và không chỉ vậy, nhưng tôi muốn nói đó là dễ sử dụng nhất. Bạn sẽ có loại hành vi nào trên trang web? Nó thực sự tất cả phụ thuộc vào nhu cầu của bạn.

11

Rất đơn giản: tất cả trong số họ.

Tất cả các khuôn khổ đã được xây dựng để cung cấp hiệu suất nhanh nhất có thể và cung cấp các nhà phát triển với chức năng và công cụ hữu ích. sự lựa chọn của bạn nên được dựa trên yêu cầu của bạn.

JavaScript chạy ở phía máy khách, vì vậy sẽ không có ảnh hưởng nào đến hiệu suất máy chủ của bạn. Sự khác biệt duy nhất giữa phía máy chủ là lượng băng thông được sử dụng để chuyển các tệp .js cho ứng dụng khách.

Cá nhân tôi thích MooTools vì nó trả lời các yêu cầu của tôi và cũng dính vào các lý tưởng mã hóa của tôi. Rất nhiều người thông qua jQuery (Cá nhân tôi không thích nó, không có nghĩa là nó không phải là rất lớn). Tôi đã không sử dụng những cái khác.

Nhưng không cái nào tốt hơn cái kia, đó là tất cả câu hỏi về yêu cầu và sở thích cá nhân.

+1

+1 bạn đánh bại tôi với nó. phần thông tin quan trọng mà câu hỏi bị thiếu là ý nghĩa của hiệu suất cao. thời gian tải ban đầu nhanh? màu sắc đẹp? khả năng hiển thị phim trực tuyến ở kích thước pixel 10000x10000? trong hầu hết các trường hợp (ngoại trừ thời gian tải ban đầu) nút cổ chai sẽ là máy chủ hoặc băng thông không phải là máy khách. –

+0

Không phải tất cả các khung công tác đều giống nhau về tốc độ. Một số vốn đã chậm hơn so với một số khác do sự khác biệt về kiến ​​trúc. Taskspeed, trong khi là một chút nhân tạo và không nhất quán, chứng minh những khác biệt rõ ràng. – kangax

0

Câu trả lời, như mọi khi, là: nó phụ thuộc. Bạn đang nói về loại hiệu suất nào? Tốc độ tải về? Sử dụng một minimiser và có lẽ không có nhiều sự khác biệt. Hoặc hiệu suất phía máy khách, và bạn đang làm gì với nó? Tuy nhiên, tôi sẽ đề nghị rằng nếu bạn sau khi thực hiện thô, tôi sẽ không sử dụng một khuôn khổ ở tất cả, và tạo javascript cấp thấp sẽ khó khăn hơn rất nhiều để duy trì.

Một số thông tin tốt có thể được tìm thấy trên YUI site.

1

Tôi không thực sự nghĩ rằng nó tạo ra một chút khác biệt. Những người lớn dường như sử dụng một hỗn hợp của nguyên mẫu Jquery & cùng với những người khác.

Khá thẳng thắn, nó không tạo ra sự khác biệt gì bạn sử dụng cho các trang web được truy cập nhiều như chúng ta đang nói về công nghệ của khách hàng. Sau khi tệp được tải, không thực sự có bất kỳ chi phí nào. Vì vậy, nếu bạn chỉ muốn làm một điều đơn giản và nhiều khung công tác hỗ trợ nó, hãy sử dụng bất kỳ thứ gì có kích thước tệp nhỏ hơn (tất nhiên, nếu nó hoạt động kém, hãy sử dụng một tệp khác!)

Điều này đang được nói, google lưu trữ nhiều khung công tác, vì vậy ngay cả điều này thực sự là một vấn đề không phải. Tôi sử dụng Jquery được Google lưu trữ và tôi rất hạnh phúc.

http://code.google.com/apis/ajaxlibs/

Backend và những gì các máy chủ nên sử dụng là một câu hỏi hoàn toàn khác nhau, nơi bạn sẽ nhận được một ngàn câu trả lời khác nhau!

0

Như các câu trả lời khác đã được giải thích, khuôn khổ sẽ không phải là nút cổ chai trong hiệu suất trang web của bạn - thay vào đó, nhiều yếu tố khác.Nếu bạn sử dụng các khung phổ biến và tải chúng từ các URL phổ biến cho chúng (ví dụ: AOL hoặc Google), chúng có thể được lưu trong bộ nhớ cache trong trình duyệt của người dùng, do đó bạn cũng không phải lo lắng nhiều về điều đó.

Nếu bạn quan tâm đến hiệu suất, hãy hoàn toàn kiểm tra công việc Steve Souders; - bao gồm cả sách, "Trang web hiệu suất cao" và "Thậm chí trang web nhanh hơn".

Tôi thiên vị, vì Steve là bạn bè và đồng nghiệp (và chúng tôi cũng chia sẻ với nhà xuất bản), nhưng tôi đã khen ngợi và ngưỡng mộ tác phẩm của mình ngay cả trước khi chúng tôi gặp trực tiếp và trở thành đồng nghiệp - Tôi chủ yếu một người back-end, như ông đã từng, vì vậy tôi không thể không ngưỡng mộ ai đó, đến từ cùng một nền tảng, có tính toàn vẹn và can đảm để chuyển đổi gần như hoàn toàn tập trung vào front-end khi ông nhận ra rằng đến nay nút cổ chai cho hiệu suất người dùng nhận thức (nghĩa là ai đó có ý định đưa trải nghiệm người dùng trước tiên, điều mà tất cả chúng ta đều kính trọng, tất nhiên, nhưng không luôn thực hành, khi đó "ưu tiên ghi đè" cách chuyên môn, sở thích và kỹ năng chuyên môn của chúng tôi ...).

1

Tôi khuyên bạn nên xem xét Dojo.

Dojo 1.6 cũng là Thư viện JavaScript phổ biến đầu tiên (và duy nhất) có thể được sử dụng thành công với chế độ Nâng cao của Trình biên dịch Đóng gói, với các lợi ích lớn, hiệu suất và sự can thiệp gắn liền với nó - ngoài Thư viện Đóng riêng của Google, đó là.

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

Nói cách khác, một chương trình sử dụng Dojo thể chắc chắn 100% obfuscated - ngay cả những thư viện riêng của mình.

Mã đã biên dịch có cùng hành vi giống như mã văn bản thuần, ngoại trừ nó nhỏ hơn nhiều (trung bình 25% trên bộ lọc), chạy nhanh hơn nhiều (đặc biệt trên thiết bị di động) và hầu như không thể đảo ngược sau khi đi qua một cái làm đẹp, bởi vì toàn bộ cơ sở mã (kể cả thư viện) bị làm xáo trộn.

Mã chỉ được "rút gọn" (ví dụ: máy nén YUI, Uglify) có thể dễ dàng được thiết kế ngược sau khi đi qua bộ làm đẹp.

Các vấn đề liên quan