웹 성능 진단
비용을 갉아먹는 밀리초, 정확히 진단합니다
1초만 느려져도 매출은 10% 줄어듭니다. 나머지, 되찾을까요?
함께한 브랜드
8년 경력, 중요도가 높은 웹사이트에서 35+ 브랜드를 지원했습니다.
Des résultats concrets
Une approche holistique
Lire un rapport PageSpeed est à la portée de tout développeur, il est plus compliqué de comprendre réellement comment améliorer la performance du site web.
? Focus sur l'expérience utilisateur
Un site rapide est un site qui convertit. La qualité de l'expérience de vos clients peut avoir une incidence sur leur confiance envers votre marque.
? Optimisation des Core Web Vitals
En améliorant la web performance, vous accéderez aux attentes de Google sur les Core Web Vitals. Une bonne perf profitera d'un boost de positonnement dans les moteurs de recherche.
? Recommandations priorisées
Pour chaque point, des conseils adaptés pondérés par la difficulté d'accomplissement et le gain espéré.
? Critical Rendering Path
Identification des ressources bloquant le rendu des pages. Optimisation de la chaîne critique de rendu par des mécanismes modernes.
? Bundles JS & CSS
Audit de l'impact des assets de votre site web. Plus le navigateur est sollicité, plus lentes seront les pages et les interactions pour vos utilisateurs.
? Scripts tiers
Les third-parties ont un impact sur le thread principal. L'objectif n'est pas de les supprimer, mais d'optimiser leur chargement et de réduire leur impact sur l'expérience utilisateur.
Des améliorations mesurables et durables
Comment se passe un audit web performance ?
Un audit performance site web se déroule en 3 étapes clés nécessaires afin de vous produire le livrable le plus complet possible.
Découverte et alignement technique
Lors de cette première visio-conférence, nous échangeons sur la technique de votre site web, vos objectifs business et les pages stratégiques à auditer en priorité.
Réalisation de l'audit webperf
À l'aide de différents outils, je réalise l'audit complet de votre site : WebPageTest, Chrome DevTools, YLT, analyse des bundles JS/CSS et des third-parties.
Présentation du livrable
Une fois l'audit terminé, je vous proposerai de nous rencontrer une seconde fois en visio-conférence pour vous présenter le rapport détaillé et répondre à toutes vos questions.
Test des recommandations
Une fois l'implémentation terminée, je vérifie la bonne implémentation des changements sur votre site.
Découverte et alignement technique
Lors de cette première visio-conférence, nous échangeons sur la technique de votre site web, vos objectifs business et les pages stratégiques à auditer en priorité.
Réalisation de l'audit webperf
À l'aide de différents outils, je réalise l'audit complet de votre site : WebPageTest, Chrome DevTools, YLT, analyse des bundles JS/CSS et des third-parties.
Présentation du livrable
Une fois l'audit terminé, je vous proposerai de nous rencontrer une seconde fois en visio-conférence pour vous présenter le rapport détaillé et répondre à toutes vos questions.
Test des recommandations
Une fois l'implémentation terminée, je vérifie la bonne implémentation des changements sur votre site.
Des optimisations sur des dizaines de technologies
Résultats mesurables garantis
Si les recommandations appliquées conformément au rapport n'améliorent pas vos Core Web Vitals sous 30 jours, je retravaille l'audit gratuitement.
Ce qu'en disent mes clients
훌륭한 작업입니다.
Paul은 사이트 속도를 눈에 띄게 개선했고 Google 권장사항에 완벽히 맞춰 주었습니다.
전문적이고 꼼꼼하며 효율적이라 강력히 추천합니다.
Nicolas - April Moto
디지털 & 이커머스 디렉터
저희는 Paul의 업무에 매우 만족하고 있습니다. 그는 신속하고, 언제든지 응대 가능하며, 특히 효율적입니다. 그가 합류한 이후 성과와 대응력 측면 모두에서 매우 좋은 결과가 확인되었습니다. 저희 팀의 진정한 자산입니다.
Léo - Maison de luxe
이커머스 프로덕트 오너
우리가 이 말을 충분히 했는지는 모르겠지만.
하지만 로딩 속도를 개선하고,
Google을 만족시키고 Core Web Vitals를 초록 영역으로 만들고 싶다면,
Paul Delcloy에게 연락하세요.
Florian Darroman - Les Makers
공동 창업자
Prêt à accélérer ?
2023-2026 데이터
Foire aux questions
Pourquoi réaliser un audit web performance ?
Sur quelles technologies travaillez-vous ?
Les recommandations sont-elles classées ?
web performance 감사를 왜 수행해야 하는가?
web performance 감사는 모든 최적화 작업의 필수 출발점입니다. 정확한 진단 없이는 개선 노력이 잘못된 지렛대를 겨냥할 위험이 있습니다. 감사는 사이트를 느리게 만드는 진짜 병목을 식별합니다. 렌더링을 차단하는 리소스, 최적화되지 않은 이미지, 무거운 third-party 스크립트, 비효율적인 서버 요청이 그것입니다.
PageSpeed Insights 같은 자동화 도구는 점수를 제공하지만, 문제를 이해하고 해결하는 열쇠를 주는 경우는 드뭅니다. 전문가의 감사는 여기서 더 나아가 전체 기술 맥락을 분석합니다. 프론트엔드 아키텍처, 크리티컬 렌더링 체인, third-party의 영향, 실제 사용자 행동까지 다룹니다.
Core Web Vitals: 중요한 지표들
Google은 세 가지 핵심 지표로 사이트의 성능을 평가합니다. LCP (Largest Contentful Paint)는 주요 콘텐츠가 표시되는 속도를 측정하고, INP (Interaction to Next Paint)는 사용자 상호작용에 대한 반응성을 평가하며, CLS (Cumulative Layout Shift)는 페이지의 시각적 안정성을 정량화합니다.
이 지표들은 단순한 기술적 수치가 아닙니다. 사용자의 경험을 직접적으로 반영하고 검색 결과에서의 순위에 영향을 미칩니다. 각 지표에 대한 상세 감사는 무엇이 지표를 떨어뜨리는지, 어떻게 해결할지를 정확히 파악하게 해줍니다.
감사에서 실행 가능한 권고로
감사 과정에서 식별된 모든 항목에는 구체적인 권고가 함께 제공되며, 영향과 구현 난이도에 따라 분류됩니다. 이러한 우선순위 지정은 팀이 더 복잡한 최적화를 다루기 전에 quick win에 집중할 수 있게 해줍니다.
산출물에는 비교 스크린샷, 수치화된 측정값, 상세한 기술 지침이 포함됩니다. 목표는 각 권고가 개발자에 의해 모호함 없이 즉시 실행 가능하도록 하는 것입니다.
보고서를 넘어: 완전한 동반
감사는 보고서 전달로 끝나지 않습니다. 발표 세션을 통해 팀과 함께 각 항목을 훑고, 질문에 답하며, 최적화 로드맵을 함께 정의합니다. 필요한 경우 권고 구현에 직접 개입하거나 개발자들이 이를 실행하는 것을 지원할 수도 있습니다.
web performance 감사가 실제로 드러내는 것
PageSpeed 점수는 감사가 아닙니다. 그것은 캘리포니아 데이터센터에서 단일 URL에 대해 시뮬레이션된 네트워크 프로파일로 생성된 스냅샷입니다. 거기서 빨간색 또는 초록색 표시와 몇 가지 일반적인 권고("렌더링을 차단하는 리소스 제거")를 얻지만, 문제에 대한 이해는 거의 얻지 못합니다.
8년간의 web performance 프로젝트 경험에서, Lighthouse 점수가 45인 사이트가 Core Web Vitals를 초록 구간으로 통과하는 것을, 그리고 그 반대로 실험실 점수 92가 실제 필드에서 실패하는 것을 보았습니다. Chanel이 구체적인 사례입니다. Lighthouse 점수는 51 근처였지만 Core Web Vitals는 여유 있게 통과했습니다. 이유는 Next.js의 islands 아키텍처, 격리된 인터랙티브 컴포넌트, 부분 hydration에 있습니다. 자동화 도구는 무거운 pre-render 페이지의 로드를 측정하지만, 사용자는 도구가 시뮬레이션하지 못하는 반응성의 혜택을 받습니다.
감사는 점수를 읽는 것에 그치지 않습니다. 세 가지 데이터 계층을 교차 검증합니다. 합성 측정(Lighthouse, WebPageTest, YellowLabTools), 필드 데이터(CrUX, 내부 RUM), 그리고 코드의 직접 판독입니다. 세 가지 없이는 눈을 감고 고치는 셈입니다.
실험실 점수와 실제 속도의 차이
감사의 첫 번째 분류 작업은 Google이 사이트에서 측정하는 것과 사용자가 실제로 느끼는 것을 분리하는 것입니다. 두 가지는 항상 일치하지는 않습니다.
CrUX는 지난 28일간 Chrome 방문자의 필드 데이터를 집계합니다. 이는 Google이 Page Experience 계층에서 사이트를 순위 매기는 데 사용하는 기반입니다. 필드 TTFB 900 ms는 통제된 시뮬레이션에서 돌아가는 Lighthouse가 300 ms로 낮게 잡을 수 있는 인프라 문제를 드러냅니다. 반대로 실험실 INP 45 ms는 실제 4G 모바일에서 320 ms의 JavaScript 핸들러를 감출 수 있으며, 이는 빨간 구간 임계값을 넘습니다.
활용 가능한 감사는 이러한 격차를 식별합니다. 최근 e-commerce 프로젝트에서, Lighthouse가 2.1초로 표시하는 동안 필드 LCP가 3.8초인 것을 보았습니다. 원인은 mobile hero가 중앙값 6 Mbit/s 연결에서 340 KB AVIF 이미지를 로드하고 있었고, Lighthouse는 더 우호적인 연결을 시뮬레이션했다는 점이었습니다. 문제 해결은 조건부 srcset을 통해서였지, 또 다른 일반적인 이미지 최적화를 통해서가 아니었습니다.
진실 원천의 피라미드
신뢰도가 가장 낮은 것부터 가장 결정적인 것까지:
- PageSpeed 요약 점수: 대략적인 지표, 우선순위 3으로만 참고.
- 로컬 Lighthouse: 재현 가능하지만 머신 프로파일에 의존.
- 다중 위치 WebPageTest: 진지한 감사에서 기대되는 엄격함 수준.
- CrUX: Google의 눈에 비친 진실.
- 내부 RUM: 사용자의 눈에 비친 진실.
어떤 도구도 나 대신 하지 못하는 진단
자동화된 권고는 세 가지 반복되는 문제 유형에서 벽에 부딪힙니다. 아키텍처 결정, 비즈니스 측면의 config 오류, third-party 컴포넌트 간의 예기치 못한 상호작용입니다. 어떤 도구도 이것들을 정확히 명명하지 못합니다. 진지한 감사는 이것들을 능동적으로 찾습니다.
더 이상 존재하지 않는 브라우저 캐시.
프랑스 e-commerce, 월 60,000 세션, CDN이 제대로 설정되어 있음에도 필드 LCP가 4.2초. PageSpeed 점수는 "캐시 지속 시간이 너무 짧음"이라고만 짚었습니다. 감사는 근본 원인을 밝혀냈습니다. 배송비가 팝업에 입력된 우편번호에서 계산되어 첫 페이지부터 표시되고 있었습니다. 우편번호가 캐시 세그먼트로 사용되고 있었습니다. 우편번호와 제품 카테고리의 모든 조합이 별개의 캐시 항목을 생성했습니다. 결과적으로 재방문자의 브라우저 캐시는 거의 무용지물이었고, 방문할 때마다 HTML을 다시 다운로드하고 있었습니다. 수정: 배송 계산을 post-load AJAX 호출로 전환, 전역 HTML 캐시. 필드 LCP는 3주 만에 1.6초로, mobile 이탈률은 14% 감소했습니다.
이것이 감사에 비용을 지불하는 유형의 진단입니다. 도구는 증상(짧은 캐시)을 봅니다. 컨설턴트는 그것을 만든 제품 결정까지 거슬러 올라가 기술적 대안을 제안합니다.
또 다른 자주 보이지 않는 범주는 밀항자처럼 행동하는 모듈과 plugin입니다. 공공 기관용 Drupal 플랫폼에서, 각 페이지마다 JS bundle 하나, CSS 시트 하나를 로드하고 수천 줄의 SQL을 실행하는 여섯 개의 모듈을 감사했습니다. 그 데이터는 단일 페이지에 있는 폼에만 사용되고 있었습니다. 중앙값 TTFB는 1.3초였고, 이 중 450 ms가 이 과잉에 직접 귀속됐습니다. 조건부 로딩으로 CMS 코어를 건드리지 않고 TTFB를 850 ms로 낮췄습니다. 이런 종류의 분석은 보고서를 읽는 것이 아니라, 테마와 모듈 코드까지 내려가야 합니다.
수정의 우선순위: 영향 / 노력 매트릭스
우선순위 지정 없이 40개의 권고를 전달하는 감사는 쓸모없는 감사입니다. 저는 식별된 각 항목에 두 가지 평가를 붙입니다. 관련 Core Web Vitals에 대한 예상 비즈니스 영향, 개발자 일수로 표현된 구현 노력입니다. 이 매트릭스가 분류 작업을 합니다.
최근 발표 세션에서, 식별된 32개의 권고 중 6개가 잠재 LCP 이득의 78%를 집중시켰고, 개발 총합은 4일이었습니다. 나머지는 소규모 수정으로 분산되어 남은 22%의 이득을 위해 누적 21일을 요구했습니다. DSI의 결정은 분명했습니다. 6개를 즉시 sprint에 담고, 나머지는 후속 분기에 예산으로 편성한다는 것이었습니다. 매트릭스 없이는 보고서의 첫 번째 권고, 대개 가장 수익성이 낮은 항목부터 시작했을 것입니다.
매트릭스는 또한 절충 결정을 내리는 데 도움이 됩니다. 웹 폰트를 font-display: optional로 전환하면 LCP 200 ms를 얻지만, 캐시되지 않은 느린 연결에서는 브랜드 폰트의 표시를 제거할 수 있습니다. 이것은 기술적 결정이 아니라 그래픽 가이드라인과 속도 사이의 절충입니다. 감사는 절충을 드러내고, 제품 리더십이 결정합니다.
감사가 제품 결정을 재조정할 때
감사의 결과는 초기 범위를 넘어 방향을 재고하게 만들 수 있습니다. 저는 이 순간을 여러 번 경험했습니다. 그중 하나입니다.
April Moto: 지각된 느림에서 표적화된 개편으로.
오토바이 보험 중개 [WordPress](https://pauld.fr/ko/expertises/wordpress) 사이트, SEA 캠페인에 민감한 트래픽. mobile에서 필드 LCP 3.2초, INP는 오렌지 구간. 초기 요청은 상당한 예산으로 추정된 전체 테마 리뉴얼이었습니다. 감사 결과 렌더 시간의 68%가 세 개의 plugin(폼, 동의 팝업, 채팅)과 과부하된 hero 슬라이더에서 왔음을 보여줬습니다. 리뉴얼 없이 이 네 개 컴포넌트에 대한 3주간의 표적 작업으로 LCP는 1.3초로 떨어지고, INP는 초록으로, 견적에서 측정된 전환 이득은 +9%였습니다. 리뉴얼은 다음 해로 미뤄졌고, 이번에는 "사이트가 낡아 보인다"는 직관이 아니라 필드 데이터에 의해 프레이밍되었습니다.
"리뉴얼할 필요 없이 이것을 고치세요"라는 결론에 이르는 web performance 감사가 때로 가장 수익성 있는 산출물입니다. 반대로 감사가 어떠한 주변부 최적화도 초기 아키텍처 선택을 상쇄하지 못할 것이며, 크리티컬 경로의 부분 리뉴얼이 올바른 투자임을 밝힐 수도 있습니다. 두 경우 모두 결정은 인상이 아니라 측정된 데이터에 기반합니다.
감사가 대체하지 못하는 것
감사는 출발점이지 종착점이 아닙니다. 프로젝트를 의뢰하기 전에 알아야 할 세 가지 정직한 한계가 있습니다.
감사는 web performance 최적화 단계를 대체하지 못합니다. 보고서는 식별하고 우선순위를 매기지만, 권고 구현에는 훈련된 내부 팀이나 동반 지원이 필요합니다. 이 이어받음 없이는 비싼 감사가 선반 위에 남습니다. 저는 즉시 내부 역량이 없는 클라이언트를 위해 항상 구현 옵션을 제안합니다.
감사는 또한 지속적인 web performance 모니터링 체계를 대체하지 못합니다. Core Web Vitals는 배포마다, 마케팅 tag 통합마다, plugin 업데이트마다 조용히 저하됩니다. 이후 모니터링 없는 일회성 감사는 움직이는 시스템을 t 시점에 사진 찍는 것과 같습니다. 3개월 뒤에는 상황이 달라져 있습니다. 필드 지표에 대한 모니터링, 회귀에 대한 경보는 시간에 걸쳐 감사의 혜택을 연장시킵니다.
마지막으로, 감사는 제품 팀이 공유하는 성능 문화를 대체하지 못합니다. Core Web Vitals를 침몰시키는 실수는 자신의 선택의 영향을 측정하지 않는 개발자나 마케터에 의해 종종 도입됩니다. 보고서를 전달하고 물러나는 감사는 회귀에 비옥한 땅을 남깁니다. 더 긴 프로젝트에서는 관련 팀을 위한 인식 세션을 항상 포함합니다. INP가 무엇인지, 왜 장식용 캐러셀이 CLS를 떨어뜨리는지, 새로운 third-party 스크립트를 통합하기 전에 어떻게 측정할 것인지.
web performance 감사에 관한 자주 묻는 질문
web performance 감사는 얼마나 걸리나요?
일반적으로 첫 기술 교류부터 결과 발표까지 영업일 기준 5일입니다. 상세 보고서는 실질적인 분석 2~3일과 1시간 화상 결과 발표 세션이 추가됩니다. 복잡한 프로젝트(다중 도메인, 크리티컬 경로가 많은 SPA 애플리케이션)에서는 기간이 8일에 이를 수 있습니다.
감사는 구체적으로 무엇을 다루나요?
분석은 렌더링 전체 체인을 다룹니다. 서버 TTFB, 렌더링을 차단하는 리소스, LCP 이미지, JavaScript 및 CSS bundle, third-party 스크립트, main thread의 long task, 시각적 안정성입니다. Lighthouse, WebPageTest, Chrome DevTools, YellowLabTools, CrUX 데이터를 교차 검증합니다. 보고서에는 비교 스크린샷, 예상되는 전/후 측정값, 영향별로 분류된 권고가 포함됩니다.
PageSpeed Insights만으로 감사를 할 수 있나요?
아니요. PageSpeed Insights는 유용한 진입점을 제공하지만 충분하지 않습니다. 고정된 시뮬레이션에서 실행되고, 하나의 URL만 테스트하며, 코드로 내려가지 않고, 문제를 만든 제품 결정을 이해하지 못합니다. 초록 PSI 점수가 저하된 필드 TTFB를 감출 수 있고, 빨간 점수가 훌륭한 실제 Core Web Vitals를 가릴 수 있습니다. 감사는 실험실 / 필드 격차를 확인하고 근본 원인을 찾아냅니다.
Lighthouse로 스스로 감사를 할 수 있나요?
로컬에서 Lighthouse를 실행하고 권고를 읽을 수 있습니다. 하지만 우선순위 매트릭스도, 코드 판독도, 경쟁사의 Core Web Vitals에 대한 교차 시각도, 다른 곳에서 통했던 기술적 결정에 대한 경험도 갖지 못할 것입니다. 상업적 이해관계가 있는 사이트에서는 "권고가 있다"와 "어느 세 가지 수정이 지표를 움직일지 안다" 사이의 차이가 외부 감사의 가치를 만듭니다.
권고가 Core Web Vitals를 개선하지 못하면 어떻게 되나요?
보고서에 따라 적용된 수정이 30일 이내에 Core Web Vitals를 개선하지 못하면, 추가 청구 없이 감사를 재작업합니다. 이 약속은 각 항목에 대해 수치화된 이득 가설과 함께 검증 가능한 권고를 제공하기 때문에 존재합니다.
언제 web performance 감사를 시작할 것인가
어떤 신호는 거짓말을 하지 않으며, 다음 리뉴얼을 기다리지 않고 감사를 정당화합니다.
Search Console에서 식별된 릴리스로 설명되지 않는 Core Web Vitals의 하락은 강한 신호입니다. 외부 대행사가 기술 팀을 거치지 않고 추가한 단순 마케팅 tag 하나 때문에 3주 만에 사이트가 빨간 구간으로 넘어가는 것을 보았습니다. 감사 없이는 원인이 여러 달 동안 보이지 않은 채로 남습니다.
트래픽이 안정적으로 유지되는데 mobile 이탈률이 다시 오르는 것, 세션당 평균 시간이 줄어드는 것, 평균 장바구니가 mobile에서 desktop보다 빠르게 떨어지는 것 — 이 세 가지 비즈니스 지표는 종종 말없이 성능을 가리킵니다. mobile 전환은 저하된 LCP에 빠르게 반응하고, 신호는 Google Analytics에 명확히 나타나기 전에 상업 대시보드에서 먼저 올라옵니다.
마지막으로, 주요 인프라 변경, 호스팅 마이그레이션, CMS 메이저 버전 업데이트, 테마 리뉴얼, CDN 추가 — 이런 변경은 배포 후 2~3주에 통제 감사를 요구합니다. CrUX 데이터가 안정될 시간을 준 뒤, 변경의 초기 약속이 필드 이득으로 이어졌는지 확인합니다. 최근 세 개의 프로젝트에서, 이전 공급자가 "더 빠르다"고 약속한 마이그레이션이 실제로는 TTFB를 200에서 400 ms로 저하시켰습니다. 전/후 격차에 초점을 맞춘 짧은 감사가 계약을 재협상할 수 있게 했습니다.