Power hour · gmbapi

통화 한 번으로 LCP 5초에서 1.9초 단축

새 Next.js 사이트를 구축한 로컬 SEO 기업. 데스크톱에서는 빠르지만 모바일에서는 느렸습니다.

1.9초CrUX LCP, 기존 5초
150ms모바일 INP, 기존 220ms
700ms서버 응답, 기존 3초
0.00CrUX CLS, 기존 0.08
고객사gmbapi, 로컬 SEO 소프트웨어
플랫폼React, Next.js, headless CMS
서비스Power hour, 2026년 8월
고객사

데스크톱은 통과하고 모바일은 실패한 신규 사이트

gmbapi는 로컬 SEO 소프트웨어 기업이며, 실력도 탄탄한 곳입니다. 2026년 7월, WordPress에서 React, Next.js, headless CMS 기반 새 사이트로 이전했습니다. 데스크톱은 Core Web Vitals를 통과했습니다. 모바일에서는 LCP, FCP, INP가 통과하지 못했습니다.

이 회사를 운영하는 Michel van Luijtelaar와는 2021년부터 알고 지냈습니다. 2023년과 2025년에 WordPress 사이트를 봐달라고 요청해 왔고, 2026년 7월에는 새 사이트를 가지고 다시 찾아왔습니다.

gmbapi.com homepage
발견한 문제와 조치 내용

자잘한 문제들의 누적

결정적인 단 하나의 문제는 없었습니다. 원래 그런 경우는 거의 없습니다. DevTools로 모바일 페이지 로드를 기록하고, 첫 바이트부터 LCP까지 트레이스를 살펴보며 통화 중에 바로바로 수정했습니다.

문제점
조치 내용
TTFB
서버가 첫 바이트를 반환하기까지 3초가 걸렸습니다. 모든 페이지가 요청마다 렌더링되며 headless CMS에서 실시간으로 콘텐츠를 가져왔고, 캐시 헤더가 no-store로 설정되어 CDN이 HTML을 전혀 저장하지 못했습니다.
페이지를 ISR 기반 정적 렌더링으로 전환하고 CMS 호출을 캐싱했으며, CDN이 HTML을 저장하도록 헤더를 수정했습니다. 서버 응답 속도가 700ms로 줄었고, 다른 곳은 손대기도 전에 FCP와 LCP에서 그만큼이 바로 줄어들었습니다.
LCPINP
head의 태그와 애널리틱스, 페이지 상단의 서드파티 위젯, 서버가 렌더링해도 충분한 컴포넌트를 브라우저에서 렌더링하고 있었습니다. 모두 실제로 쓰이는 JavaScript였지만, 실행 시점이 너무 빨랐습니다.
태그와 위젯은 페이지가 표시될 때까지 실행을 미루고, 해당 컴포넌트는 서버에서 렌더링해 내려주도록 했습니다.
LCP
히어로 이미지에 lazy loading이 적용되어 있었습니다. priority 속성 없이 next/image를 거쳤고, CMS 블록은 모든 이미지에 loading="lazy"를 설정했습니다. 히어로가 CSS 배경 이미지로 되어 있던 페이지에서는 브라우저가 이미지를 너무 늦게 발견했습니다.
히어로 이미지에 priority와 fetchpriority="high"를 적용했고, CMS 블록에서는 첫 번째 이미지를 예외 처리했습니다. CSS 배경 이미지는 preload를 적용한 실제 img 태그로 변경했습니다. 이 조치들을 합쳐 LCP를 120ms 단축했습니다.
LCP
첫 화면을 띄우는 데 30kB와 0.5kB짜리 스타일시트 2개를 기다려야 했습니다.
두 스타일시트를 15kB로 다시 작성했고, 여기서 LCP를 추가로 100ms 줄였습니다.
LCP
그 자체로는 크지 않은 자잘한 문제들이 많았습니다.
트레이스를 계속 확인하며 통화 중에 하나씩 수정했습니다.
CrUX 데이터

누구나 바라는 차트입니다. 모바일 방문자의 LCP는 가장 느렸던 5.6초에서 2.0초로 줄었고, 서버 응답은 4.2초에서 0.8초로 줄었습니다. 두 그래프 선이 내려오는 데는 몇 주가 걸립니다. 각 지점이 28일 집계 기간 동안의 느렸던 날들을 여전히 포함하기 때문입니다. 8월 이후 LCP는 1.9초에서 2.2초 사이를 유지하고 있습니다.

2.5초4.0초2월3월4월5월6월7월8월9월10월3.8초2.0초5.6초모바일 LCP, p75
0.8초1.8초2월3월4월5월6월7월8월9월10월2.0초0.76초4.2초모바일 TTFB, p75
2026년 1월부터 10월까지의 gmbapi.com CrUX 데이터. 각 지점은 해당 날짜 이전 28일간의 집계입니다. 초록색은 좋음, 주황색은 개선 필요, 빨간색은 나쁨입니다.
후속 조치

통화 후 페이지별, 릴리스별로 모바일 방문자 데이터를 확인할 수 있도록 CoreDash 접근 권한을 제공했고, 작업 목록도 점검했습니다. 상단에 정리한 수치는 Google의 자체 field data인 CrUX 측정값입니다.

개발자가 직접 통화에 참여하고 수정 작업이 간단하다면 1시간으로 충분합니다. 규모가 더 큰 작업은 가장 중요한 것부터 메모에 정리합니다.

배운 점

고객사의 예상은 미사용 JavaScript였습니다

새로 구축한 React 사이트라면 충분히 합리적인 추측입니다. 하지만 트레이스 분석 결과 가장 큰 문제는 서버 응답과 lazy loading된 히어로 이미지였습니다.

새 프레임워크를 쓴다고 저절로 빨라지지는 않습니다

Next.js로 막 이전한 상태였고, 프레임워크의 기본 동작이 그대로 적용되었습니다. next/image는 priority를 지정하지 않으면 모든 이미지를 lazy loading하는데, 히어로 이미지 역시 그중 하나였습니다.

Arjen Karel

개발팀과 함께하는 1시간 통화: €350

담당 개발자와 함께 가장 느린 페이지를 준비하세요. 함께 살펴보며 통화하는 동안 수정할 수 있는 것은 바로 해결합니다.

Power hour 예약하기

더 많은 결과는 고객사 페이지에서 확인할 수 있습니다.

gmbapi: 통화 한 번으로 LCP 5초에서 1.9초 단축 Core Web Vitals gmbapi: 통화 한 번으로 LCP 5초에서 1.9초 단축