Core Web Vitals 최적화 가이드: 사업 홈페이지와 SaaS 첫 화면의 LCP·INP·CLS 개선 기준 > 인사이트

본문 바로가기

인사이트

#프론트엔드

Core Web Vitals 최적화 가이드: 사업 홈페이지와 SaaS 첫 화면의 LCP·INP·CLS 개선 기준

결론부터 말하면, Core Web Vitals 최적화의 목표는 PageSpeed Insights 100점이 아닙니다. 사업 홈페이지, SaaS 랜딩, 가입·문의·결제 화면에서는 ‘가장 많은 사용자가 실제로 겪는 첫 화면 지연, 클릭 반응 지연, 화면 흔들림’을 줄이는 것이 목표입니다. 개발 예산이 제한되어 있다면 모든 URL을 한 번에 고치기보다 모바일 유입이 많은 첫 화면, 가격·문의 페이지, 가입 폼, 결제 또는 데모 신청 화면, 로그인 직후 대시보드처럼 매출과 신뢰에 가까운 화면부터 봐야 합니다.

우선순위는 단순합니다. Search Console에서 Poor로 잡힌 URL 그룹 중 사업 전환에 가까운 화면을 고르고, 그 화면에서 LCP·INP·CLS 중 가장 나쁜 지표를 먼저 개선합니다. 랜딩 첫 화면이 늦게 보이면 LCP, 버튼·탭·필터·폼 입력이 늦게 반응하면 INP, 배너·이미지·폰트 때문에 화면이 밀리면 CLS가 1순위입니다.

노트북 화면에 PageSpeed Insights와 SaaS 랜딩 첫 화면 성능 지표가 함께 표시된 장면
Core Web Vitals는 개발 점수표가 아니라 고객이 첫 화면을 신뢰하는 데 걸리는 시간을 보여주는 운영 지표입니다.
Core Web Vitals는 개발 점수표가 아니라 고객이 첫 화면을 신뢰하는 데 걸리는 시간을 보여주는 운영 지표입니다.

1. Core Web Vitals는 성능 점수가 아니라 화면 품질 기준이다

Core Web Vitals는 현재 LCP, INP, CLS 세 가지 지표로 구성됩니다. LCP는 가장 중요한 콘텐츠가 화면에 보이는 시간, INP는 사용자의 클릭·탭·키 입력 후 다음 화면 변화가 나타나는 응답성, CLS는 예상치 못한 레이아웃 이동 정도를 봅니다. 쉽게 말해 ‘보이는가’, ‘반응하는가’, ‘흔들리지 않는가’를 측정합니다.

지표사용자가 느끼는 문제Good 기준사업 화면에서 자주 터지는 위치
LCP첫 화면의 핵심 이미지·문구·콘텐츠가 늦게 보임2.5초 이하홈 히어로, 제품 소개, 가격 페이지 상단, 블로그 대표 이미지
INP클릭했는데 메뉴·폼·필터·저장 버튼이 늦게 반응함200ms 이하가입 폼, 견적 문의, 결제, SaaS 대시보드, 관리자 화면
CLS화면이 밀려 잘못 클릭하거나 신뢰감이 떨어짐0.1 이하배너, 팝업, 폰트 교체, 이미지·iframe, 광고·채팅 위젯

중요한 점은 이 기준이 ‘한 번 실행한 테스트 점수’가 아니라 실제 사용자 경험을 기준으로 해석된다는 것입니다. 공식 문서에서도 Core Web Vitals 평가는 모바일과 데스크톱을 나누고, 75번째 백분위 기준으로 다룹니다. 즉 평균 사용자가 아니라 느린 기기와 불안정한 네트워크를 포함한 상당수 사용자가 괜찮은 경험을 해야 통과에 가까워집니다.

운영 관점에서 좋은 기준은 ‘우리 사이트가 100점인가’가 아니라 ‘핵심 고객 여정의 모바일 p75 경험이 Good 기준에 들어오는가’입니다.

2. PageSpeed Insights와 Search Console은 서로 다른 질문에 답한다

