Tối ưu hóa yêu cầu javascript và css

Tôi cần tối ưu hóa tốc độ tải của một số trang web hiện có. Một trong những vấn đề mà tôi có là số lượng yêu cầu trên mỗi trang. Các trang web có 7 hoặc nhiều loại trang khác nhau sẽ tải tập hợp css và javascripts khác nhau vì chúng chứa các tiện ích hoặc chức năng khác nhau. Hiện tại, mỗi tiện ích hoặc chức năng đều có tệp javascript riêng. Tôi đang lập kế hoạch để kết hợp và rút gọn các tệp để có ít yêu cầu hơn.Tối ưu hóa yêu cầu javascript và css

Sẽ là một cách hay để kết hợp và rút gọn tất cả các javascripts cần thiết trên mỗi loại trang thành một tệp (và để làm tương tự cho css)? ví dụ.
- trang chủ chỉ có một homepage.js,
- trang danh sách vừa listing.js,
- trang chi tiết chỉ có detail.js,
- , vv
Là nó tốt hơn để kết hợp chỉ các tập tin mà luôn luôn sử dụng cùng nhau? ví dụ.
- jquery.js + jquery.cookie.js + common.js,
- list.js + paging.js + favorite.js,
- detail.js + favorite.js,
- , vv
gì về việc có một tập tin cho tất cả các javascripts rằng nên tải trong đầu và một tệp cho tất cả các tệp javascripts sẽ tải ở cuối phần thân, ví dụ
- init.js chuyển đến <head> và do.js chuyển đến <body>.
Điều gì về việc có một tệp cho các chức năng phổ biến và một cho các chức năng quản trị được tải nếu người dùng có quyền cụ thể?
Có bất kỳ chiến lược nào để cân bằng giữa 1., 2., 3. và 4. không?
Số lượng yêu cầu javascript và css được đề xuất cho một trang là bao nhiêu?

Tôi đang xem xét các trang web có cổng hoặc mạng xã hội có quy mô lớn.

(BTW, có một số thư viện yêu cầu tôi không thể kiểm soát, ví dụ: TinyMCE hoặc bản đồ google).

Nguồn

2010-11-03 Aidas Bendoraitis

Cá nhân, tôi sẽ thử và định lượng sự khác biệt. Hồ sơ theo một cách nào đó. Nếu bạn đã đi trước, trong quá trình quảng bá cho bạn môi trường sống, bạn sẽ phải viết kịch bản hoặc xử lý hàng loạt quá trình rút gọn. – brumScouse

Vì bạn chưa nói gì về nó: Đảm bảo bạn có đúng tiêu đề bộ nhớ cache trên các tệp của mình và bạn gửi các phiên bản tệp nén (nếu khách hàng chấp nhận tệp đó). – some

Thông thường, bạn có thể sử dụng mẫu sau:

main.js - bó tất cả các kịch bản ở đây được sử dụng bởi nhiều trang trên trang web.
page.js - tất cả js cụ thể cho trang. Điều này có nghĩa là đóng gói với nhau js của tất cả các tiện ích trên trang .

Với thực tế này, bạn chỉ cần 2 yêu cầu cho JS của bạn trên mỗi trang và bạn nhận được một tách/cấu trúc rõ ràng trong JS của bạn. Đối với tất cả các trang ngoại trừ trang đầu tiên, nó sẽ chỉ là một yêu cầu là main.js sẽ được lưu vào bộ nhớ cache.

Bạn cũng có thể sử dụng nguyên tắc tương tự cho CSS. Điều này có hiệu quả nhưng như đã đề cập bởi một câu trả lời khác, bạn thực sự có thể thực hiện việc này thêm và gộp mọi thứ chỉ trong 1 giây. Sở thích hoặc phong cách của nó. Tôi thích chia nó thành 2 vì nó giữ mọi thứ hợp lý cho tôi.

Đảm bảo những điều sau đây mặc dù:

Namespace JS của bạn khác mà bạn có thể kết thúc với các lỗi khi bạn bó chúng lại với nhau.
Làm cho các trang của bạn có lợi và đẩy chúng ở cuối trang.

