2011-09-20 36 views
10

Năm ngoái, tôi đã dành một thời gian dài đọc về hiệu suất javascript, tắc nghẽn và thực hành tốt nhất. Trong dự án mới nhất của tôi, tôi đang sử dụng CSS3 với các dự phòng cho javascript/jquery cho các hoạt ảnh và hiệu ứng cơ bản như các máy cắt và am quan tâm đến việc thử nghiệm với CSS3 hơn nữa.CSS3 - Các phương pháp hay nhất về hiệu suất là gì?

Có vấn đề với hiệu suất CSS3 không?

Nếu có, các phương pháp hay nhất là gì?

Ví dụ: transition: all 150ms ease-out; sử dụng nhiều bộ nhớ hơn transition: opacity 150ms ease-out, background-color 150ms ease-out;?

[xin đừng chỉ cần trả lời câu hỏi của tôi chẳng hạn!]

+0

Thú vị câu hỏi. Kết quả thử nghiệm của bạn cho đến nay là gì? Bạn đã thử làm một trang với 500 divs giảm bớt thông qua mỗi phương pháp (cũng có thể là đáng giá để thử cách tiếp cận Javascript quá)? –

+0

Đó là một câu hỏi thú vị, nhưng CSS dường như không phải là nút cổ chai hiệu suất trong bất kỳ tình huống thực tế nào. – JJJ

+0

@Steven Xu - haha, tôi nghĩ tôi sẽ hỏi ở đây trước. Không có điểm sáng tạo lại bánh xe nếu ai đó đã tạo ra một tài nguyên trực tuyến tuyệt vời ở đâu đó, tôi sẽ kiểm tra tốt nhất và sau đó thực hiện các thí nghiệm của tôi để mở rộng khi những gì đã được thực hiện ... – Haroldo

Trả lời

-6

Để kiểm tra mà ra, bạn sẽ phải làm cho hình ảnh động của bạn xảy ra 500 hoặc 1000 lần và thời gian nó.

Hoạt ảnh Canvas và HTML5 có nhiều CPU hơn flash. Flash trên iPhone hoạt động tốt hơn các lựa chọn thay thế HTML5. Tôi sẽ làm hình ảnh động, âm thanh và video của tôi bằng cách sử dụng JQuery như HTML5 hoán đổi linh hoạt để thuận tiện.

+1

Flash trên iPhone ...? – JJJ

+0

ditto - flash trên iphone ??? và jQuery cũng hoàn toàn không liên quan đến Flash. – Spudley

+0

Không hoàn toàn chắc chắn làm thế nào flash đi vào nó, tôi đang xem xét thao tác các yếu tố dom. CSS, javascript và jquery sử dụng 'css', flash hoạt động trên một canvas hoàn toàn khác? – Haroldo

24

