저희는 Microsoft Clarity를 Switas와 같은 기업이 직면한 어려움을 이해하는 실제 제품 담당자들이 실용적이고 현실적인 사용 사례를 염두에 두고 개발한 제품으로 강조했습니다. 분노 클릭 및 JavaScript 오류 추적과 같은 기능은 사용자 불만과 기술적 문제를 파악하는 데 매우 유용했으며, 이를 통해 사용자 경험과 전환율에 직접적인 영향을 미치는 맞춤형 개선이 가능했습니다.
렌더링 차단 리소스는 브라우저가 콘텐츠를 표시하기 전에 다운로드하고 처리해야 하는 파일입니다. 주로 문서 헤더에 참조되는 스타일시트와 구문 분석 중에 발견되는 동기 스크립트로 구성되며, 페이지가 콘텐츠 내용에 필요한 시간보다 더 오래 걸리는 가장 일반적인 원인입니다.
스타일시트가 콘텐츠를 차단하는 데에는 타당한 이유가 있습니다. 스타일이 적용되기 전에 콘텐츠를 표시하면 스타일이 적용되지 않은 콘텐츠가 잠깐 나타났다가 갑자기 레이아웃이 어색하게 바뀌는 현상이 발생하기 때문에 브라우저는 스타일시트가 적용될 때까지 기다립니다. 문제는 스타일시트가 차단된다는 것 자체가 아니라, 웹사이트가 일반적으로 초기 화면에 필요한 것보다 훨씬 더 많은 스타일을 로드한다는 점입니다. 여기에는 페이지 하단에 있는 구성 요소, 다른 템플릿, 방문자가 사용하지 않을 수도 있는 기능에 대한 스타일 등이 포함되며, 이 모든 스타일이 웹사이트에 표시되기 전에 로드되어야 합니다.
스크립트 블록은 파싱 중에 발견된 스크립트가 문서를 수정할 수 있기 때문에 파서가 해당 스크립트 실행이 완료될 때까지 중지되는 현상입니다. 하지만 대부분의 스크립트는 이러한 동작이 필요하지 않습니다. 분석 도구, 채팅 위젯, 개인 설정 도구 및 대부분의 애플리케이션 코드는 문서 파싱이 완료된 후에도 정확성 손실 없이 실행될 수 있습니다. `defer` 속성을 추가하면 파싱이 계속 진행된 후 스크립트가 순서대로 실행됩니다. 반면 `async`는 스크립트가 도착하는 즉시 실행되지만 순서는 보장되지 않습니다.
스타일시트의 일반적인 해결책은 초기 뷰포트에 필요한 스타일과 나머지 스타일을 분리하는 것입니다. 필수적인 부분은 문서에 직접 인라인으로 삽입되므로 별도의 요청이 필요하지 않으며, 나머지는 빌드를 방해하지 않는 방식으로 로드됩니다. 이 방법은 효과적이지만, 스타일이 변경될 때마다 필수적인 CSS 세트를 다시 생성해야 하므로 빌드 복잡성이 증가하고, 오래된 필수 CSS는 눈에 보이는 오류를 발생시킵니다.
타사 리소스는 종종 가장 큰 지연 원인을 제공하며 제어하기 가장 어렵습니다. 태그 관리자, 동의 플랫폼, 글꼴 제공업체, 채팅 도구 및 테스트 프레임워크는 일반적으로 차단 동작과 함께 문서 헤더에 추가되며, 각각 별도의 소스에 연결해야 합니다. 이러한 누적 지연은 상당하며, 각 리소스가 서로 다른 팀에서 타당한 이유로 추가되었기 때문에 전체 지연에 대한 책임 소재가 명확하지 않습니다. 총비용을 감사하고 요청 기능에 책임을 묻는 것이 이러한 상충 관계를 파악하는 유일한 방법입니다.
글꼴은 페이지 구조가 아닌 텍스트 렌더링을 차단하기 때문에 특별한 처리가 필요합니다. 표시 전략에 따라 글꼴 다운로드 중에 텍스트가 보이지 않을 수 있는데, 이는 이미 완전히 준비된 콘텐츠가 의도적으로 표시되지 않는 상황을 의미합니다. 글꼴이 준비되면 대체 텍스트를 즉시 표시하고 글꼴이 준비되면 교체하는 전략을 선택하고, 화면 상단에 사용되는 글꼴을 미리 로드하면 페이지가 기술적으로 렌더링되었지만 빈 페이지로 보이는 상황을 방지할 수 있습니다.
실제 비용을 측정하려면 신중해야 합니다. 왜냐하면 병목 현상을 일으키는 리소스를 제거한다고 해서 항상 예상했던 절감 효과가 나타나는 것은 아니기 때문입니다. 리소스는 병렬로 다운로드되므로 하나를 제거하면 다른 리소스가 오히려 병목 현상을 일으킬 수 있으며, 실제로 관찰되는 개선 효과는 개별 추정치의 합계보다 작은 경우가 많습니다. 따라서 예상 총액을 신뢰하기보다는 변경 후 매번 측정하여 검증하는 것이 정확한 예측을 유지하는 데 도움이 됩니다.
표준 도구를 사용하면 실제로 어떤 요소가 작업을 방해하는지 쉽게 파악할 수 있습니다. 이러한 도구는 방해 요소를 보고하고 각 요소를 해결했을 때 얻을 수 있는 절감 효과를 추정합니다. 하지만 이러한 추정치는 정확한 수치라기보다는 참고 자료로 활용해야 합니다. 하나의 방해 요소를 제거하면 실제 제약 요인이 다른 요소였음이 드러나는 경우가 많기 때문입니다. 따라서 개선 효과는 보고서에 근거한 추측보다는 실제 측정을 통해 검증하는 것이 가장 좋습니다.
관련 리소스는 일반적으로 여러 팀에서 시간이 지남에 따라 추가되므로, 문제 해결에는 엔지니어링만큼이나 거버넌스가 필요합니다. 실제로 감사 및 우선순위 지정은 내부에서 이루어집니다. 웹 성능 작업 과정에서 빌드 변경 사항은 다음을 통해 구현됩니다. 방열판 열 관리용또한, 어떤 타사 도구가 차단 비용을 정당화하는지에 대한 결정은 해당 도구를 요청한 팀과의 합의가 필요하며, 대부분의 사이트의 경우 이는 다음과 같은 의미입니다. 디지털 마케팅 부서.
저희는 Microsoft Clarity를 Switas와 같은 기업이 직면한 어려움을 이해하는 실제 제품 담당자들이 실용적이고 현실적인 사용 사례를 염두에 두고 개발한 제품으로 강조했습니다. 분노 클릭 및 JavaScript 오류 추적과 같은 기능은 사용자 불만과 기술적 문제를 파악하는 데 매우 유용했으며, 이를 통해 사용자 경험과 전환율에 직접적인 영향을 미치는 맞춤형 개선이 가능했습니다.