대표나 PM이 가장 많이 혼동하는 부분이 여기입니다. PageSpeed Insights를 열면 상단에는 실제 사용자 데이터가 보이고, 하단에는 Lighthouse 기반 랩 테스트 결과가 나옵니다. Search Console의 Core Web Vitals 보고서는 실제 사용자 데이터를 기반으로 URL 그룹을 묶어 보여줍니다. 반면 Lighthouse 점수는 통제된 환경에서 특정 URL을 한 번 테스트한 진단 결과에 가깝습니다.

도구어떤 질문에 답하나의사결정에 쓰는 법
Search Console Core Web Vitals실제 사용자 기준으로 어떤 URL 그룹이 Poor 또는 Need improvement인가사업 우선순위와 결합해 개선 대상 URL 그룹을 정한다
PageSpeed Insights 필드 데이터해당 URL 또는 Origin의 실제 사용자 경험이 어떤 분포인가모바일·데스크톱별 LCP·INP·CLS 상태를 확인한다
PageSpeed Insights 랩 진단현재 테스트 조건에서 어떤 리소스와 코드가 병목 후보인가이미지, CSS, JS, 폰트, 서버 응답, 렌더 차단 원인을 찾는다
Chrome DevTools Performance어떤 스크립트·이벤트·렌더 작업이 실제로 느린가개발자가 LCP 요소, 긴 작업, 이벤트 핸들러를 재현해 수정한다
실험실 테스트 화면과 실제 사용자 데이터 대시보드가 나란히 비교된 모니터
Lighthouse 점수와 실제 사용자 경험 데이터는 서로 다른 질문에 답합니다.
Lighthouse 점수와 실제 사용자 경험 데이터는 서로 다른 질문에 답합니다.

따라서 개발팀에 ‘PageSpeed 점수 100 만들어 주세요’라고 요청하면 작업 범위가 흐려집니다. 더 좋은 요청은 ‘모바일 Search Console에서 가격 페이지 그룹의 LCP가 Poor입니다. PageSpeed Insights에서 LCP 요소가 히어로 이미지로 잡히는지 확인하고, 이미지 발견 시점·파일 크기·렌더 지연을 나눠 개선안을 주세요’입니다.

3. SEO와 전환율에 어떤 영향을 주나

SEO 관점에서는 과장하지 않는 것이 중요합니다. Google은 Core Web Vitals를 페이지 경험과 관련된 신호로 다루며 좋은 사용자 경험을 권장합니다. 하지만 Core Web Vitals 점수가 좋다고 해서 검색 순위 상위 노출이 보장되지는 않습니다. 검색에서는 콘텐츠의 관련성, 신뢰성, 검색 의도 충족, 내부 구조, 색인 상태 등 여러 요소가 함께 작동합니다. 그래서 Core Web Vitals는 ‘부실한 콘텐츠를 상위로 올리는 버튼’이 아니라, 경쟁 페이지와 비교했을 때 사용자가 머무를 수 있는 기본 품질을 맞추는 작업으로 보는 편이 정확합니다.

전환율 관점에서는 더 직접적으로 해석할 수 있습니다. 광고를 클릭한 사용자가 랜딩 첫 화면을 기다리다 나가면 LCP 문제가 전환 손실로 이어질 수 있습니다. 문의 버튼을 눌렀는데 모달이 늦게 열리거나 폼 입력 중 검증 스크립트가 멈추면 INP 문제가 됩니다. 가격 영역 위에 늦게 뜬 배너가 CTA를 밀어 사용자가 잘못 누르면 CLS 문제입니다. 단, 특정 수치를 모든 사이트에 그대로 적용하면 안 됩니다. 업종, 트래픽 품질, 가격대, 폼 길이, 브랜드 인지도에 따라 성능 개선의 전환 효과는 달라집니다.

