중요한 느린 페이지는 홈페이지가 아니다

요약

상사가 웹사이트가 느리다고 말하면, 본능적으로 이미지를 압축하고 홈페이지에 사과하기 시작합니다. 더 유용한 행동은 실제로 먼저 빠르게 만들 가치가 있는 페이지를 결정하는 것입니다. 이 글은 한 가지 시나리오를 다룹니다: 중규모 B2B 사이트의 "속도 개선"을 요청받은 소규모 마케팅 팀. 현장 데이터로 Core Web Vitals를 측정하고, 비즈니스 영향에 따라 페이지를 선택하며, 저렴한 수정 이후에만 구조화 데이터를 추가하는 방법을 다룹니다. 그 결과는 비기술적 상사에게도 이해가 되는 짧고 방어 가능한 계획입니다.

웹사이트에서 가장 느린 페이지는 PageSpeed Insights가 지적하는 페이지가 아닙니다. 상사가 한 번도 열어보지 않은 페이지, 즉 유료 캠페인과 연결된 페이지나 잊혀진 제품 섹션에 묻혀 있는 페이지이며, 그 페이지가 실제로 이번 달 예산이 어떤 성과를 내는지를 결정합니다. 고위 관계자가 "사이트가 느리니 고쳐라"라고 말할 때, 그들은 웹사이트 속도 프로젝트가 필요하지 않습니다. 그들에게는 우선순위를 정하는 작업이 필요합니다.

우리 중 많은 사람이 겪어본 시나리오를 가정해 봅시다. 당신은 중규모 B2B 소프트웨어 회사의 마케팅 팀 전체입니다. 사이트에는 홈페이지, 블로그, 고객 센터, 그리고 특정 광고 캠페인과 연결된 다섯 개의 랜딩 페이지가 있습니다. 상사는 Core Web Vitals에 관한 기사를 읽었거나 고객 불만을 들었습니다. 지시는 분명합니다: 더 빠르게 만들라는 것입니다.

다음 한 시간 동안 어떻게 대응하느냐에 따라 다음 한 달을 이미지 압축으로 보낼지, 아니면 실제로 중요한 수치를 바꾸는 작업을 할지가 결정됩니다.

수익을 내는 페이지부터 시작하세요. 부끄러운 페이지가 아니라요.

원칙: 속도 작업에는 수익이 있으며, 그 수익은 트래픽과 전환 가치에 따라 달라집니다. 트래픽이 적지만 전환율이 높은 페이지는 홈페이지보다 비즈니스에 더 중요할 수 있습니다. 더 느리더라도 말이죠.

따라서 첫 번째 행동은 사이트맵이 아닌 분석 도구에서 페이지 목록을 만드는 것입니다. 어떤 페이지가 광고 클릭이라는 형태로 돈을 벌어들이나요? 출시 이후 손대지 않은 페이지는 어떤 것인가요? 이 시나리오에서 가장 중요한 랜딩 페이지—두 달 동안 운영된 유료 검색 광고 뒤에 있는 페이지—는 크고 최적화되지 않은 스크린샷으로 만들어졌습니다. 반면 홈페이지는 1년 전에 에이전시가 이미 최적화했습니다.

홈페이지부터 고치지 마세요. 돈을 버는 페이지를 고치세요. 그것은 기술적 선택이 아니라 비즈니스 선택입니다. 전체 기술 감사가 올바른 대응처럼 보인다면 잠시 저항하세요. 감사는 목록을 만들어 줄 뿐, 어떤 항목부터 시작할지 알려주지 않습니다. 제대로 범위를 정한 기술 SEO 감사는 결정 도구이지, 당황한 반응이 아닙니다.

소수의 페이지가 대부분의 트래픽과 전환을 생성하고, 나머지는 정보 제공용이거나 잔재인 경우가 많습니다. 그렇다고 느린 정보 페이지를 영원히 무시해야 한다는 뜻은 아닙니다. 수익과 직접 연결된 페이지 이후에 순서를 정하면 된다는 뜻입니다. 홈페이지가 전부 느릴 수 있지만, 비즈니스 목표가 리드 생성이라면 홈페이지 방문은 시작점에 불과합니다. 실제 전환이 일어나는 곳은 랜딩 페이지입니다.