EDIT: Tôi nghĩ tôi sẽ cập nhật câu trả lời cho trả lời một số điểm của bạn.

Điểm 2: Tốt hơn là chỉ kết hợp những tệp luôn được sử dụng cùng nhau?

Trả lời: Cá nhân, tôi không nghĩ vậy. Nếu bạn đang phục vụ tất cả các tệp đang được sử dụng cùng nhau, không quan trọng họ thuộc về nhóm nào hoặc cách họ truy cập trang. Điều này là do chúng tôi kết hợp các tệp JS để giảm số lượng Yêu cầu HTTP.

Khi JS của bạn được kết hợp & được rút gọn & trong PROD, bạn không được mong đợi gỡ lỗi hoặc hiểu ý nghĩa của nó.Vì vậy, để liên kết với nhau các tệp JS liên quan một cách hợp lý là một điểm tranh luận. Trong môi trường DEV của bạn, nơi bạn muốn có tất cả các tệp mã có liên quan logic này với nhau.

Điểm 3: Điều gì về việc có một tệp cho tất cả các tệp javascripts sẽ tải trong đầu và một tệp cho tất cả các tệp javascripts sẽ tải ở cuối phần thân?

Trả lời: Có một số trường hợp nhất định bạn buộc phải tiêm JS vào số HEAD. Lý tưởng nhất, bạn không nên làm điều đó như là SCRIPT thẻ đang chặn trong tự nhiên. Vì vậy, trừ khi bạn thực sự cần, hãy đặt tất cả JS của bạn (1 hoặc nhiều tệp) vào cuối thẻ BODY.

Điểm 4: Điều gì về việc có một tệp cho các chức năng phổ biến và một cho các chức năng quản trị được tải nếu người dùng có quyền cụ thể?

Trả lời: Điều này có vẻ như là một cách tiếp cận hợp lý để chia mã JS của bạn. Tùy thuộc vào đặc quyền của người dùng, bạn có thể chia nhỏ mã JS của mình.

Điểm 6: Số lượng yêu cầu javascript và css được đề xuất cho một trang là bao nhiêu?

Trả lời: Đây là câu hỏi rất chủ quan. Nó phụ thuộc vào những gì bạn đang xây dựng. Nếu bạn đang lo lắng về quá nhiều JS được tải khi tải trang, bạn luôn có thể tách nó và sử dụng theo yêu cầu SCRIPT phương pháp tiêm để chia tải.

Nguồn

2010-11-03 18:07:25 Rajat

Nói chung, tôi nối và rút gọn tất cả các tập lệnh trên trang web và chỉ phân phối hai yêu cầu - một cho JS và một cho CSS. Ngoại lệ cho quy tắc đó là nếu một trang nhất định có một tập lệnh có kích thước đáng kể chỉ chạy ở đó - trong trường hợp đó, nó phải được tải riêng.

Tải tất cả các tập lệnh JS ở cuối trang của bạn để ngăn chặn tập lệnh chặn tải trang.

Nguồn

2010-11-03 17:56:31

Trong trường hợp này, tệp js và css có thể quá lớn và có thể mất quá nhiều thời gian để thực thi thử nghiệm khởi tạo tất cả các tiện ích có sẵn. –

Ý bạn là "có thể" là gì? kiểm tra xem nó có đúng không. Đó là một chiến lược chung, và tất nhiên có những ngoại lệ. –

Như mọi khi: nó phụ thuộc. Các tệp trang cụ thể càng lớn thì càng có ý nghĩa để giữ chúng riêng biệt.Nếu chúng không lớn (hãy suy nghĩ 10 kB minified), nó có thể có ý nghĩa hơn để tham gia, thu nhỏ và nén chúng, vì vậy bạn có thể lưu một số yêu cầu và dựa vào bộ nhớ đệm.

Nguồn

2010-11-03 17:57:14 DanMan

Giảm thiểu và kết hợp JS chỉ là một phần của trận chiến. Vị trí của các tập tin là quan trọng hơn. Javascript obtrustive nên được nạp cuối cùng trên trang vì nó sẽ tạm dừng tải trang cho đến khi nó tải xong.

