숫자가 말해주는 불편한 진실
DebugBear의 2025년 Lighthouse 실측 데이터는 꽤 충격적이다. 수천 개의 라이브 사이트를 분석한 결과, 모바일 PageSpeed 평균 점수가 Wix 72점, WordPress 34점, Squarespace 31점으로 집계됐다. 이건 몇몇 나쁜 사례가 끌어내린 평균이 아니다. 플랫폼 아키텍처가 구조적으로 만들어내는 필연적인 결과다.
Core Web Vitals는 '느림'이 아니라 '경험'을 측정한다
PageSpeed 점수를 단순히 로딩 속도 지표로 이해하면 본질을 놓친다. Google이 측정하는 건 세 가지 경험이다.
- LCP(Largest Contentful Paint): 화면에 의미 있는 콘텐츠가 언제 나타나는가. Google 권장치는 2.5초 이내인데, 일반적인 Wix 모바일 사이트는 3~6초가 걸린다.
- CLS(Cumulative Layout Shift): 페이지가 로드되는 동안 요소들이 얼마나 튀어다니는가. 비동기 스크립트를 잔뜩 불러오는 빌더 플랫폼에서 특히 두드러진다.
- INP(Interaction to Next Paint): 사용자가 탭하거나 클릭했을 때 얼마나 빠르게 반응하는가. 무거운 JS 프레임워크가 메인 스레드를 점령하면, 페이지가 다 보여도 아무것도 안 되는 상태가 된다.
세 지표 중 하나라도 기준을 벗어나면 점수는 급락한다. Squarespace나 WordPress가 30점대에 머무는 건 '조금 느린' 수준이 아니라, 적어도 한 지표가 심각하게 실패하고 있다는 신호다.
왜 이 플랫폼들은 구조적으로 느린가
해당 기사가 날카롭게 지적한 지점이 여기다. Wix나 Squarespace의 문제는 품질이 낮아서가 아니다. 오히려 반대다. 드래그앤드롭 에디터, 실시간 미리보기, 유연한 레이아웃 시스템—이 편의성을 구현하기 위한 엔진 전체가 방문자 브라우저에 그대로 전달된다. 방문자는 그 에디터를 쓸 일이 없는데도.
WordPress는 결이 조금 다르다. 테마와 플러그인이 쌓이면서 페이지에 필요하지 않은 JS·CSS가 함께 로드되고, 요청마다 데이터베이스를 쿼리하는 구조가 서버 응답 자체에 지연을 만든다. 여기에 애널리틱스 픽셀, 라이브챗 위젯, 쿠키 동의 툴 같은 서드파티 스크립트가 더해지면 렌더링이 완료되기 전에 수십 개의 요청이 쌓인다.
가장 중요한 대목은 기사 말미에 나온다. "이 문제들은 플랫폼 인터페이스 안에서 고칠 수 없다. 아키텍처에 구워진 것들이다."
AI 도구가 고칠 수 없는 이유
여기서 프론트엔드 개발자라면 자연스럽게 한 가지 질문이 생긴다. Cursor나 Claude에게 "이 사이트 성능 개선해줘"라고 하면 안 되나?
안 된다. 적어도 구조적 문제 앞에서는.
AI 도구는 코드 수준의 최적화에는 놀랍도록 유용하다. 이미지 lazy loading 속성 추가, 불필요한 리렌더 제거, 번들 사이즈 분석 후 dynamic import 제안—이런 작업은 AI가 빠르게 도와줄 수 있다. 하지만 Wix 사이트의 LCP가 5초인 이유는 loading="lazy"가 빠져 있어서가 아니다. 에디터 엔진 전체를 방문자에게 서빙하는 아키텍처 결정 때문이다.
이건 velog의 한 글이 LLM의 본질적 한계로 꼽는 것과 정확히 겹친다. "LLM은 트레이드오프를 나열하는 건 아주 잘한다. 근데 하나를 고르지는 않는다." 서드파티 스크립트를 얼마나 줄일 것인가, 정적 사이트로 전환하는 비용을 감수할 것인가, 플랫폼을 바꿀 것인가—이 결정들은 비즈니스 맥락과 제약 조건 안에서 사람이 판단해야 한다. AI는 옵션을 정리해주지만 결정하지 않는다.
성능은 비용이다, 감가상각되는
숫자를 비즈니스 언어로 번역해보면 더 명확해진다. Google과 SOASTA의 연구에 따르면 모바일 로딩 시간이 1초에서 3초로 늘어날 때 이탈 확률이 32% 증가한다. 5초가 되면 90%까지 뛴다. BBC는 페이지 로드가 1초 늘어날 때마다 사용자를 10%씩 잃는다고 보고했다.
"emergency plumber near me"를 밤 9시에 검색하는 사람은 4초를 기다리지 않는다. SEO, Google Ads, 콘텐츠 마케팅에 투자한 모든 노력이 성능이라는 관문 앞에서 새고 있다면, 그 투자는 구멍 난 파이프에 물을 붓는 것과 같다.
2021년부터 Core Web Vitals가 공식 랭킹 팩터가 된 이후, 점수 31점짜리 사이트와 95점짜리 사이트가 동일한 키워드에서 경쟁한다는 건 구조적 불리함을 안고 시작하는 것이다.
프론트엔드 개발자에게 남는 시사점
성능 최적화의 실무 흐름은 이렇게 정리된다.
진단 먼저: PageSpeed Insights와 DebugBear로 현재 LCP·CLS·INP 수치를 측정한다. 점수보다 어떤 지표가 어느 수준에서 실패하고 있는지가 핵심이다.
AI를 보조 도구로: Cursor나 Claude에게 Lighthouse 리포트를 붙여넣고 코드 수준에서 개선 가능한 항목을 추출하게 한다. 이미지 포맷 최적화, 렌더 블로킹 스크립트 식별, 불필요한 polyfill 제거—이런 작업은 AI와 함께 빠르게 처리할 수 있다.
아키텍처 결정은 사람이: 플랫폼을 바꿀 것인가, 정적 사이트로 전환할 것인가, 어떤 서드파티 스크립트를 포기할 것인가—이 질문들에 대한 답은 AI가 생성해줄 수 없다. 비즈니스 제약과 사용자 임팩트를 동시에 고려한 판단이 필요하다.
전망: 성능 부채는 조용히 쌓인다
흥미로운 역설이 있다. AI 코딩 도구가 빠른 프로토타이핑을 가능하게 할수록, 성능 최적화에 대한 의식적 결정을 미루기 쉬워진다. v0.dev로 UI를 뚝딱 만들고, Cursor로 기능을 빠르게 붙이는 사이, 번들 사이즈와 서드파티 의존성은 조용히 불어난다.
Core Web Vitals 점수는 개발 단계에서 내린 아키텍처 결정들의 총합이다. AI는 그 결정을 더 빠르게 실행하게 해주지만, 어떤 결정을 내려야 하는지는 여전히 개발자가 알고 있어야 한다. 성능은 기능이 아니다. 사용자가 첫 콘텐츠를 보기까지 걸리는 시간, 버튼을 눌렀을 때 페이지가 반응하는 속도—이것들이 사용자 경험의 가장 기본적인 토대다.
AI가 코드를 잘 짜주는 시대일수록, '무엇을 짜야 하는가'를 판단하는 역량이 더 중요해진다. Core Web Vitals는 그 판단력을 숫자로 보여주는 가장 솔직한 거울이다.