이 도구에 대해
CSS 스프라이트 시트는 아이콘, UI 글리프, 이모지 같은 작은 이미지 묶음 전체를 하나의 더 큰 이미지 파일로 합치고, CSS의 background-position을 사용해 각 요소에 딱 맞는 부분만 보여줍니다. HTTP/2의 멀티플렉싱이 등장하기 전에는 이것이 상당히 의미 있는 성능 기법이었습니다. 수십 개의 작은 아이콘 파일을 위해 수십 개의 개별 연결을 여는 것은 하나로 합친 이미지를 위해 하나의 연결만 여는 것보다 느렸고, 이 차이는 HTTP/1.1 연결, CDN의 엄격한 요청 수 제한, 또는 느린 네트워크에서 렌더링을 막는 리소스 요청을 줄이려는 경우에 여전히 의미가 있을 수 있습니다.
이 도구는 그 두 부분을 완전히 브라우저 안에서 대신 만들어 줍니다. 아이콘 파일을 놓고, 가로 한 줄로 배치할지 세로 한 줄로 배치할지, 그리고 그 사이에 투명 여백을 얼마나 둘지 선택하면, 도구가 이를 하나의 캔버스에 그리고 투명도를 보존하기 위해 PNG로 인코딩한 뒤, 각 이미지에 대한 정확한 background-position CSS 규칙을 생성합니다 — 스타일시트에 그대로 복사해 넣으세요. 다만 스프라이트는 다소 오래된 기법입니다. 대부분의 새 프로젝트에서는 인라인 SVG나 SVG 아이콘 폰트가 유지 관리하기 더 간단하고 어떤 크기에서도 더 깔끔하게 확대·축소되므로, 이를 유일한 정답이 아니라 도구 모음의 또 다른 선택지로 여기세요 — 이미 래스터 아이콘(벡터가 아닌 PNG) 세트를 가지고 있고 요청 수를 줄이고 싶을 때 사용하면 좋습니다.
자주 묻는 질문
CSS 스프라이트가 여전히 유효한가요, 아니면 SVG 아이콘을 사용해야 하나요?
대부분의 새 프로젝트에서는 인라인 SVG나 SVG 아이콘 폰트/스프라이트가 보통 더 현대적인 선택입니다(어떤 확대 수준에서도 선명하고, CSS로 쉽게 재색상 가능하며, 고정 픽셀 그리드 정렬 문제가 없음). CSS 스프라이트는 벡터 도형으로 표현할 수 없는 사진/래스터 아이콘 세트, 이미 이 기법을 중심으로 구축된 레거시 코드베이스, 또는 최소한의 HTTP 요청으로 작은 아이콘 세트를 번들링하는 빠르고 의존성 없는 방법으로서 여전히 진정으로 유용합니다. 실제 제약에 맞는 것을 사용하세요 — 이 도구는 래스터 스프라이트 시트가 작업에 적합한 도구일 때를 위한 것이지, 항상 최선의 선택이라는 주장이 아닙니다.
마지막 이미지 뒤에 후행 패딩이 추가되지 않는 이유는 무엇인가요?
이렇게 하면 시트의 총 크기를 가능한 한 작게 유지합니다 — 패딩 설정은 시트가 확대/축소될 때 인접한 아이콘 사이의 텍스처 번짐을 방지하기 위해 존재하며, 이는 두 아이콘이 공유하는 가장자리에서만 문제가 됩니다. 시트 자체의 바깥쪽 가장자리는 반대편에 인접한 아이콘이 없으므로 그곳에 추가 공간을 두는 것은 그 목적에 도움이 되지 않고 파일 크기만 낭비하며, 위치에 따라 각 아이콘이 시트의 절대 가장자리에서 얼마나 떨어져 있는지에 일관성 없는 결과를 초래합니다.