Hợp nhất những gì bạn có thể nhưng việc đặt tên và sử dụng các bao đóng có thể giúp giữ cho DOM sạch các cuộc gọi chức năng của bạn cho đến khi cần.

Có các công cụ có thể kiểm tra tốc độ tải trang.

Bảng điều khiển Net trong Firebug cũng như Yslow là các công cụ tiện dụng mà bạn có thể sử dụng để giúp gỡ lỗi tốc độ tải trang.

Chúc bạn may mắn và vui vẻ!

Nguồn

2010-11-03 17:57:31 TALLBOY

Giống như một số người khác đã nói, đặt sử dụng-on-hơn-hơn-một trang kịch bản tất cả lại với nhau thành một main.js và sau đó nếu có những trang những cái cụ thể: home.js, another_page.js vv

Điều duy nhất Tôi thực sự muốn thêm là cho các thư viện như jQuery, bạn nên sử dụng một cái gì đó như của Google Libraries API.

Nếu người dùng của bạn đã truy cập một trang web khác cũng sử dụng máy chủ của Google cho thư viện, họ sẽ đến với bộ nhớ cache gốc! Thắng lợi!
Tôi sẽ đi ra ngoài bằng một chi ở đây và đặt cược rằng các máy chủ của Google nhanh hơn máy chủ của bạn.
Bởi vì yêu cầu được đi đến các máy chủ khác nhau, khách hàng có thể đồng thời xử lý hai yêu cầu đến các máy chủ của Google (ví dụ như: jQuery & jQuery UI) cũng như hai yêu cầu đến các máy chủ của bạn (main.js & main.css)

Ồ, và cuối cùng - đừng quên bật gzipping trên máy chủ của bạn!

Nguồn

2010-11-08 16:58:57 nickf

** 1) ** Cơ hội người dùng có chính xác cùng một thư viện với chính xác cùng một phiên bản từ chính xác cùng một CDN trong bộ nhớ cache của mình (và không được thay thế bởi nội dung khác từ đó) không cao lắm. + giới hạn bộ nhớ cache là nhỏ ** 2) ** Tên miền mới có nghĩa là tra cứu DNS mới chậm ** 3) ** Trình duyệt là môi trường luồng đơn có nghĩa là nó chỉ có thể xử lý một tập lệnh tại một thời điểm. Nếu bạn có nghĩa là tải xuống là song song, sau đó bạn sai, theo nghĩa là nó không phụ thuộc vào nếu họ đang ở trên miền khác nhau hoặc cùng. Chỉ phụ thuộc vào hỗ trợ trình duyệt để tải xuống tập lệnh song song. – galambalazs

@galam 1) Càng nhiều nhà phát triển sử dụng các CDN này, hiệu suất tốt hơn chúng ta sẽ thấy. 2) Tôi sẽ đi ra ngoài một chi và nói rằng nó rất có khả năng người dùng đã có Google trong bộ nhớ cache DNS của họ. 3) Xem http://developer.yahoo.com/performance/rules.html đặc biệt là điểm thứ hai: 80-90% thời gian được tải xuống. – nickf

Tùy thuộc vào môi trường phát triển của bạn, bạn có thể xem xét tự động hóa quy trình. Đó là một chút công bằng hơn làm việc lên phía trước, nhưng tôi thấy nó đã được giá trị nó trong thời gian dài. Làm thế nào bạn sẽ đi về làm điều đó phụ thuộc phần lớn vào dự án và môi trường của bạn. Có một vài lựa chọn, nhưng tôi sẽ giải thích (mức cao) những gì chúng tôi đã làm.

Trong trường hợp của chúng tôi, chúng tôi có một số trang web dựa trên ASP.NET. Tôi đã viết một điều khiển ASP.NET chỉ đơn giản là chứa một danh sách các phụ thuộc tĩnh - CSS và JavaScript. Mỗi trang liệt kê những gì nó cần. Chúng tôi có một số trang với 7 hoặc 8 phụ thuộc JS và 4 hoặc 5 phụ thuộc CSS, tùy thuộc vào thư viện/điều khiển được chia sẻ đang được sử dụng.Lần đầu tiên trang tải, tôi tạo một chuỗi công nhân nền mới đánh giá tất cả các tài nguyên tĩnh, kết hợp chúng thành một tệp duy nhất (1 cho CSS, 1 cho JS), và sau đó thực hiện giảm thiểu chúng bằng cách sử dụng Yahoo Yui Compressor (có thể làm cả hai JS và CSS). Sau đó tôi xuất tệp vào thư mục "đã hợp nhất" hoặc "được tối ưu hóa" mới.