지표전환 여정에서의 의미같이 봐야 할 비즈니스 지표
LCP광고·검색 유입 후 첫 신뢰 형성 시간랜딩 이탈률, 스크롤 시작률, CTA 노출 전 이탈
INP사용자가 행동을 시작한 뒤 서비스가 반응하는 속도폼 시작 후 완료율, 버튼 재클릭률, 결제 실패 전 이탈
CLS화면 안정성과 조작 신뢰감잘못된 클릭, 입력 오류, 모달 닫기, 모바일 이탈

4. 무엇을 먼저 고칠까: URL 그룹과 고객 여정으로 결정한다

Core Web Vitals 최적화는 전체 사이트 평균을 낮추는 작업이 아닙니다. 특히 스타트업, 지원사업 MVP, B2B SaaS 랜딩처럼 개발 리소스가 제한된 조직은 고객 여정 기준으로 잘라야 합니다. ‘가장 많이 방문되는 페이지’와 ‘가장 돈에 가까운 페이지’가 다를 수 있기 때문입니다.

PM과 개발자가 LCP INP CLS 개선 우선순위를 보드에 정리하는 회의 장면
먼저 고칠 화면을 정하지 않으면 성능 개선은 점수 경쟁으로 흐르기 쉽습니다.
먼저 고칠 화면을 정하지 않으면 성능 개선은 점수 경쟁으로 흐르기 쉽습니다.
화면 유형우선 확인 지표대표 원인우선 작업
사업 홈페이지 홈LCP, CLS큰 히어로 이미지, 늦게 로드되는 폰트, 상단 애니메이션히어로 이미지 최적화, preload, 폰트 전략, 상단 레이아웃 고정
SaaS 랜딩·가격 페이지LCP, CLS가격 카드·FAQ·배너가 늦게 밀림, 이미지 과다첫 화면 콘텐츠 우선 로드, 카드 높이 예약, 이미지 크기 명시
문의·가입 폼INP, CLS무거운 검증 로직, 주소 검색·채팅·CRM 스크립트, 오류 메시지 밀림이벤트 핸들러 경량화, 비동기 검증, 오류 영역 예약
결제·예약 화면INP, CLS외부 결제 위젯, 약관 모달, 쿠폰 계산, 재렌더링서드파티 로딩 순서 조정, 계산 분리, 버튼 상태 즉시 표시
로그인 후 대시보드INP, LCP큰 JS 번들, 차트·테이블 초기 렌더, 권한 조회 지연코드 스플리팅, 데이터 페칭 분리, 가상화, 스켈레톤 설계

이미지가 많은 홈페이지라면 먼저 반응형 이미지 최적화 가이드의 기준처럼 화면 크기별 이미지 제공, 적절한 포맷, 첫 화면 이미지의 로딩 우선순위를 점검하는 것이 좋습니다. 반대로 문의·가입 화면에서 이탈이 크다면 성능과 함께 폼 UX 최적화 가이드의 입력 흐름, 오류 메시지, 버튼 상태까지 같이 봐야 합니다.

5. LCP 개선: 이미지 압축보다 먼저 LCP 요소를 찾아야 한다

LCP가 나쁘다고 해서 항상 이미지 압축부터 할 필요는 없습니다. 먼저 PageSpeed Insights나 DevTools에서 실제 LCP 요소가 무엇인지 확인해야 합니다. 히어로 이미지일 수도 있고, 큰 제목 텍스트일 수도 있으며, 배경 이미지나 동적으로 삽입된 카드일 수도 있습니다.

