Technote

성능 최적화 실무

마케터가 직접 확인하는 랜딩 페이지 속도

개발자에게 "빠르게 해 주세요" 라고 요청하면 무엇을 해야 할지 정해지지 않습니다. 이미지 · 서드파티 스크립트 · 폰트 · 히어로 이미지 네 가지는 마케터가 직접 확인해 항목으로 넘길 수 있습니다.

랜딩 페이지가 느리다는 것은 대개 감으로 먼저 압니다. 문제는 그다음입니다 — 개발자에게 “속도를 개선해 주세요” 라고 요청하면 상대는 무엇부터 봐야 할지 정하는 일부터 시작해야 하고, 그 일은 우리가 대신해 줄 수 있는 부분이 꽤 많습니다.

아래 네 항목은 브라우저와 눈만으로 확인할 수 있습니다. 코드를 읽을 필요도, 서버에 들어갈 필요도 없습니다. 확인이 끝나면 요청서가 “빠르게” 가 아니라 파일 이름과 도메인 목록이 됩니다.

준비 — 개발자 도구의 네트워크 탭 하나면 됩니다

브라우저에서 개발자 도구를 열고 네트워크 탭으로 갑니다. 캐시를 비운 상태에서 페이지를 새로 고치면, 그 페이지를 그리기 위해 내려받은 파일이 전부 목록으로 나옵니다. 여기서 볼 것은 두 가지입니다 — 크기 열로 정렬해 무거운 순서를 보고, 도메인으로 우리 것과 남의 것을 가릅니다. 하단에 전체 전송량과 요청 수가 표시되는데, 이 두 숫자를 개선 전후로 적어 두면 그것만으로도 리포트가 됩니다.

모바일 기준으로 보는 것이 중요합니다. 개발자 도구의 기기 시뮬레이션을 켜고, 네트워크 속도 제한을 걸어 두면 실제 방문자에 가까운 조건이 됩니다.

① 이미지 — 표시 크기보다 큰 원본을 찾습니다

가장 흔하고 가장 쉽게 고쳐지는 항목입니다. 크기 순으로 정렬한 목록의 위쪽은 거의 언제나 이미지입니다. 각 이미지에 대해 확인할 것은 원본 크기와 실제 표시 크기의 차이입니다. 화면에서 400px 폭으로 보이는 이미지의 원본이 3,000px이라면, 방문자는 보이지도 않는 픽셀을 내려받고 있는 셈입니다.

확인 방법은 간단합니다. 이미지를 새 탭에서 열면 주소창 옆이나 탭 제목에 원본 픽셀 크기가 표시되고, 요소 검사에서 그 이미지에 마우스를 올리면 실제 표시 크기가 함께 뜹니다. 둘을 비교합니다.

파일 형식도 함께 봅니다. 사진인데 PNG로 저장돼 있으면 대체로 필요 이상으로 무겁습니다. 요청서에는 파일 이름 · 원본 크기 · 표시 크기를 그대로 적어 넘기면 됩니다.

② 서드파티 스크립트 — 도메인 수를 셉니다

네트워크 목록에서 우리 도메인이 아닌 것들을 골라 냅니다. 분석 도구, 광고 픽셀, 채팅 위젯, 폰트 서비스, A/B 테스트 도구, 소셜 공유 버튼이 여기 해당합니다. 이 목록이 길어지는 과정에는 공통점이 있습니다 — 대부분 마케팅 쪽에서 하나씩 추가한 것이고, 그래서 마케터가 가장 정확하게 정리할 수 있습니다.

각 항목에 대해 세 가지를 묻습니다. 지금도 쓰고 있는가, 이 데이터를 실제로 보는 사람이 있는가, 없어지면 곤란한가. 세 질문에 전부 “아니오” 인 항목이 대개 두세 개 나옵니다. 캠페인이 끝난 뒤 남은 픽셀, 몇 번 쓰고 만 히트맵 도구, 예전 대행사가 넣은 태그가 전형적입니다.

서드파티 목록 정리 — 판단 기준은 기술이 아니라 "지금 쓰는가" 다

③ 폰트 — 굵기와 파일 수를 봅니다

목록에서 .woff2 로 끝나는 파일을 세어 봅니다. 한글 웹폰트는 라틴 폰트보다 훨씬 무겁기 때문에, 굵기를 여럿 쓰면 그만큼 파일이 늘어납니다. 디자인에서 실제로 쓰는 굵기가 두세 개인데 여섯 개가 로드되고 있는 경우가 흔합니다.

여기서 마케터가 확인할 것은 기술이 아니라 디자인 결정입니다. 이 페이지에서 실제로 쓰이는 굵기가 몇 개인지 세어 개발자에게 알려 주면, 나머지를 정리하는 것은 그쪽에서 할 수 있는 일입니다.

④ 히어로 이미지에 lazy 가 붙어 있는가

이것 하나만 따로 다루는 이유가 있습니다. 이미지 지연 로딩은 아래쪽 이미지에는 좋은 기법이지만, 첫 화면의 가장 큰 이미지에 걸리면 오히려 표시가 늦어집니다. 그 이미지가 대개 페이지의 로딩 완료 인상을 좌우하는 요소이기 때문입니다.

확인 방법은 이렇습니다. 히어로 이미지에서 요소 검사를 열고 그 img 태그에 loading="lazy" 가 붙어 있는지 봅니다. 붙어 있다면 그것 하나가 개선 항목입니다. 많은 플러그인과 테마가 모든 이미지에 일괄로 지연 로딩을 걸기 때문에 의외로 자주 발견됩니다.

요청서 형태로 넘기기

네 항목을 확인했으면 요청은 이렇게 바뀝니다. “느립니다” 대신 “첫 화면 배경 이미지가 원본 3,000px인데 표시는 1,200px입니다 / 서드파티 도메인 아홉 개 중 셋은 종료된 캠페인 태그입니다 / 폰트 굵기 여섯 개가 로드되는데 디자인에서 쓰는 것은 셋입니다 / 히어로 이미지에 lazy 속성이 붙어 있습니다” 가 됩니다. 같은 요청인데 상대가 바로 착수할 수 있습니다.

측정과 개선의 순환을 만드는 방법은 속도와 전환율 연재에서, 원리 쪽은 성능 최적화 아카이브에서 더 다룹니다. 사이트 전체의 상태를 한 번에 재 보고 싶다면 무료 도구의 사이트 진단을 써 보시고, 서버 · 캐시 계층까지 함께 손봐야 하는 상태라면 최적화 지원 사업에서 다룹니다.

이 주제의 다른 글

노하우 목록으로

성능 최적화 심화

부모 테마 자산 걷어내기 — 절차와 뒤따르는 책임

쓰지 않는 스크립트를 내리는 것은 가능합니다. 다만 그 자산에 기대던 기능의 책임이 함께 넘어오므로, 무엇이 실제로 깨지는지 확인하는 절차가 필요합니다.

개발자 5분 읽기

성능 최적화 실무

Core Web Vitals 를 마케터의 말로 옮기면

세 지표는 각각 한 문장으로 옮겨집니다. 언제 보이나, 읽는 중에 흔들리나, 눌렀을 때 반응하나 — 이 말로 옮기면 무엇을 요청할지가 보입니다.

마케터 3분 읽기

₩270,000 · 신청하기