"빠름"을 "측정된 빠름"과 "체감 빠름"으로 나누기

두 번째 단계는 성능 테스트가 말하는 것과 실제 사용자가 경험하는 것을 분리하는 것입니다. Google의 Core Web Vitals 문서에는 검색 순위에 영향을 주는 세 가지 지표가 있습니다: Largest Contentful Paint(로딩), Interaction to Next Paint(반응성), Cumulative Layout Shift(시각적 안정성). 이 지표들이 중요한 이유는 사용자가 페이지를 실제로 사용할 수 있는지에 영향을 주는 순간을 추적하기 때문입니다.

시나리오에서는 랜딩 페이지를 성능 테스트 도구로 열면 합리적인 점수가 나옵니다. 그러나 Google Search Console의 현장 데이터(방문자의 실제 경험을 반영)와 비교하면 그 페이지가 자주 느린 것으로 나타납니다. 그것이 중요한 신호입니다. 실험실 테스트는 변경 후 이전과 이후를 비교하는 데 여전히 유용합니다. 하지만 현장 데이터는 다양한 기기와 연결 환경에서 광고를 클릭한 사람들에게 있어 사실의 기준입니다.

이렇게 하지 말고	이렇게 시작하세요	이유
PageSpeed 점수를 하나의 숫자로 보기	Core Web Vitals 현장 데이터	현장 데이터는 테스트 서버가 아닌 실제 사용자에게서 나옵니다
"사이트가 느리다"	비즈니스 목표를 지원하는 페이지는 무엇인가	빠른 무용지물 페이지는 리드를 생성하지 않습니다
CMS 재구축	이미지 압축 및 스크립트 정리	위험 부담이 적은 수정이 대부분의 이점을 제공합니다

나중에 더 깊이 참조하고 싶다면 Core Web Vitals 가이드가 각 지표를 안내해 줄 수 있습니다. 하지만 지금은 계획을 세우기에 충분한 정도만 있으면 됩니다. 핵심은 특정 페이지에서 실제로 문제를 일으키는 세 가지 지표 중 무엇인지 밝히는 것입니다. 텍스트가 늦게 나타나면 이미지와 서버 응답을 살펴보세요. 버튼이 버벅거리면 긴 JavaScript 작업을 살펴보세요. 레이아웃이 튀면 광고와 임베드를 위해 예약된 공간을 살펴보세요. 그 미묘한 차이가 무작위 최적화와 목표 지향적 수정을 구분합니다.

비싼 것보다 싼 것부터 고치세요

세 번째 원칙: 성능 프로젝트가 재설계로 비대해지지 않게 하세요. 실제 사용자 경험을 개선하는 대부분의 개선은 화려하지 않고 저렴합니다.

랜딩 페이지를 보고 명백한 문제를 찾아보세요. 이미지는 원본 해상도의 스크린샷입니다. 페이지에 아무도 더 이상 식별할 수 없는 타사 스크립트가 있습니다. 웹 폰트가 텍스트 렌더링을 차단하고 있습니다. 이는 익숙한 문제들입니다.

완벽한 세계라면 현대적인 프레임워크로 페이지를 다시 작성하는 데 일주일을 보낼 것입니다. 실제로는 반나절 작업으로 시작합니다: 이미지 압축, 사용하지 않는 스크립트 지연, 히어로 이미지 사전 로드. 이 변경 사항은 오후에 테스트할 수 있고 승인 위원회가 필요 없습니다.

주의: 속도가 항상 이렇게 단순하지는 않습니다. 일부 페이지는 서버, 데이터베이스, 또는 통제할 수 없는 타사 종속성 때문에 느립니다. 그러나 저렴한 수정을 확인하지 않았다면 비싼 수정을 정당화할 수 없습니다. 많은 팀이 스크린샷을 압축하지 않았기 때문에 재구축에 예산을 낭비합니다. 여기서 겸손함을 유지해야 합니다: 성능 점수는 증상이지 진단이 아닙니다. 저렴한 수정 자체가 진단입니다. 이미지를 압축한 후에는 병목 현상이 콘텐츠 때문인지 인프라 때문인지 알 수 있습니다.

코드를 만지는 김에 구조화 데이터 추가하기