O có! Nếu bạn thích tinker với hiệu suất - bạn sẽ vui mừng khi biết có rất nhiều vấn đề hiệu suất với CSS3.

  1. sơn lại và Reflow. Nó khá dễ dàng để gây ra repaints không cần thiết và reflows, và do đó làm cho toàn bộ trang lag. Đọc: http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/ Ví dụ cực đoan: http://files.myopera.com/c69/blog/lag-me.html
  2. Cuộn và di chuột. Khi bạn cuộn hoặc di chuột, trình duyệt phải hiển thị nội dung mới. Webkit là thông minh ở đây, vì nó lưu trữ các trang dưới dạng hình ảnh tĩnh nên nó KHÔNG hiển thị trang, khi bạn cuộn. Nhưng - bạn có thể bỏ qua tối ưu hóa này, bằng cách sử dụng những thứ như nền trong suốt trong khối mà bạn đang cuộn, thêm xoay khi di chuột, thêm position:fixed đầu đề/chân trang dính với hiệu ứng như vậy sẽ cảnh giác trong các trình duyệt khác nhau, Opera dường như bị ảnh hưởng nhiều nhất hiện tại .
  3. Bóng bóng là điều xấu. Hộp đổ bóng có chất lượng hiển thị khác nhau trong các trình duyệt khác nhau (thấp trong Webkit, cao trong Opera/IE9, thay đổi giữa các phiên bản Firefox) - và do đó tác động hiệu suất của chúng khác nhau giữa các trình duyệt khác nhau, chưa có bóng. với bán kính trải rộng lớn có thể gây treo cứng có thể quan sát khi vẽ lại trong bất kỳ trình duyệt nào.
  4. Nổi, bảng và bạn bè của họ là xấu. Âm thanh điên lúc đầu, nhưng đọc bài viết này (bằng tiếng Nga) - http://chikuyonok.ru/2010/11/optimization-story/ - nó có thể giúp bạn tiết kiệm một số tóc trên đầu của bạn. Ý tưởng chính là - trẻ em của các yếu tố nổi nguyên nhân gây ra chuỗi reflows trên sửa đổi tất cả các con đường lên.
  5. Bán kính viền rất tốn kém, thậm chí còn đắt hơn gradient. Không ảnh hưởng đến bố cục, nhưng ảnh hưởng đến sơn lại. http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/
  6. Độ trễ của độ dốc. Độ dốc CSS là công cụ mới rất thú vị, tôi là một fan lớn của chúng. Tuy nhiên, chỉ một vài thử nghiệm đã cho thấy rằng bạn không nên sử dụng chúng, nếu bạn dự định có nhiều yếu tố với độ dốc và yêu cầu giao diện đáp ứng: (Mặc dù vậy, có một cách giải quyết khác) - sử dụng canvas để hiển thị hình ảnh và thiết lập gradient chúng làm nền thông qua url dữ liệu.
  7. Độ trong suốt rất tốn kém. Nếu bạn có một số yếu tố di chuyển ngang nhau và bán trong suốt (độ mờ < 0, màu rgba, png, góc tròn (!)) - mong đợi độ trễ. Thường có thể được giải quyết bằng cách giới hạn số lượng các phần tử trong suốt, có thể che phủ.
  8. Chuyển tiếp tốt hơn JS, nhưng ... Firefox không thể hiển thị chuyển tiếp chính xác, nếu bạn áp dụng chúng cho hơn 150 phần tử cùng một lúc. Opera không thể áp dụng hiệu ứng chuyển tiếp cho trước và sau. IE9 không hỗ trợ gì cả. Thử nghiệm trước khi bạn sử dụng chúng, nhưng nói chung - chúng nhanh hơn so với các chất tương tự JS (jQuery.animate).
  9. Xem ra để tải CPU. Thật khó để đo lường mức sử dụng bộ nhớ của trình duyệt, (nhưng bạn có thể làm điều đó trong kết quả chrome và nội suy, với một số hạt muối) nhưng dễ dàng quan sát việc sử dụng CPU (thông qua Process Explorer hoặc các công cụ hệ thống). Spikes sẽ hiển thị cho bạn các địa điểm, nơi bạn cần sự chú ý của mình.
  10. Trình duyệt cũ cũ. Đừng cố gắng hiện đại hóa IE6, Firefox 2, Safari 3. Những trình duyệt này không bao giờ phải xử lý những thứ mới mẻ. Để họ một mình. Chỉ phục vụ nội dung cơ bản với các kiểu cơ bản. Người dùng IE6 còn lại sẽ biết ơn vì điều đó.
+1

Cảm ơn các con trỏ! Tôi chắc chắn sẽ không đồng ý với những người đã đóng câu hỏi này vì "không xây dựng". Tôi sẽ coi ý kiến ​​của bạn là có tính xây dựng cao. TBH có vẻ như đã kết luận rằng mọi người đang đóng một câu hỏi như thế này. – Haroldo

+0

Từ những gì tôi biết, hộp bóng: inset với bán kính> = 15px thực sự chậm trong Safari. Đối với các trường hợp khác: chỉ không lạm dụng tính năng này. – kirilloid

+0

Cả hai biến đổi 2D và 3D đều rất tốn kém, cũng như 'hoạt hình'. Nhưng trong hầu hết các trường hợp, bạn sẽ nhận thấy tác động hiệu suất mà không có bất kỳ mẹo hoặc công cụ bên ngoài nào;) – c69

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