LCP는 크게 네 구간으로 나눠 봐야 합니다. 서버가 HTML 첫 바이트를 늦게 보내는지, 브라우저가 LCP 리소스를 늦게 발견하는지, 리소스 다운로드가 오래 걸리는지, 리소스는 받았는데 자바스크립트나 CSS 때문에 렌더가 늦어지는지입니다. 이 구간을 나누지 않으면 이미지를 압축해도 실제 LCP는 거의 줄지 않는 상황이 생깁니다.

  • 첫 화면 이미지는 lazy loading 대상에서 제외합니다. 히어로 이미지가 LCP 요소라면 브라우저가 가능한 한 빨리 발견해야 합니다.
  • 이미지의 width, height 또는 aspect-ratio를 명시합니다. LCP와 CLS를 동시에 다룹니다.
  • WebP, AVIF, 적절한 JPEG 품질을 비교합니다. 단순히 용량만 줄이다가 품질이 깨지면 브랜드 신뢰가 떨어질 수 있습니다.
  • CSS 배경 이미지라면 preload와 우선순위를 검토합니다. CSS 파일을 받아야 이미지를 알 수 있는 구조는 LCP 발견이 늦어질 수 있습니다.
  • 폰트가 첫 화면 문구의 렌더를 막는지 확인합니다. 브랜드 폰트가 중요하더라도 첫 화면 텍스트가 보이지 않으면 신뢰 형성에 손해입니다.
  • 서버 응답과 캐싱을 같이 봅니다. 정적 랜딩은 CDN, 캐시, SSG·ISR 같은 전략이 LCP에 영향을 줄 수 있습니다.

Next.js 기반 랜딩이라면 메타데이터, 렌더링 방식, 정적 생성, 이미지 컴포넌트 사용 방식이 함께 얽힙니다. 검색 노출 구조까지 함께 점검해야 한다면 Next.js App Router SEO 가이드와 연결해 보는 것이 실무적으로 좋습니다.

6. INP 개선: 2026년에는 이미지보다 자바스크립트를 의심해야 하는 순간이 많다

INP는 2024년 3월 FID를 대체해 Core Web Vitals의 응답성 지표가 되었습니다. FID가 첫 입력의 지연을 좁게 봤다면, INP는 페이지 방문 중 발생하는 여러 상호작용의 응답성을 더 넓게 봅니다. 그래서 ‘첫 화면은 빨리 떴는데 버튼이 늦게 눌린다’, ‘필터를 바꾸면 화면이 멈춘다’, ‘모바일 메뉴가 한 박자 늦게 열린다’ 같은 문제가 더 잘 드러납니다.

INP가 나쁜 화면에서는 이미지 압축보다 자바스크립트 실행, 긴 작업, 이벤트 핸들러, 프레임워크 재렌더링, 서드파티 스크립트가 원인일 가능성이 큽니다. 특히 SaaS 대시보드, 관리자 화면, 견적 계산기, 검색 필터, AI 챗봇, CRM 연동 폼처럼 화면 안에서 사용자가 계속 조작하는 기능은 INP를 별도 품질 기준으로 봐야 합니다.

  • 초기 JS 번들을 줄입니다. 첫 화면에 필요 없는 차트, 에디터, 지도, 결제, 채팅, 관리자 기능은 코드 스플리팅합니다.
  • 이벤트 핸들러 안의 작업을 줄입니다. 클릭 한 번에 대량 계산, DOM 측정, 상태 업데이트, API 호출 준비를 모두 처리하면 지연이 커집니다.
  • 긴 작업을 쪼갭니다. 메인 스레드를 오래 막는 작업은 사용자의 다음 입력을 기다리게 만듭니다.
  • 무거운 계산은 Web Worker나 서버로 이동할 수 있는지 검토합니다. 견적 계산, 대량 필터링, 문서 파싱 같은 작업이 후보입니다.
  • 상태 업데이트 범위를 줄입니다. 버튼 하나를 눌렀는데 전체 페이지가 재렌더링되는 구조는 SaaS 화면에서 자주 문제를 만듭니다.
  • 서드파티 스크립트 로딩 순서를 조정합니다. 태그 매니저, 히트맵, 채팅, 광고, CRM 스크립트는 매출 분석에 필요할 수 있지만 첫 입력을 막아서는 안 됩니다.
  • 사용자 피드백을 즉시 표시합니다. 저장 버튼 클릭 후 실제 API 처리가 오래 걸리더라도 버튼 상태, 로딩 인디케이터, 낙관적 UI를 통해 반응성을 체감시킬 수 있습니다.

