반응형 이미지, srcset과 sizes를 같이 적습니다

후보 목록과 표시 크기를 둘 다 알려 줍니다

반응형 이미지에서 흔한 실수는 후보 목록만 적고 표시 크기를 적지 않는 것입니다. 브라우저는 이미지가 화면에서 얼마나 크게 보일지 알아야 적절한 후보를 고를 수 있는데, 그 정보는 레이아웃이 계산된 뒤에야 확정됩니다. 그래서 미리 알려 주지 않으면 브라우저는 화면 전체 너비를 가정하고 가장 큰 후보를 고릅니다. 결과적으로 작은 영역에 큰 이미지를 받게 됩니다. 그래서 두 가지를 함께 적습니다. 후보 파일들과 각 파일의 실제 픽셀 너비, 그리고 화면 폭 구간별로 이 이미지가 차지할 크기입니다. 둘 중 하나만 적으면 효과가 없습니다.

후보 폭은 실제 레이아웃에서 역산합니다

후보 폭을 임의로 정하면 쓰이지 않는 파일이 생기거나 딱 맞는 파일이 없습니다. 그래서 역산합니다. 1단계로 이 이미지가 쓰이는 화면 폭 구간을 적습니다. 2단계로 각 구간에서 이미지가 차지하는 실제 폭을 계산합니다. 3단계로 고해상도 화면을 고려해 그 값의 두 배까지 후보를 둡니다. 4단계로 비슷한 값을 묶어 후보 수를 줄입니다. 이렇게 하면 후보가 네다섯 개로 정리되고 각각이 실제로 쓰입니다. 또 가장 작은 후보가 모바일에서 쓰이는 값이므로, 그 파일의 용량을 특히 신경 써서 줄입니다. 모바일이 전체 방문의 다수인 경우가 많습니다.

모바일 전송 절감을 계산합니다

학습용 가정으로 계산합니다. 가정값은 원본 이미지가 400킬로바이트이고 모바일용 작은 후보가 24킬로바이트이며, 월 모바일 방문이 50,000건이라고 두겠습니다. 한 건당 절감은 376킬로바이트입니다. 월 절감은 18,800,000킬로바이트이고 기가바이트로는 18.8기가바이트입니다. 이것이 중간 계산값입니다. 최종 효과는 두 가지로 나타납니다. 전송 요금이 그만큼 줄어들고, 모바일 사용자의 첫 화면 렌더가 빨라집니다. 두 번째가 더 중요합니다. 큰 콘텐츠가 그려지는 시간의 로드 구간이 직접 줄어들기 때문입니다.

원본이 작으면 후보를 늘려도 소용없습니다

결론을 뒤집는 조건은 원본 품질입니다. 원본이 작은 이미지를 크게 늘려 쓰고 있다면 후보를 여러 개 만들어도 큰 화면에서 흐릿합니다. 이 경우 먼저 원본을 확보해야 합니다. 두 번째 조건은 압축 형식입니다. 같은 폭이라도 형식에 따라 용량이 크게 달라지므로, 폭을 나누기 전에 형식을 최신 형식으로 바꾸는 쪽이 효과가 큰 경우가 많습니다. 그래서 작업 순서를 형식 변경, 폭 분할, 표시 크기 선언으로 둡니다. 세 번째는 배경 이미지입니다. 스타일로 넣은 배경은 후보 목록을 쓸 수 없으므로 화면 폭 조건으로 다른 파일을 지정해야 합니다.

성능 최적화 실행 전 점검표

• 후보 목록과 표시 크기를 함께 적었다
• 후보 폭을 실제 레이아웃에서 역산했다
• 가장 작은 후보의 용량을 집중적으로 줄였다
• 형식 변경을 폭 분할보다 먼저 검토했다