Câu hỏi "đơn giản".Nhiều hình ảnh vs spritesheet
Có tốt hơn không khi sử dụng các tệp họa tiết lớn cho các phần tử trang web hơn là sử dụng nhiều hình ảnh? 
Ý tôi là, thực hiện thao tác hình ảnh CSS bổ sung (định vị nền hình ảnh lớn và cắt hình ảnh) bù cho yêu cầu hình ảnh HTTP ít hơn?
number of concurrent HTTP/1 connections to a host được giới hạn ở khoảng 6. Giả sử độ trễ 100ms, khoảng 60 hình ảnh trong sprite được đăng sẽ mất ít nhất một giây để tải xuống (có thể nhiều hơn, vì yêu cầu và câu trả lời HTTP cần được tạo và phân tích cú pháp).
Vì kích thước của hình ảnh sprite giống như hình ảnh riêng lẻ và xử lý hình ảnh nhanh chóng (tôi ước tính dưới < 100 ms cho tất cả 60 hình ảnh cùng nhau), sử dụng sprites tiết kiệm amazon khoảng 900ms tải thời gian, một tác động đáng chú ý - và đó là về mặt lý thuyết, mà không tính đến chi phí khổng lồ của việc phải phân phối 60x số lượng yêu cầu mà họ sẽ phải làm khác.
Tóm lại, sử dụng sprites cho biểu tượng và hình ảnh nhỏ qua HTTP/1.
HTTP/2 được thiết kế sao cho các giải pháp thay thế không còn cần thiết nữa. Quan trọng nhất, nhiều yêu cầu có thể được phân phối đồng thời trên cùng một kết nối TCP. Ngoài ra, nén tiêu đề được thiết kế để nén tiêu đề dư thừa chẳng hạn như User-Agent hoặc Accept.
Thường tốt hơn nên sử dụng các hình ảnh nhỏ mà nhiều hình ảnh nhỏ.
Mọi hình ảnh đều tạo thêm yêu cầu http và cần thời gian. Đặc biệt với HTTP 1.0, mỗi yêu cầu mới cần phải chờ phản hồi trước đó.
Đối với những bức ảnh rất lớn - nó chủ yếu phụ thuộc vào tỷ lệ thời gian cần thiết để chuyển một hình ảnh của một tập hợp lên trên cao trong thời gian đến từ giao thức HTTP. Nếu chi phí không lớn và bạn cảm thấy những hình ảnh lớn như vậy có thể làm chậm ứng dụng của bạn - bạn có thể sử dụng nhiều hình ảnh, nếu nó có liên quan - hãy sử dụng sprites css.
Nhưng nếu bạn có hình ảnh có kích thước 1024 * 1024px và bạn có 30 phần tử trong đó bạn phải vẽ hình ảnh đó 30 lần bên trong một div riêng biệt và mỗi lần có một vị trí nền khác. Đó không phải là kết xuất chậm? – Cristy
Những ngày này chúng tôi có CPU lõi tứ và biểu diễn RAM. Bạn nghĩ sao? – robert
Tất nhiên có tình huống khi các sprites css không phải là ý tưởng hay nhất - ví dụ với các bức ảnh khổng lồ không ai kết hợp chúng thành một bức tranh lớn hơn. Có một giới hạn cho điều đó. Nhưng nó là một phần mềm, vì vậy bạn cần phải làm một số thử nghiệm của riêng bạn nếu bạn có nhu cầu không tiêu chuẩn –
Chắc chắn, nó tốt hơn. Trình duyệt sẽ chỉ thực hiện yêu cầu cho tệp, so với nhiều yêu cầu đối với nhiều tệp hơn.
Sử dụng sprites cho nhiều hình ảnh nhỏ có xu hướng lặp lại trong thiết kế của bạn (biểu tượng cho ví dụ). Đối với những bức ảnh lớn, đó không phải là ý tưởng hay, trong trường hợp của một bộ sưu tập ảnh.
Có, đối với bất kỳ kích thước hình ảnh hợp lý nào, nó sẽ nhanh hơn.
Vẽ một phần của hình ảnh lớn hơn không chậm hơn so với vẽ toàn bộ hình ảnh nhỏ hơn. Không giống như trình duyệt đang vẽ toàn bộ hình ảnh và xóa các phần không hiển thị, nó chỉ vẽ một phần của hình ảnh đang hiển thị. Nó chỉ sao chép điểm ảnh từ bộ nhớ, và nó rất quan trọng nếu các điểm ảnh gần nhau trong bộ nhớ hoặc trải ra trong một hình ảnh lớn hơn.
Hình ảnh lớn hơn mất nhiều thời gian hơn để tải một hình ảnh nhỏ, vì vậy hình ảnh nhỏ hơn sẽ bắt đầu hiển thị nhanh hơn, nhưng hình ảnh lớn tải nhanh hơn rất nhiều so với tất cả các hình ảnh nhỏ cùng nhau. Ngay cả khi bạn phải đợi lâu hơn một chút trước khi hình ảnh bắt đầu hiển thị, tất cả các hình ảnh hiển thị cùng một lúc thay vì xuất hiện từng ảnh một.
Tôi tự hỏi liệu điều này vẫn áp dụng với tiêu chuẩn 'HTTP/2' mới và cải thiện tải xuống song song hay chưa. Ngoài ra, nếu bạn sử dụng nhiều hình ảnh, bạn chỉ có thể tải xuống những hình ảnh bạn cần ở chiều cao cuộn hiện tại. – Cristy
@Cristy Đã thêm giải thích cho HTTP/2. Tải xuống một biểu tượng nhỏ chỉ sau khi cuộn có thể nguy hiểm, vì bạn hiện đang áp dụng ít nhất một RTT (và thường nhiều hơn) trên mỗi lần tải trang, chưa kể rằng các biểu tượng của bạn sẽ chỉ được tải sau JavaScript và trang web sẽ ngắt nếu người dùng cuộn sau khi mất kết nối Internet. – phihag