Lần sau khi ai đó tải trang đó, điều khiển ASP.NET thấy phiên bản được tối ưu hóa của tài nguyên và tải thay vì danh sách 10-12 tài nguyên khác.

Hơn nữa, nó được thiết kế để chỉ tải các tài nguyên được tối ưu hóa khi dự án đang chạy trong chế độ "RELEASE" (trái ngược với chế độ DEBUG bên trong Visual Studio). Điều này là tuyệt vời vì chúng tôi có thể giữ các lớp, trang, điều khiển khác nhau, vv riêng biệt cho tổ chức (và chia sẻ qua các dự án), nhưng chúng tôi vẫn nhận được lợi ích của việc tải tối ưu hóa. Nó là một quá trình hoàn toàn minh bạch mà không yêu cầu thêm sự chú ý (một khi nó đang hoạt động). Chúng tôi thậm chí đã quay trở lại và thêm điều kiện nơi các tài nguyên không được tối ưu hóa được tải nếu "debug = true" được chỉ định trong chuỗi truy vấn của URL cho các trường hợp bạn cần xác minh/sao chép lỗi trong quá trình sản xuất.

Nguồn

2010-11-09 20:48:55 Matt

Có rất nhiều điều cần cân nhắc khi quyết định cách kết hợp các tệp JS và CSS của bạn.

Bạn có sử dụng CDN để phân phối tài nguyên của mình không. Nếu bạn làm như vậy, bạn có thể nhận được nhiều yêu cầu hơn trên mỗi trang, nếu không thì. Kẻ giết người lớn nhất về hiệu suất với nhiều lượt tải xuống là độ trễ. CND sẽ giảm độ trễ của bạn.
Trình duyệt mục tiêu của bạn là gì. Nếu bạn là đối tượng chủ yếu sử dụng trình duyệt IE8 +, FF3 và WebKit sẽ cho phép 6+ kết nối đồng thời vào một miền phụ cụ thể, bạn có thể lấy đi nhiều tệp CSS hơn (chứ không phải JS). Hơn thế nữa, trong trường hợp trình duyệt hiện đại, bạn thực sự muốn tránh kết hợp tất cả CSS thành một tệp lớn, vì mặc dù tổng thời gian dành cho việc tải xuống 1 tệp lớn sẽ ngắn hơn thời gian để tải xuống 6 tệp nhỏ hơn kích thước bằng nhau, bạn có thể tải xuống nhiều tệp cùng một lúc và tải xuống cho 6 tệp nhỏ hơn sẽ kết thúc trước khi tải xuống một tệp lớn (vì người dùng của bạn sẽ không tối đa băng thông của mình khi tải xuống tệp CSS một mình).
Bạn đang phân phối bao nhiêu nội dung khác từ cùng một tên miền. Hình ảnh, Flash, v.v. sẽ được tính vào giới hạn kết nối của trình duyệt cho mỗi miền phụ. Nếu có thể, bạn muốn di chuyển chúng sang một tên miền phụ riêng biệt.
Bạn có dựa nhiều vào bộ đệm ẩn không. Việc quyết định cách kết hợp các tệp luôn là sự cân bằng giữa số lượng kết nối và bộ nhớ đệm. Nếu bạn kết hợp tất cả các tệp trên một trang và 90% các tệp đó được sử dụng trên các trang khác, người dùng của bạn sẽ bị buộc phải tải xuống lại tệp được kết hợp trên mọi trang của trang web, vì thay đổi 10% cuối cùng.
Bạn có sử dụng chia tách tên miền hay không. Nếu bạn làm thế, một lần nữa cho CSS bạn có thể lấy đi với nhiều tập tin hơn nếu bạn phục vụ chúng từ nhiều tên miền phụ. Các kết nối khả dụng khác - tải xuống nhanh hơn.
Tần suất bạn cập nhật trang web của mình sau khi trang web hoạt động. Nếu bạn làm một bản vá vài ngày một lần sẽ sửa đổi các tệp CSS/JS, bạn chắc chắn muốn tránh kết hợp mọi thứ vào một tệp, vì nó sẽ phá hủy bộ nhớ đệm.