정부지원사업으로 만든 MVP에서도 INP는 중요합니다. 시연용 기능이 많아질수록 ‘데모에서는 보이지만 실제로 누르면 늦는’ 화면이 생기기 쉽습니다. 초기 MVP라면 모든 기능을 고급 최적화할 필요는 없지만, 투자자·심사위원·초기 고객이 눌러볼 핵심 버튼과 폼은 반드시 빠르게 반응해야 합니다.

7. CLS 개선: 화면이 흔들리면 사용자는 사이트를 덜 믿는다

CLS는 기술적으로는 레이아웃 이동 점수지만, 사업적으로는 조작 신뢰의 문제입니다. 모바일에서 CTA 버튼을 누르려는 순간 상단 배너가 늦게 삽입되어 버튼이 밀리면 사용자는 잘못된 버튼을 누르거나 사이트가 불안정하다고 느낍니다. 결제·예약·상담 신청 화면에서는 이 작은 흔들림이 이탈로 이어질 수 있습니다.

  • 이미지와 영상 영역의 크기를 미리 예약합니다. width, height, aspect-ratio 없이 이미지를 넣으면 로드 후 주변 콘텐츠를 밀 수 있습니다.
  • 광고, 배너, 쿠키 알림, 프로모션 바의 공간을 사전에 확보합니다. 상단에 늦게 삽입되는 요소는 CLS의 대표 원인입니다.
  • 폰트 교체로 인한 줄바꿈 변화를 줄입니다. fallback 폰트와 웹폰트의 크기 차이가 크면 텍스트 블록 높이가 바뀝니다.
  • 오류 메시지와 도움말 영역을 설계 단계에서 확보합니다. 폼 오류가 나타날 때 입력 필드 전체가 밀리면 사용자는 흐름을 잃습니다.
  • 스켈레톤 UI는 실제 콘텐츠와 같은 크기에 가깝게 만듭니다. 예쁜 스켈레톤이 실제 카드보다 작거나 크면 로딩 후 다시 흔들립니다.
  • 스크롤 위쪽에 동적 콘텐츠를 무심코 삽입하지 않습니다. 추천 배너, 앱 설치 유도, 채팅 안내가 본문을 아래로 밀지 않게 해야 합니다.

CLS는 상대적으로 빠르게 개선되는 경우도 많습니다. 이미지 크기 명시, 배너 영역 예약, 폰트 전략 조정처럼 설계 기준을 잡으면 다른 페이지에도 반복 적용할 수 있기 때문입니다. 다만 디자인팀이 ‘첫 화면을 더 풍성하게’ 만들기 위해 새 배너를 계속 추가하는 조직이라면 배포 전 CLS 체크를 QA 항목에 넣어야 합니다.

8. 개발팀에는 이렇게 요청해야 한다

성능 개선 요청이 실패하는 가장 흔한 이유는 요청이 추상적이기 때문입니다. ‘홈페이지가 느립니다’, ‘PageSpeed 점수를 올려 주세요’, ‘SEO에 안 좋다는데 고쳐 주세요’만으로는 개발팀이 어디까지 손대야 하는지 알기 어렵습니다. 개발 요청서는 최소한 URL, 지표, 기기, 재현 조건, 완료 기준을 포함해야 합니다.

나쁜 요청좋은 요청완료 기준 예시
사이트가 느려요모바일 홈 URL의 LCP 요소를 확인하고 2.5초 이하를 목표로 개선안을 주세요배포 후 PageSpeed 필드 또는 RUM에서 LCP p75 개선 확인
이미지 줄여 주세요첫 화면 히어로 이미지가 LCP인지 확인하고 srcset, preload, fetch priority, lazy 제외 여부를 점검해 주세요LCP 리소스 발견 지연 감소, 품질 저하 없는 이미지 용량 감소
버튼이 느려요가입 폼 제출 버튼 클릭 시 INP 후보 긴 작업을 DevTools Performance에서 캡처해 주세요이벤트 처리 시간 감소, 중복 클릭 방지와 즉시 피드백 구현
화면이 밀려요모바일 가격 페이지에서 프로모션 배너와 폰트 로딩으로 인한 CLS 발생 지점을 찾아 주세요이미지·배너·오류 영역 크기 예약, CLS Good 기준 통과
Core Web Vitals 개선 체크리스트와 코드 에디터, 모바일 테스트 기기가 놓인 작업 책상
완료 기준이 있어야 성능 개선이 배포 후에도 유지됩니다.
완료 기준이 있어야 성능 개선이 배포 후에도 유지됩니다.