이 부분이 상사를 놀라게 합니다. 저렴한 수정을 마친 후에는 이미 페이지 내부에 들어와 있습니다. 속도와 전혀 상관없는 무언가를 추가하기에 딱 좋은 시점입니다: 구조화 데이터.

구조화 데이터는 검색 엔진이 페이지 내용을 이해하도록 돕는 마크업입니다. 더 풍부한 검색 결과와 더 나은 가시성으로 이어질 수 있는 HTML이며, 검색이 AI 생성 답변으로 전환됨에 따라 더욱 관련성이 높아지고 있습니다. 소규모 팀에게 이는 충분히 활용되지 않는 레버입니다. 새 콘텐츠를 작성할 필요가 없기 때문입니다. 이미 존재하는 것에 레이블을 붙이는 것입니다.

시나리오에서는 랜딩 페이지에 서비스 지향 스키마를 추가합니다. 정확한 유형은 페이지가 무엇에 관한 것인지에 따라 다릅니다: 서비스 페이지, 기사, 제품. 모든 유형을 한 번에 추가할 필요는 없습니다. 하나를 신중하게 추가하는 것이 열 개를 엉성하게 추가하는 것보다 낫습니다. 보장된 결과는 없습니다. 표시할 내용은 Google이 결정합니다. 그러나 위험은 낮고 잠재적 상승 여력은 실재합니다. 더 깊이 들어가기로 결정했다면 구조화 데이터 구현 가이드가 실용적인 단계를 다룹니다.

수정 사항을 "돈을 벌었는가?"로 번역하기

어려운 부분은 기술 작업이 아닙니다. 비기술적인 상사에게 그것을 제시하는 방식입니다.

상사는 한 가지만 요청했습니다: 사이트를 더 빠르게 만들라는 것. "랜딩 페이지의 LCP를 개선했습니다"라고 말하면 멍한 표정을 받을 수 있습니다. 대신 작업을 비즈니스 결과로 번역하세요.

이 시나리오에서 랜딩 페이지는 유료 캠페인의 목적지입니다. 1초의 지연은 방문자가 콜투액션이 나타나기 전에 이탈할 수 있는 1초입니다. 그래서 이렇게 설명합니다: 돈이 오가는 페이지에서 명백한 마찰을 제거했습니다. 특정 순위 상승을 약속할 수는 없습니다—그런 사람은 추측하는 것입니다—하지만 합리적이고 정직한 주장은 할 수 있습니다. 또한 상사가 이미 이해하는 예산과 연결 지을 수 있습니다. 동일한 광고 비용이 방문을 구매합니다. 차이는 그 방문이 리드가 될 기회가 있는지입니다.

간단한 월간 보고서가 전문용어로 가득한 대시보드보다 효과적입니다. 세 가지를 보여주세요: 어떤 페이지를 선택했는지, 어떤 지표를 측정했는지, 무엇을 변경했는지. 지표가 개선되면 그것은 검증입니다. 개선되지 않아도 재평가할 명확한 실험이 있습니다. 한 달에 한 번 단일 점수를 쫓지 마세요. Core Web Vitals는 트래픽 구성, 기기 유형, 심지어 지리적 지역에 따라 변동합니다. 숫자가 아닌 추세를 보고하세요.

다음 월요일에 할 일

시나리오에서 얻은 교훈: "웹사이트"를 고치는 것이 아닙니다. 데이터에 기반해 특정 페이지를 고치고, 일회성 프로젝트가 아닌 반복 가능한 프로세스를 만드는 것입니다. 권한 있는 사람이 "더 빠르게 만들라"고 말할 때 가장 유용한 대답은 한 가지 명확한 질문입니다: 어떤 페이지를, 누구를 위해?

그런 다음 현장 데이터를 측정하고, 저렴한 것부터 고치고, 이미 코드를 만지는 중이라면 구조화 데이터를 추가하고, 평범한 언어로 보고하세요. 결과가 극적이지 않을 수 있습니다. 그러나 어떤 페이지가 빨라졌는지, 왜 그 페이지를 선택했는지, 다음에 무엇을 할지 정확히 알게 됩니다. 그것은 속도 점수로 시작해 아무도 이해하지 못하는 재설계로 끝난 모호한 프로젝트보다 더 나은 결과물입니다.