Nhìn chung, đề nghị chung của tôi, không biết tất cả sự thật về những gì tình hình của bạn, là kết hợp tập tin được sử dụng trên tất cả các trang (jquery, jquery-ui, vv) vào một tập tin, sau đó nếu có nhiều tiện ích con được sử dụng trên tất cả các trang hoặc gần như tất cả các trang, kết hợp chúng. Và sau đó kết hợp các tệp độc đáo với trang hoặc chỉ được sử dụng trên một hai trang vào một nhóm khác.Điều đó sẽ mang lại cho bạn mức lợi nhuận lớn nhất, không cần phải tính toán kích thước của từng tệp, số lượt truy cập trên mỗi trang và đường dẫn chuẩn của người dùng trên trang web để đạt được chiến lược kết hợp tối ưu (vâng, tôi phải làm tất cả ở trên cho các trang web rất lớn).

Ngoài ra, một nhận xét khác không liên quan đến câu hỏi của bạn, nhưng về nội dung bạn đã đề cập. Tránh thêm tệp Javascript vào phần đầu của tài liệu. Javascript tải xuống, phân tích cú pháp và thực thi sẽ chặn tất cả các kích hoạt khác trong trình duyệt (ngoại trừ IE9, tôi tin), vì vậy bạn muốn CSS của bạn được đưa vào càng sớm càng tốt trên trang và bạn muốn JavaScripts của bạn được bao gồm vào cuối có thể, ngay trước khi đóng thẻ body, nếu có thể.

Và một nhận xét khác, nếu bạn quan tâm đến việc có được hiệu suất tốt nhất từ trang web của mình, tôi khuyên bạn nên xem một số kỹ thuật tối ưu hóa tối nghĩa hơn, chẳng hạn như tải trước nội dung cho trang tiếp theo sau khi hoàn thành trang hoặc , như sử dụng Comet để chỉ phân phát các tệp javascript được yêu cầu (hoặc các đoạn mã js) khi chúng được yêu cầu.

Nguồn

2010-11-11 05:54:36

Giả sử nó trên apache, nếu không, bỏ qua các câu trả lời :)

tôi đã không cố gắng bản thân mình này được nêu ra nhưng bạn có thể muốn có một cái nhìn tại mod_pagespeed từ google.

Rất nhiều tính năng bạn muốn thực hiện bằng tay đã có trong đó, hãy xem here.

Nguồn

2010-11-11 14:49:40

Tôi đang làm việc trên một dự án thực sự lớn trong cùng khu vực có nhiều định nghĩa kiểu và JS-Scripts khác nhau cho các tác vụ khác nhau trong dự án. Trang web có cùng vấn đề => quá nhiều yêu cầu. Về cơ bản, chúng tôi đã triển khai bản sửa lỗi như sau:

Thành phần hiển thị của ứng dụng ghi nhớ mỗi j cần thiết bao gồm tệp và đặt chúng lại với nhau, được rút gọn ở cuối quá trình hiển thị. kết quả đầu ra được lưu trữ bởi các máy khách thông qua các tiêu đề bộ nhớ đệm và HTTP ETag!
các biểu định kiểu của ứng dụng đã cho dựa vào nhau. Có một phong cách cơ bản rất lớn mà quan tâm về định dạng cơ bản và các đối tượng trang (kích thước, nổi vv) đang được mở rộng bởi một bảng màu cơ bản, có thể được mở rộng bởi một phong cách ghi đè tùy chỉnh cho các khách hàng khác nhau để cho phép tùy chỉnh màu sắc , bố cục, biểu tượng vv .... Tất cả các bảng định kiểu này có thể vượt quá kích thước 300k vì có nhiều biểu tượng làm hình nền ... mỗi biểu tượng có hai định nghĩa - một biểu tượng cho GIF6 và PNG hình ảnh cho tất cả các trình duyệt khác.

