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