Có giới hạn nào về số lượng phần tử html, trình duyệt đó có thể hiển thị mà không gặp sự cố không?

Question

Về cơ bản tôi có một bảng lớn, thậm chí còn lớn hơn khi người dùng cuộn xuống (tự động tải trước các hàng tiếp theo). Tại một số trình duyệt điểm trở nên chậm chạp, nó bắt đầu treo trong một thời điểm khi tôi nhấp chuột xung quanh hoặc cố gắng di chuyển và chậm chạp hơn nó trở thành, càng có nhiều hàng nó nhận được. Tôi tự hỏi liệu có bất kỳ giới hạn nào về số lượng các yếu tố mà trang đó có thể giữ không? Hoặc có thể nó chỉ là javascript của tôi bị rò rỉ ở đâu đó (mặc dù tôi chỉ có một trình xử lý sự kiện, được gắn với bảng của bảng - và một kịch bản phân tích các sự kiện hỗn loạn sôi nổi).

Cập nhật: Sự chậm trễ trở nên đáng chú ý sau hàng nghìn hàng được tải. Tốc độ di chuyển của nó khá dễ chịu, nhưng ví dụ làm nổi bật hàng được nhấn (với sự trợ giúp của trình xử lý sự kiện đơn lẻ trên tbody) là đau đớn (mất ít nhất 2-3 giây và trì hoãn tăng lên với số hàng). Tôi quan sát sự chậm trễ trên tất cả các trình duyệt. Không chỉ tôi, mà là hầu hết mọi người truy cập trang, vì vậy tôi đoán ở một mức độ nào đó nó ảnh hưởng đến mọi nền tảng.

Cập nhật: Tôi đã đưa ra ví dụ đơn giản ở đây: http://client.infinity-8.me/table.php?num=1000 (bạn có thể vượt qua bất cứ số nào bạn muốn num), về cơ bản nó ám một bảng với num hàng và có một handler sự kiện duy nhất gắn liền với một bảng cha. Tôi nên kết luận từ điều này, rằng có thực sự là không có đáng chú ý thả xuống trong hiệu suất, gây ra bởi số lượng các yếu tố con. Vì vậy, nó có thể bị rò rỉ ở một nơi khác: (

Answer 1

Tôi không nghĩ rằng có giới hạn được xác định theo tiêu chuẩn. Có thể có giới hạn được mã hóa cứng trong mỗi lần triển khai trình duyệt, mặc dù tôi sẽ tưởng tượng rằng giới hạn này có thể là hàng tỷ phần tử. Giới hạn khác là số lượng bộ nhớ địa chỉ.

Để khắc phục sự cố của bạn: Cũng như tự động tải các phần tử khi bạn cuộn xuống, bạn có thể tự động xóa các phần tử đã cuộn lên khỏi màn hình. Sau đó, chương trình của bạn sẽ vẫn nhanh ngay cả sau khi cuộn rất nhiều.

Bạn cũng có thể muốn xem xét một giao diện thay thế như phân trang.

Answer 2

Tôi không nghĩ rằng có giới hạn. Tuy nhiên, tệp HTML càng dài thì càng cần nhiều tài nguyên hơn, nhưng bảng phải rất lớn sau đó ...

Answer 3

Giới hạn thực sự được xác định bởi tác nhân người dùng và máy khách đang được sử dụng. HTML, giống như XML, là định dạng cây dữ liệu.

Tôi đã gặp sự cố khi thêm hơn 100 bảng vào div (như cách giải quyết cũ cho IE6 không thể tạo các phần tử bảng động)

Answer 4

Nếu bạn có JS trên mỗi hàng của bảng thì máy tính cũ sẽ không xử lý được. Đối với chính HTML, bạn không nên lo lắng nhiều.

Bạn nên lo lắng về thực tế là con người bình thường không thích các bảng lớn, đây là cách phân trang được tạo ra. Phân tách nó bằng cách sử dụng phân trang cho khả năng sử dụng tốt hơn cũng như các mối quan tâm khác.

Hãy nghĩ đến sách không có trang nhưng có một trang lớn, bạn có muốn đọc nó không? Ngay cả khi đôi mắt của bạn (PC trong trường hợp của chúng tôi) có thể xử lý nó.

Answer 5

Bạn đang sử dụng trình duyệt nào? Một số trình duyệt có thể xử lý mọi thứ tốt hơn so với các trình duyệt khác - ví dụ, nếu bạn đang sử dụng IE, tôi sẽ không ngạc nhiên nếu nó chậm chạp - nó không xử lý các sự kiện javascript cũng như các trình duyệt dựa trên webkit.

Điều khác rõ ràng là máy tính của bạn (RAM và CPU). Nhưng phải trung thực, hầu hết các máy tính không nên có vấn đề với điều đó trừ khi chúng tôi đang nói 10000 hàng ... và thậm chí sau đó ...

Bạn có thể đăng một số mã không?

Answer 6