Và ở đây chúng tôi đến vấn đề .. lúc đầu các Stylesheets làm việc với @import quy tắc. Chúng tôi đã viết một kịch bản trình bao bọc, phân tích tất cả các kiểu và kết hợp chúng thành một tệp duy nhất. Kết quả là, tất cả các phiên bản IE đã phá vỡ bố trí khi một bảng định kiểu vượt quá kích thước khoảng 250-270k. định dạng trông giống như crap. Vì vậy, chúng tôi đã thay đổi điều này trở lại, do đó trình bao bọc của chúng tôi chỉ đặt cùng hai tờ định kiểu và viết tất cả các trang tính khác theo các quy tắc @import ở trên cùng. Ngoài ra, trình bao bọc sử dụng tiêu đề bộ nhớ đệm và ETag.

Điều này giải quyết được sự cố tải cho chúng tôi.

Trân

(Xin vui lòng, không rant vào tôi bởi vì chúng tôi có một stylesheet 300k. Tin tôi đi, nó chỉ có được vì nhiều lý do.: D)

Nguồn

2010-11-12 09:57:28

Một điều bạn nên làm là tối ưu hóa tập tin .htaccess của bạn để nén và tập tin bộ nhớ cache đúng cách:

# compress text, html, javascript, css, xml: 
AddOutputFilterByType DEFLATE text/plain 
AddOutputFilterByType DEFLATE text/html 
AddOutputFilterByType DEFLATE text/xml 
AddOutputFilterByType DEFLATE text/css 
AddOutputFilterByType DEFLATE application/xml 
AddOutputFilterByType DEFLATE application/xhtml+xml 
AddOutputFilterByType DEFLATE application/rss+xml 
AddOutputFilterByType DEFLATE application/javascript 
AddOutputFilterByType DEFLATE application/x-javascript 

# cache media files 
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$"> 
Header set Cache-Control "max-age=2592000" 
</FilesMatch>

Nguồn

2010-11-12 18:03:33 wajiw

đây là tất nhiên nếu bạn đang sử dụng apache như máy chủ web của bạn :-) – wajiw

Tôi nghĩ đó là cần thiết để thực hiện các optimisations sau:

máy chủ -side:
1. Sử dụng máy chủ web nhanh như nginx hoặc lighttpd để phân phối tệp js và css nếu chưa sử dụng.
2. Bật bộ nhớ đệm và gziping cho các tệp.
Và client-side:
1. Nơi tất cả chung js-file vào minified một và cho phép bộ nhớ đệm hardcore. Nếu trang của bạn không yêu cầu chạy chúng trước khi "tải", bạn có thể thêm một trang vào động. Nó sẽ tăng tốc độ tải.
2. Đặt mã mỗi trang vào các tệp riêng biệt và nếu nó không cần thiết để làm điều đó. trước khi sự kiện onload, thêm nó động.
3. Nếu nó nhiều hơn một vài Kbyte của css ở tất cả, chỉ cần hợp nhất nó thành một. Khác bạn nên chia nó thành kiểu phổ biến và mỗi trang.
4. Nếu bạn cần hiệu suất tốt nhất trên phía máy khách, hãy đặt vào các tệp css phổ biến thực sự phổ biến, áp dụng cho TẤT CẢ các trang. Tải quy tắc bạn cần trên trang chỉ, nó sẽ tăng tốc độ dựng hình.
5. Cách đơn giản nhất để rút gọn js và css lại với nhau là sử dụng YUI Compress. Nếu bạn muốn tăng tốc tốt hơn, bạn có thể loại bỏ tất cả các evals và mã "động" khác và sử dụng Google Closure Compiler.

Nếu nó sẽ không giúp đỡ, hơn tất cả mọi thứ của xấu và bạn cần nhiều máy chủ để phục vụ các file js và css.

Nguồn

2010-11-13 21:52:00

Tối ưu hóa yêu cầu javascript và css

Trả lời

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