스프라이트/PNG 그래픽이 많은 사이트, 오 마이!

Question

파일 크기를 절약 할 생각이었던 한 가지 방법은 모든 배경 요소를 하나의 PNG로 삭제하는 것이 매우 그래픽이 많은 사이트를 만들어야합니다. 문제는이 파일이 이제 180k라는 것입니다. 내가 그것을 다양한 GIF와 몇 개의 PNG로 분해하면 70K에 가까워 질 것입니다.

정말로 중요합니까? 요즘 파일 크기의 경우 "너무 큰"것은 무엇입니까? 파일이 180 또는 70k인지 알 수 있습니까?

Answer 1

사용자가 사이트에 빠르게 액세스 할 수있는 경우 (예 : 인트라넷) 180K는 문제가되지 않습니다. 반면 에이 사이트가 유머러스하게 연결된 일반 노인이 사이트를 사용한다면 아마도 문제가 될 것입니다. 사용자가 GPR을 사용하지만 끝없는 인내심이 있다면 문제가되지 않을 것입니다. 사이트가로드 시간을 기다리는 인내심을 가진 사람에게 백만 달러를 제공하는 경우 전송 속도는 문제가되지 않습니다. 등등.

내가 말하는 것은 실제로 당신의 요구 사항과 제약에 달려 있습니다. 이것은 당신이 그것을 오른쪽에 가깝게 얻기 전에 많은 것들을 알아야한다 (그리고 우리가 더 도움이되기 위해 우리에게 더 도움이되기 위해 우리에게 말해 주어야한다)를 필요로한다.

매우 밸리드의 응답을위한 성가신 다운 보트를 피하기 위해, 단순하게 불안하지 않은 것은 다음과 같습니다.

180K는 표준 ADSL 모뎀 전송 속도 = 180KB / 100KB / S = 1.8S = 엔디 어이블로 나뉩니다.

Answer 2

이유가 있습니까? ~ 아니다 작은 이미지를 사용하려면? 이미 분해 된 것 같습니다. 더 작고 빠른 방법을 사용해 보지 않겠습니까?

순수한 상대 론적 관점에서 70k는 180k의 다운로드 시간의 38% 만 소요됩니다 (대략). 트래픽이 높거나 빠른로드 시간을 원한다면 모든 비트가 도움이됩니다.

Answer 3

모든 별도의 이미지를 요청하는 데 걸리는 시간과 큰 이미지를 다운로드하는 데 걸리는 시간을 비교해야합니다. 문제는 HTTP 요청에 관한 것입니다.

Google의 Firefox Extension으로 일부 테스트를 실행하는 것이 좋습니다. PagesPeed 큰 PNG 또는 별도의 PNG 사이에 큰 차이가 있는지 확인합니다.

HTTP 요청이 적은 것 외에도 모든 그래픽이 다운로드 될 때 사이트가 점진적으로 한 번에로드된다는 것입니다. 그러나 헨릭이 말했듯이 결론은 요구 사항에 따라 다르다는 것입니다.

Answer 4

여러 이미지로 분할하면 서버에 추가로 연결되어 각각의 지연과 관련된 지연과 요청 및 응답 헤더의 추가 크기를 의미합니다.

브라우저는 각 서버에 대한 활성 연결 수 (브라우저 버전 종속)를 제한하기 때문에 단일 이미지를 검색하는 것보다 오래 걸릴 수 있습니다. 한계를 높이기위한 일반적인 해결 방법은 별도의 "이미지"서버 또는 동일한 호스트에 맵핑하는 DNS 별칭을 사용하는 것입니다.

애니메이션이 필요하지 않으면 항상 GIF보다 PNG를 추천합니다.

Answer 5

이미지가 먼저 비활성화 된 상태에서 사이트가 잘 보이도록하고 (따라서 Alt Tag, Width 및 Heights Set, 사용 된 올바른 색상) 이미지를 그룹으로 분할하십시오. 가능한 경우 모든 버튼을 한 이미지로 그룹화하고 (CSS 스프라이트 시트 사용) 모든 경계를 다른 이미지로 그룹화하십시오. 큰 이미지를 별도의 파일 (SO 사이트 배경, 헤더)으로 유지하십시오.

이미지가 많을수록 브라우저가 더 많은 요청을 병렬화 할 수 있습니다. 그러나 너무 많이 나누면 다른 이미지가 다른 시간에로드되어 사이트의 일부를 팝업으로 만듭니다. 약간의 트레이드 오프이지만 프로그래밍의 기쁨입니다 :)

이미지가 보이기 전에 사이트가 더 좋아질수록 사용자가 이미지 다운로드 속도를 덜 신경 쓰지 않습니다.