9. 현실적인 2주~6주 개선 로드맵

Core Web Vitals 개선은 사이트 규모와 코드 상태에 따라 범위가 크게 달라집니다. 외주로 만든 홈페이지, 오래된 워드프레스 테마, 빠르게 붙인 SaaS 관리자 화면, 여러 태그가 누적된 랜딩은 같은 진단으로 시작해도 해결 방식이 다릅니다. 다만 작은 팀이라면 다음 순서가 현실적입니다.

단계기간산출물주의점
진단2~4일핵심 URL 목록, 모바일·데스크톱 지표, LCP 요소, INP 후보 상호작용, CLS 발생 지점홈만 보지 말고 가격·문의·가입·대시보드를 포함한다
빠른 개선1~2주이미지 크기·포맷·우선순위, 폰트 로딩, 배너 공간 예약, 불필요한 초기 스크립트 지연시각 품질과 추적 기능을 무작정 제거하지 않는다
구조 개선2~4주번들 분리, 렌더링 전략 조정, 컴포넌트 재렌더링 축소, API·서버 응답 개선프론트엔드만으로 해결되지 않는 TTFB와 데이터 페칭을 분리한다
운영화상시배포 전 성능 체크리스트, RUM 또는 주기적 PSI 기록, 변경 전후 비교 리포트한 번 좋아진 점수도 새 태그와 디자인 변경으로 다시 나빠질 수 있다

AgentMit은 이런 작업을 ‘점수 올리기’가 아니라 핵심 화면 품질 개선으로 접근합니다. BizMit 기반 SaaS, AI 서비스 개발, 자동화 대시보드, 관리자 화면, 정부지원사업 MVP처럼 화면 수는 많지 않아도 고객 신뢰가 중요한 서비스라면, 먼저 전환 여정을 정하고 LCP·INP·CLS가 매출 가까운 화면에서 어떻게 나타나는지부터 봅니다. 그다음 이미지·폰트·컴포넌트·상태 관리·서드파티 스크립트·배포 환경을 함께 정리하는 편이 시행착오가 적습니다.

10. 최종 체크리스트: 오늘 바로 확인할 것

  • Search Console에서 모바일과 데스크톱을 나눠 Poor URL 그룹을 확인했는가?
  • 해당 URL 그룹이 실제 매출·문의·가입 여정과 가까운가?
  • PageSpeed Insights에서 필드 데이터와 랩 데이터를 구분해 읽었는가?
  • LCP 요소가 무엇인지 스크린샷과 함께 확인했는가?
  • 첫 화면 이미지를 lazy load하고 있지는 않은가?
  • 상단 배너, 폰트, 이미지, iframe의 공간이 미리 예약되어 있는가?
  • 문의·가입·결제·필터 버튼의 느린 상호작용을 DevTools에서 재현했는가?
  • 태그 매니저, 채팅, 히트맵, CRM, 광고 스크립트가 첫 입력을 막고 있지는 않은가?
  • 배포 후 확인할 완료 기준을 p75 LCP·INP·CLS 또는 핵심 행동 지표로 정의했는가?
  • 새 랜딩, 새 배너, 새 폰트, 새 분석 태그를 추가할 때 성능 QA를 반복할 체계가 있는가?

FAQ

Q1. PageSpeed Insights 점수 100점을 꼭 만들어야 하나요?

대부분의 사업 홈페이지와 SaaS에서는 100점 자체보다 핵심 전환 화면의 실제 사용자 필드 데이터가 Good 기준을 통과하는지가 더 중요합니다. 특히 모바일 LCP, 가입·문의·결제 화면의 INP, 첫 화면 CLS를 우선 확인해야 합니다.