Vì có rất nhiều trình duyệt và công cụ hiển thị và tất cả đều có các đặc tính hiệu suất khác nhau và cũng cho rằng những công cụ đó được cải thiện liên tục về hiệu suất và phần cứng máy tính nhanh hơn mọi lúc: Không có giới hạn trên cố định những gì một trình duyệt có thể xử lý. Tuy nhiên, có giới hạn trên hiện tại trên phần cứng cụ thể cho các phiên bản trình duyệt cụ thể.

Nếu bạn không xác định rõ phần cứng và trình duyệt của bạn khó có thể giúp bạn. Ngoài ra, không ai có thể đưa ra bất kỳ đề xuất nào liên quan đến hiệu suất có thể có của Javascript của bạn nếu bạn không đăng mã. Thậm chí nếu nó chỉ là một trình xử lý sự kiện, nếu nó lặp vô hạn hoặc nếu nó được gọi cho mỗi phần tử, nó có thể làm chậm đáng kể quá trình kết xuất.

Answer 7

RAM không sử dụng hoặc sử dụng CPU, kích thước thực của tệp sau khi tải trước là gì?

Nếu bảng của bạn thực sự khổng lồ, bạn có thể buộc người dùng tải xuống megabyte dữ liệu - tôi thấy rằng một số máy có xu hướng treo sau 2-4MB dữ liệu.

Answer 8

Một điều bạn nên xem xét là định cỡ bảng. Nếu bạn có bảng theo kiểu với table-width:auto;, trình duyệt phải đo từng phần tử trong bảng để định kích thước bảng. Điều này có thể cực kỳ chậm chạp.

Thay vào đó, hãy chọn chiều rộng cố định hoặc ít nhất là kiểu bảng sử dụng table-width:fixed.

Answer 9

Tùy thuộc. Ví dụ, IE sẽ không bắt đầu vẽ một bảng cho đến khi tất cả nội dung được tải. Vì vậy, nếu bạn có một bảng 5.000 hàng, nó cần tải tất cả 5.000 hàng dữ liệu trước khi hiển thị bất kỳ vị trí nào khi các trình duyệt khác bắt đầu hiển thị khi chúng có dữ liệu một phần và chỉ cần điều chỉnh một chút (nếu cần) khi bảng tăng lên.

Nói chung hiển thị chậm với số lượng nút nhưng cũng với độ phức tạp của các nút ... Tránh các bảng lồng nhau và nếu có thể, hãy cố gắng chia các bảng lớn thành các khối ... Ví dụ: Mỗi 100 hàng (nếu có thể)

Answer 10

Thực sự không phải là lý do để xuất bản toàn bộ tập dữ liệu khổng lồ trên một trang. Nếu yêu cầu là cung cấp cho người dùng tất cả dữ liệu đó, thì bạn nên xuất nó sang một tệp có thể được đọc bởi một số phần mềm tốt hơn so với một trình duyệt. Thay vào đó, tôi khuyên bạn nên tạo trang AJAX, nơi bạn cho phép người dùng thấy một phần dữ liệu và nếu họ cần xem thêm, bạn chỉ cần tải xuống phần dữ liệu đó và thay thế tập dữ liệu hiện tại vào trang. Đây là phân trang. Tìm kiếm của Google là một ví dụ tuyệt vời về điều này.

Answer 11

Nếu có bất kỳ giới hạn nào, điều đó tùy thuộc vào trình duyệt. Nhưng vấn đề bạn có nó không phải về giới hạn, vì trình duyệt vẫn hiển thị trang.

Bảng lớn luôn gặp sự cố với trình duyệt. Việc hiển thị một bảng lớn mất rất nhiều thời gian. Do đó, thường là ý tưởng tốt để chia bảng lớn thành các bảng nhỏ hơn.

Hơn nữa, bạn có thể muốn chỉ định chiều rộng cột.Nếu không có điều đó, trình duyệt phải tải xuống toàn bộ bảng trước khi nó có thể tính toán chiều rộng của mỗi cột và hiển thị bảng. Nếu bạn chỉ định chiều rộng trong mã HTML, trình duyệt có thể hiển thị trang trong khi nó vẫn đang tải xuống. (Lưu ý: chỉ định chiều rộng của toàn bộ bảng không đủ, bạn cần phải xác định chiều rộng của mỗi cột.)

Nếu bạn thêm một dòng vào bảng lớn bằng Javascript, trình duyệt có nhiều khả năng hiển thị toàn bộ bảng một lần nữa. Đây là lý do tại sao nó trở nên quá chậm. Nếu bạn có các bảng nhỏ hơn, chỉ một bảng nhỏ cần được hiển thị lại. Vẫn tốt hơn, nếu bạn tải một bảng phụ tại một thời điểm thay vì chỉ một dòng.

Nhưng phương pháp hiệu quả nhất là chia dữ liệu thành nhiều trang. Người dùng cũng có thể thích điều đó. Đó là lý do tại sao ví dụ Google chỉ hiển thị rất nhiều kết quả trên mỗi trang.