성능 및 사용성을 위해 쿠키 알림을 최적화합니다.
이 문서에서는 쿠키 알림이 성능, 성능 측정, 사용자 환경에 미치는 영향을 설명합니다.
성능
쿠키 알림은 일반적으로 페이지 로드 프로세스 초기에 로드되고 모든 사용자에게 표시되며 광고 및 기타 페이지 콘텐츠의 로드에 잠재적으로 영향을 미칠 수 있기 때문에 페이지 성능에 상당한 영향을 미칠 수 있습니다.
쿠키 알림이 웹 바이탈 측정항목에 미치는 영향은 다음과 같습니다.
최대 콘텐츠 페인트 (LCP): 대부분의 쿠키 동의 알림은 상당히 작으므로 일반적으로 페이지의 LCP 요소를 포함하지 않습니다. 그러나 특히 휴대기기에서는 이러한 상황이 발생할 수 있습니다. 휴대기기에서 쿠키 참고사항은 일반적으로 화면에서 더 많은 부분을 차지합니다. 이러한 상황은 일반적으로 쿠키 알림에 대규모 텍스트 블록이 포함된 경우 발생합니다 (텍스트 블록도 LCP 요소일 수 있음).
다음 페인트에 대한 상호작용 (INP): 쿠키 알림은 일반적으로 수락 시 많은 서드 파티 스크립트를 추가하기 때문에 INP가 높아지는 원인이 될 수 있습니다. 주요 문제는 Accept 상호작용을 수행하는 것입니다. 이 경우 서드 파티 스크립트를 모두 한 번에 추가하는 데 많은 처리가 필요합니다. 이 문제를 완화하는 방법은 아래 권장사항 섹션을 참고하세요.
누적 레이아웃 변경 (CLS): 쿠키 동의 알림은 레이아웃 변경의 매우 일반적인 소스입니다.
일반적으로 서드 파티 제공업체의 쿠키 알림은 개발자가 직접 만든 쿠키 참고사항보다 성능에 더 큰 영향을 미칠 것으로 기대할 수 있습니다. 이는 쿠키 참고사항에 고유한 문제가 아니라 일반적으로 서드 파티 스크립트의 특성입니다.
권장사항
이 섹션의 권장사항은 서드 파티 쿠키 참고사항에 중점을 둡니다. 이러한 권장사항 중 일부는 퍼스트 파티 쿠키 알림에도 적용될 수 있습니다.
쿠키 참고사항이 INP에 미치는 영향 이해하기
앞서 언급했듯이 Accept 버튼을 클릭하면 많은 양의 처리가 발생하기 때문에 INP 문제가 발생하는 특정 원인이 되는 경우가 많습니다.
Chrome팀은 여러 동의 관리 플랫폼 (CMP)과 협력하여 동의 클릭 후 동의가 도출될 수 있도록 하여 브라우저가 다음 페인트에서 빠르게 수락을 확인할 수 있도록 했습니다. 이 PubTech 우수사례를 예로 참조하세요.
사용 중인 CMP가 이로 인해 영향을 받는 경우 CMP에 연락하여 CMP를 삽입하는 사이트의 INP 문제를 마찬가지로 방지할 수 있는지 확인하세요. 수익 창출 전략에 대한 안내는 장기 작업 최적화 도움말을 참고하세요.
쿠키 알림 스크립트를 비동기식으로 로드하기
쿠키 참고사항 스크립트는 비동기식으로 로드되어야 합니다. 이렇게 하려면 async 속성을 스크립트 태그에 추가합니다.
<script src="https://cookie-notice.com/script.js" async>
비동기적이지 않은 스크립트는 브라우저 파서를 차단합니다. 이렇게 하면 페이지 로드와 LCP가 지연됩니다. 자세한 내용은 서드 파티 JavaScript의 효율적인 로드를 참고하세요.
쿠키 참고사항 스크립트 직접 로드
쿠키 참고사항 스크립트는 태그 관리자나 다른 스크립트에 의해 로드되지 않고 기본 문서의 HTML에 스크립트 태그를 배치하여 '직접' 로드해야 합니다. 태그 관리자 또는 보조 스크립트를 사용하여 쿠키 참고사항 스크립트를 삽입하면 쿠키 참고사항 스크립트 로드가 지연됩니다. 즉, 브라우저의 미리보기 파서에서 스크립트를 가리고 자바스크립트 실행 전에 스크립트가 로드되지 않습니다.
쿠키 알림 출처로 조기 연결 설정
서드 파티 위치에서 쿠키 알림 스크립트를 로드하는 모든 사이트는 쿠키 알림 리소스를 호스팅하는 출처와의 조기 연결을 설정하는 데 도움이 되는 dns-prefetch 또는 preconnect 리소스 힌트를 사용해야 합니다. 자세한 내용은 인지되는 페이지 속도 개선을 위해 네트워크 연결 조기 설정을 참고하세요.
<link rel="preconnect" href="https://cdn.cookie-notice.com/">
적절한 쿠키 알림 미리 로드
일부 사이트에서는 preload 리소스 힌트를 사용하여 쿠키 참고사항 스크립트를 로드하는 것이 좋습니다. preload 리소스 힌트는 지정된 리소스의 조기 요청을 시작하도록 브라우저에 알립니다.
<link rel="preload" href="https://www.cookie-notice.com/cookie-script.js">
preload는 사용이 페이지당 몇 개의 키 리소스만 가져올 때 가장 강력합니다. 따라서 쿠키 알림 스크립트를 미리 로드하는 것의 유용성은 상황에 따라 달라집니다.
쿠키 알림 스타일 지정 시 성능 저하 유의
서드 파티 쿠키 알림의 디자인을 맞춤설정하면 추가 성능 비용이 발생할 수 있습니다. 예를 들어 서드 파티 쿠키 알림은 페이지의 다른 위치에서 사용되는 것과 동일한 리소스 (예: 웹 글꼴)를 항상 재사용할 수 있는 것은 아닙니다. 또한 서드 파티 쿠키 참고사항은 긴 요청 체인의 끝에 스타일을 로드하는 경향이 있습니다. 예상치 못한 상황을 방지하려면 쿠키 알림이 로드되고 스타일 지정 및 관련 리소스를 어떻게 적용하는지 알고 있어야 합니다.
레이아웃 변경 피하기
다음은 쿠키 알림과 관련된 가장 일반적인 레이아웃 변경 문제입니다.
- 화면 상단 쿠키 알림: 화면 상단 쿠키 알림은 레이아웃 변경의 매우 일반적인 소스입니다. 주변 페이지가 이미 렌더링된 후에 DOM에 쿠키 알림이 삽입되면 그 아래에 있는 페이지 요소가 페이지 아래로 푸시됩니다. 이러한 유형의 레이아웃 변경은 동의 알림을 위한 DOM에 공간을 예약하여 제거할 수 있습니다. 가능한 해결책이 아닌 경우(예: 쿠키 알림의 크기가 지역에 따라 다른 경우) 고정 바닥글 또는 모달을 사용하여 쿠키 참고사항을 표시하는 것이 좋습니다. 두 가지 방법 모두 쿠키 알림이 페이지의 나머지 부분 위에 '오버레이'로 표시되므로, 쿠키 알림이 로드될 때 콘텐츠 이동을 유발해서는 안 됩니다.
- 애니메이션: 많은 쿠키 참고사항은 애니메이션을 사용합니다. 예를 들어 쿠키 참고사항을 '슬라이드인'하는 것은 일반적인 디자인 패턴입니다. 이러한 효과가 구현되는 방법에 따라 레이아웃이 변경될 수 있습니다. 자세한 내용은 레이아웃 변경 디버깅을 참고하세요.
- 글꼴: 글꼴 로드가 지연되면 렌더링이 차단되거나 레이아웃이 변경될 수 있습니다. 이 현상은 연결이 느린 경우 더 두드러집니다.
고급 로드 최적화
이러한 기법을 사용하면 구현하는 데 더 많은 작업이 필요하지만 쿠키 참고사항 스크립트의 로드를 더욱 최적화할 수 있습니다.
- 자체 서버에서 서드 파티 쿠키 참고사항 스크립트를 캐시하고 제공하면 이러한 리소스의 전달 속도를 개선할 수 있습니다.
- 서비스 워커를 사용하면 쿠키 참고사항 스크립트와 같은 서드 파티 스크립트 가져오기 및 캐싱을 더 세부적으로 제어할 수 있습니다.
실적 측정
쿠키 참고사항은 성능 측정에 영향을 줄 수 있습니다. 이 섹션에서는 이러한 영향과 이를 완화하는 기법을 설명합니다.
실제 사용자 모니터링 (RUM)
일부 분석 및 RUM 도구는 쿠키를 사용하여 성능 데이터를 수집합니다. 사용자가 쿠키 사용을 거부하면 이러한 도구는 성능 데이터를 캡처할 수 없습니다.
사이트에서 이 현상을 인지하고 있어야 합니다. 또한 RUM 도구가 데이터를 수집하는 데 사용하는 메커니즘을 이해하는 것이 좋습니다. 하지만 일반적인 사이트의 경우 데이터 편향의 방향과 크기를 고려할 때 이러한 불일치는 경보의 원인이 아닙니다. 쿠키 사용은 성능 측정을 위한 기술적 요구사항이 아닙니다. web-vitals JavaScript 라이브러리는 쿠키를 사용하지 않는 라이브러리의 예입니다.
사이트에서 쿠키를 사용하여 성능 데이터를 수집하는 방식(쿠키에 개인 정보가 포함되어 있는지 여부) 및 해당 법률에 따라 성능 측정을 위한 쿠키 사용에는 다른 목적(예: 광고 쿠키)으로 사이트에서 사용되는 일부 쿠키와 동일한 법률 요건이 적용되지 않을 수 있습니다. 일부 사이트에서는 사용자 동의를 요청할 때 성능 쿠키를 별도의 쿠키 카테고리로 분류합니다.
합성 모니터링
맞춤 구성을 사용하지 않으면 대부분의 합성 도구 (예: Lighthouse 및 WebPageTest)가 쿠키 동의 알림에 응답하지 않은 최초 사용자의 환경만 측정합니다. 하지만 성능 데이터를 수집할 때는 캐시 상태의 변화 (예: 최초 방문과 재방문)뿐만 아니라 수락, 거부, 미응답 등 쿠키 수락 상태의 변화도 고려해야 합니다.
WebPageTest로 쿠키 알림 테스트
다음 섹션에서는 쿠키 알림을 성능 측정 워크플로에 통합하는 데 도움이 될 수 있는 WebPageTest 및 Lighthouse 설정에 대해 설명합니다. 하지만 쿠키 및 쿠키 알림은 실험실 환경에서 완벽하게 시뮬레이션하기 어려울 수 있는 여러 요소 중 하나일 뿐입니다. 따라서 합성 도구보다는 RUM 데이터를 성능 벤치마킹의 기초로 만드는 것이 중요합니다.
스크립팅 사용
스크립팅을 사용하여 트레이스를 수집하는 동안 WebPageTest에서 쿠키 동의 배너를 '클릭'하도록 할 수 있습니다.
스크립트 탭으로 이동하여 스크립트를 추가합니다. 다음 스크립트는 테스트할 URL로 이동한 후 id=cookieButton가 있는 DOM 요소를 클릭합니다.
combineSteps
navigate %URL%
clickAndWait id=cookieButton
이 스크립트를 사용할 때는 다음 사항에 유의하세요.
combineSteps는 WebPageTest에 단일 trace 및 측정 집합으로 따르는 스크립팅 단계의 결과를 '결합'하도록 지시합니다.combineSteps없이 이 스크립트를 실행하는 것도 유용할 수 있습니다. 별도의 트레이스를 사용하면 쿠키 수락 전이나 후에 리소스가 로드되었는지 더 쉽게 확인할 수 있습니다.%URL%는 테스트 중인 URL을 참조하는 WebPageTest 규칙입니다.clickAndWait는attribute=value로 표시된 요소를 클릭하고 후속 브라우저 활동이 완료될 때까지 대기하도록 WebPageTest에 지시합니다.clickAndWait attribute=Value형식을 따릅니다.
이 스크립트를 올바르게 구성했다면 WebPageTest로 찍은 스크린샷에 쿠키 참고사항이 표시되지 않아야 합니다. 즉, 쿠키 참고사항이 수락되었습니다.
WebPageTest 스크립팅에 관한 자세한 내용은 WebPageTest 문서를 참고하세요.
쿠키 설정
쿠키 집합으로 WebPageTest를 실행하려면 고급 탭으로 이동하여 맞춤 헤더 필드에 쿠키 헤더를 추가합니다.
테스트 위치 변경
WebPageTest에서 사용하는 테스트 위치를 변경하려면 고급 테스트 탭에 있는 위치 테스트 드롭다운을 클릭하세요.
Lighthouse로 쿠키 알림 테스트
Lighthouse 실행에서 쿠키를 설정하면 Lighthouse에서 테스트하기 위해 페이지를 특정 상태로 전환하는 메커니즘의 역할을 할 수 있습니다. Lighthouse의 쿠키 동작은 컨텍스트 (DevTools, CLI 또는 PageSpeed Insights)에 따라 약간 다릅니다.
DevTools
DevTools에서 Lighthouse를 실행할 때는 쿠키가 삭제되지 않습니다. 하지만 다른 유형의 저장소는 기본적으로 삭제됩니다. 이 동작은 Lighthouse 설정 패널의 Clear Storage 옵션을 사용하여 변경할 수 있습니다.
CLI
CLI에서 Lighthouse를 실행하면 새 Chrome 인스턴스가 사용되므로 기본적으로 쿠키가 설정되지 않습니다. CLI에서 특정 쿠키 세트로 Lighthouse를 실행하려면 다음 명령어를 사용합니다.
lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"
Lighthouse CLI에서 커스텀 요청 헤더를 설정하는 방법에 대한 자세한 내용은 인증된 페이지에서 Lighthouse 실행을 참조하세요.
PageSpeed Insights
PageSpeed Insights에서 Lighthouse를 실행하면 새 Chrome 인스턴스가 사용되며 쿠키는 설정되지 않습니다. PageSeed Insights는 특정 쿠키를 설정하도록 구성할 수 없습니다.
사용자 환경
서로 다른 쿠키 동의 알림의 사용자 환경 (UX)은 주로 두 가지 결정의 결과입니다. 페이지 내 쿠키 알림의 위치와 사용자가 사이트의 쿠키 사용을 맞춤설정할 수 있는 정도입니다. 이 섹션에서는 이러한 두 가지 결정에 대한 잠재적 접근 방식을 설명합니다.
쿠키 참고사항의 잠재적인 디자인을 고려할 때는 다음과 같은 사항을 고려해야 합니다.
- UX: 만족스러운 사용자 환경인가요? 이 특정 디자인이 기존 페이지 요소 및 사용자 플로우에 어떤 영향을 미칠까요?
- 비즈니스: 사이트의 쿠키 전략은 무엇인가요? 쿠키 참고사항의 목표는 무엇인가요?
- 법적 요건: 현지 법규를 준수하나요?
- 엔지니어링: 구현하고 유지하는 데 얼마나 많은 작업이 필요할까요? 변경하기가 얼마나 어려운가요?
위치
쿠키 참고사항은 헤더, 인라인 요소 또는 바닥글로 표시될 수 있습니다. 모달을 사용하여 페이지 콘텐츠 상단에 표시하거나 전면 광고로 게재할 수도 있습니다.
헤더, 바닥글 및 인라인 쿠키 참고사항
쿠키 참고사항은 일반적으로 머리글이나 바닥글에 배치됩니다. 이 두 옵션 중 바닥글 배치는 눈에 거슬리지 않고 배너 광고 또는 알림과 경쟁하지 않으며 일반적으로 CLS를 유발하지 않기 때문에 일반적으로 권장됩니다. 또한 개인정보처리방침 및 이용약관을 배치하는 일반적인 위치입니다.
인라인 쿠키 알림은 옵션이지만 기존 사용자 인터페이스에 통합하기 어려울 수 있으므로 드문 일입니다.
모달
모달은 페이지 콘텐츠 상단에 표시되는 쿠키 사용 동의 알림입니다. 모달은 크기에 따라 모양과 작동 방식이 매우 다를 수 있습니다.
더 작은 부분 화면 모달은 레이아웃 변경을 유발하지 않는 방식으로 쿠키 알림을 구현하는 데 어려움을 겪는 사이트에 좋은 대안이 될 수 있습니다.
반면에 페이지 콘텐츠 대부분을 가리는 대형 모달은 신중하게 사용해야 합니다. 특히 소규모 사이트의 경우 콘텐츠가 가려진 낯선 사이트의 쿠키 참고사항을 수락하기보다는 사용자가 이탈할 수도 있습니다. 두 개념이 반드시 동의어인 것은 아니지만, 전체 화면 쿠키 동의 모달의 사용을 고려하고 있다면 쿠키 월에 관한 법률을 숙지해야 합니다.
구성 가능성
쿠키 참고사항 인터페이스를 통해 사용자는 허용되는 쿠키를 다양한 수준으로 제어할 수 있습니다.
구성 불가능
이러한 알림 스타일의 쿠키 배너는 사용자에게 쿠키를 선택 해제할 수 있는 직접적인 UX 컨트롤을 표시하지 않습니다. 대신 일반적으로 사이트의 쿠키 정책 링크를 포함하여 웹브라우저를 사용하여 쿠키를 관리하는 방법에 관한 정보를 사용자에게 제공할 수 있습니다. 이러한 알림에는 일반적으로 '닫기' 및 '수락' 버튼이 포함됩니다.
약간의 구성 가능성
이러한 쿠키 알림은 사용자에게 쿠키를 거부할 수 있는 옵션을 제공하지만 더 세부적인 제어 기능은 지원하지 않습니다. 이러한 방식의 쿠키 참고사항은 흔하지 않습니다.
완전한 구성 가능성
이러한 쿠키 참고사항을 통해 사용자는 자신이 허용하는 쿠키 사용을 구성하는 데 더 세밀하게 활용할 수 있습니다.
UX: 쿠키 사용 구성을 위한 컨트롤은 가장 일반적으로 사용자가 초기 쿠키 동의 알림에 응답할 때 실행되는 별도의 모달을 사용하여 표시됩니다. 하지만 공간이 허락하는 경우 일부 사이트의 경우 초기 쿠키 동의 알림에 이러한 컨트롤이 인라인으로 표시됩니다.
세분화: 쿠키 구성 가능성을 위한 가장 일반적인 접근 방식은 사용자가 쿠키 '카테고리'별로 쿠키를 선택하도록 허용하는 것입니다. 일반적인 쿠키 카테고리의 예로는 기능, 타겟팅, 소셜 미디어 쿠키가 있습니다.
하지만 일부 사이트는 한 걸음 더 나아가 사용자가 쿠키 단위로 선택할 수 있도록 합니다. 또는 사용자에게 보다 구체적인 제어 기능을 제공하는 또 다른 방법은 '광고'와 같은 쿠키 카테고리를 특정 사용 사례로 나누는 것입니다. 예를 들어 사용자가 '기본 광고'와 '개인 맞춤 광고'를 별도로 선택할 수 있습니다.