Q2. LCP, INP, CLS 중 무엇을 먼저 개선해야 하나요?

Search Console에서 Poor로 잡힌 지표 중 매출·문의·가입에 가장 가까운 URL 그룹을 먼저 봅니다. 랜딩 첫 화면은 LCP, 폼·필터·결제처럼 클릭 후 반응이 중요한 화면은 INP, 배너·이미지·폰트로 화면이 흔들리는 경우는 CLS를 먼저 잡는 것이 현실적입니다.

Q3. Search Console 경고를 고쳤는데 왜 바로 사라지지 않나요?

Core Web Vitals 보고서는 실제 사용자 데이터 기반이며 일정 기간의 누적 데이터를 반영합니다. 배포 직후에는 Lighthouse나 PageSpeed Insights 랩 테스트로 개선 여부를 먼저 확인하고, Search Console의 상태 변화는 시간을 두고 봐야 합니다.

Q4. 이미지 압축만 하면 Core Web Vitals가 좋아지나요?

LCP가 큰 이미지 다운로드 때문에 느린 경우에는 도움이 됩니다. 하지만 INP 문제는 자바스크립트 실행, 긴 작업, 이벤트 핸들러, 서드파티 스크립트가 원인인 경우가 많고, CLS는 이미지 공간 예약·폰트·동적 배너 구조가 더 중요합니다.

Q5. 로그인 후 SaaS 대시보드도 Core Web Vitals를 봐야 하나요?

검색 노출 대상이 아니더라도 봐야 합니다. 대시보드는 고객이 서비스 품질을 판단하는 화면이기 때문입니다. 초기 진입 LCP, 필터·탭·저장 버튼의 INP, 테이블·차트 로딩 중 CLS를 별도 운영 지표로 관리하는 것이 좋습니다.

참고한 공개 문서

자주 묻는 질문

PageSpeed Insights 점수 100점을 꼭 만들어야 하나요?
대부분의 사업 홈페이지와 SaaS에서는 100점보다 핵심 전환 화면의 실제 사용자 필드 데이터가 Good 기준을 통과하는지가 더 중요합니다. 특히 모바일 LCP, 가입·문의·결제 화면의 INP, 첫 화면 CLS를 우선 확인해야 합니다.
LCP, INP, CLS 중 무엇을 먼저 개선해야 하나요?
Search Console에서 Poor로 잡힌 지표 중 매출·문의·가입에 가장 가까운 URL 그룹을 먼저 봅니다. 랜딩 첫 화면은 LCP, 폼·필터·결제처럼 클릭 후 반응이 중요한 화면은 INP, 배너·이미지·폰트로 화면이 흔들리는 경우는 CLS를 먼저 잡는 것이 현실적입니다.
Search Console 경고를 고쳤는데 왜 바로 사라지지 않나요?
Core Web Vitals 보고서는 실제 사용자 데이터 기반이며 일정 기간의 누적 데이터를 반영합니다. 배포 직후에는 Lighthouse나 PageSpeed Insights 랩 테스트로 개선 여부를 먼저 확인하고, Search Console의 상태 변화는 시간을 두고 봐야 합니다.
이미지 압축만 하면 Core Web Vitals가 좋아지나요?
LCP가 큰 이미지 다운로드 때문에 느린 경우에는 도움이 됩니다. 하지만 INP 문제는 자바스크립트 실행, 긴 작업, 이벤트 핸들러, 서드파티 스크립트가 원인인 경우가 많고, CLS는 이미지 공간 예약·폰트·동적 배너 구조가 더 중요합니다.
로그인 후 SaaS 대시보드도 Core Web Vitals를 봐야 하나요?
검색 노출 대상이 아니더라도 봐야 합니다. 대시보드는 고객이 서비스 품질을 판단하는 화면이기 때문입니다. 초기 진입 LCP, 필터·탭·저장 버튼의 INP, 테이블·차트 로딩 중 CLS를 별도 운영 지표로 관리하는 것이 좋습니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 6층 101호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.