모든 곳에서 속도가 빠른 사이트를 개발하기란 쉬운 일이 아닙니다. 플레소라 연결된 네트워크의 품질에 영향을 줄 수 있습니다. 이는 극복하기 어려운 작업처럼 보일 수 있습니다. 이 과정을 브라우저 기능을 활용하여 로드 성능을 향상하는 방법에 대해 알아보았고, 사용자 기기의 기능 또는 네트워크 품질 연결되나요? 해결 방법은 고객 힌트를 참고하세요.
클라이언트 힌트는 수신 동의 HTTP 요청 헤더의 집합으로, 이를 통해 사용자 기기와 사용자가 연결된 네트워크의 이러한 측면에 영향을 미치기 때문입니다. 작성자: 정보 서버 측을 활용함으로써 Google이 제공하는 방법을 기기 및/또는 네트워크 상태에 따라 콘텐츠가 영향을 받습니다. 이렇게 하면 보다 포용적인 사용자 경험을 제공합니다
콘텐츠 협상이 중요
클라이언트 힌트는 콘텐츠 협상의 또 다른 방법으로, 콘텐츠 응답을 기반으로 합니다.
콘텐츠 협상의 한 가지 예는
Accept
요청 헤더에 사용하세요 브라우저가 이해하는 콘텐츠 유형과
서버가 응답을 협상하는 데 사용할 수 있습니다. 이미지 요청의 경우
Accept 헤더의 형식은 다음과 같습니다.
Accept: image/webp,image/apng,image/*,*/*;q=0.8
모든 브라우저가 JPEG, PNG 및 GIF와 같은 이미지 형식을 지원하지만 Accept는 이 경우 브라우저가 또한 WebP 및 APNG입니다. 이 정보를 사용하여 각 브라우저에 맞는 최적의 이미지 유형을 협상할 수 있습니다.
<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;
// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">
Accept와 마찬가지로 클라이언트 힌트는 콘텐츠 협상을 위한 또 다른 방법이지만
네트워크 상태 관련 컨텍스트 정보를 제공합니다. 클라이언트 힌트를 통해
사용자의 개별 상황에 따라 서버 측 성능 결정을 내릴 수 있습니다
사용자에게 중요하지 않은 리소스를
네트워크 연결 상태가 좋지 않은 사용자에게 도달할 수 있습니다. 이 가이드에서는
힌트와 이를 사용하여 콘텐츠를 더 많이 전송하는 방법
제공되어야 합니다.
서비스 선택하기
Accept 헤더와 달리 클라이언트 힌트는 마법처럼 표시되지 않습니다(
Save-Data의 경우는 예외로 합니다. 이에 대해서는 나중에 살펴보겠습니다.
최소 요청 헤더를 사용하는 경우 어떤 클라이언트 힌트를 사용할지
인코더와 디코더가 모두 데이터를 요청할 때 Accept-CH 헤더를 전송하여
리소스:
Accept-CH: Viewport-Width, Downlink
Accept-CH의 값은 사이트에 요청된 힌트를 쉼표로 구분한 목록입니다.
후속 리소스 요청의 결과를 결정하는 데 사용됩니다. 이
클라이언트가 이 헤더를 읽을 때 '이 사이트는 Viewport-Width
Downlink개의 클라이언트 힌트를 제공합니다." 구체적인 힌트 자체에 대해서는 걱정하지 마세요.
이에 대해서는 잠시 후에 살펴보겠습니다.
이러한 수신 동의 헤더는 모든 백엔드 언어로 설정할 수 있습니다. 예를 들어 PHP의
header 함수를 사용할 수 있습니다.
http-equiv
속성
<meta> 태그에서:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
모든 클라이언트 힌트
클라이언트 힌트는 사용자가 사용하는 기기와 네트워크 정보를 확인할 수 있습니다. 이 과정에서 다룬 사용할 수 있는 힌트입니다.
기기 힌트
일부 클라이언트 힌트는 사용자 기기의 특성을 설명(일반적으로 화면) 특성에 따라 다릅니다 일부는 언론사에 최적화된 미디어 리소스를 선택하는 데 도움이 될 수 있습니다. 모두 반드시 미디어 중심적인 것은 아닙니다.
이 목록을 살펴보기 전에 Google Cloud에서 사용할 수 있는 화면과 미디어 해상도를 설명합니다.
내장 크기: 미디어 리소스의 실제 크기입니다. 예를 들어 Photoshop에서 이미지를 열면 이미지 크기 대화상자에 표시된 크기가 내장 크기를 설명합니다.
밀도 수정 고유 크기: 픽셀 밀도에 맞게 수정되었습니다. 이미지의 내장 크기 나눈 다음 기기 픽셀 수 비율을 사용합니다. 다음 마크업을 예로 들어보겠습니다.
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
이 경우 1x 이미지의 고유 크기가 320x240이라고 가정해 보겠습니다.
2x 이미지의 고유 크기는 640x480입니다. 클라이언트가 이 마크업을 파싱하는 경우
화면 기기 픽셀 비율이 2인 기기 (예: Retina
화면)에서 2x 이미지가 요청됩니다. 밀도 수정 고유 크기는
640x480을 2로 나눈 값은 320x240이므로 2x 이미지는 320x240입니다.
외부 크기: CSS 및 기타 레이아웃 다음에 오는 미디어 리소스의 크기
요소 (예: width 및 height 속성)가 적용되었습니다. 시작
밀도가 수정된 이미지를 로드하는 <img> 요소가 있다고 가정해 보겠습니다.
고유 크기 320x240이지만 CSS width 및 height 속성도 있습니다.
각각 256px 및 192px의 값이 적용됩니다. 이 예에서
이 <img> 요소의 외부 크기는 256x192가 됩니다.
width: 256px;의 CSS 규칙을 적용합니다.
height: 192px;는 고유한 크기의 이미지를 320x240으로 변환합니다.
외부 크기로는 256x192까지 확대합니다.몇 가지 용어를 사용하여 기기별 클라이언트 힌트를 사용할 수 있습니다.
표시 영역 너비
Viewport-Width는 사용자 표시 영역의 너비입니다(CSS 픽셀 단위).
Viewport-Width: 320
이 힌트는 다른 화면별 힌트와 함께 사용하여 특정 화면 크기에 최적화된 이미지 처리 (자르기) (예: 방향) 현재 화면 너비에 불필요한 리소스를 생략할 수도 있습니다.
DPR
DPR는 기기 픽셀 비율의 약자로, CSS에 대한 실제 픽셀의 비율을 보고합니다.
사용자 화면의 픽셀 수:
DPR: 2
이 힌트는 화면의 이미지에 해당하는 이미지 소스를 선택할 때 유용합니다.
픽셀 밀도 (예: x 설명자 srcset
속성)을 포함해야 합니다.
너비
Width 힌트는 <img> 또는
sizes를 사용하는 <source> 태그
속성을 사용하세요.
sizes는 리소스의 외부 크기를 브라우저에 알려줍니다.
Width는 이 외부 크기를 사용하여
나타냅니다.
예를 들어 사용자가 320 CSS 픽셀 너비 화면의 페이지를 요청한다고 가정해 보겠습니다.
DPR이 2입니다. 기기가 다음을 포함하는 <img> 요소로 문서를 로드합니다.
85vw의 sizes 속성 값 (예: 모든 광고에 대해 표시 영역 너비의 85%
화면 크기). Width 힌트가 선택되면 클라이언트는
<img>의 src 요청으로 서버에 이 Width 힌트를 전달합니다.
Width: 544
이 경우 클라이언트는 너비는 표시 영역 너비의 85%(272픽셀)가 됩니다. 544픽셀인 화면의 DPR (2)을 곱한 값입니다.
이 힌트는 화면 너비를 보정할 뿐 아니라 이 중요한 부분을 레이아웃 내에서 이미지의 외재적 크기로 정보를 생성합니다. 이를 통해 두 서버 모두에 최적화된 이미지 응답을 협상할 수 있는 기회를 화면 및 레이아웃이 모두 달라집니다.
콘텐츠-DPR
화면에는 기기 픽셀 비율이 있다는 것을 이미 알고 있지만 리소스에도
자체 픽셀 비율이 있습니다. 가장 간단한 리소스 선택 사용 사례에서 픽셀은
장치와 리소스의 비율이 같을 수 있습니다. 하지만! 두 가지 모두
DPR 및 Width 헤더가 사용되는 경우 리소스의 외부 크기가
두 가지 다른 시나리오가 생성될 수 있습니다 여기서 Content-DPR 힌트가
중요한 역할을 합니다
다른 클라이언트 힌트와 달리 Content-DPR는 다음에서 사용할 요청 헤더가 아닙니다.
대신 응답 헤더 서버는 반드시 전송DPR 및
Width 힌트는 리소스를 선택하는 데 사용됩니다. Content-DPR의 값은
다음 방정식의 결과입니다.
Content-DPR = [선택한 이미지 리소스 크기] / ([Width] / [DPR])
Content-DPR 요청 헤더가 전송되면 브라우저에서 확장 방법을 파악합니다.
화면의 기기 픽셀 비율과 레이아웃에
따라 지정된 이미지를 반환합니다. 그것이 없으면,
이미지의 크기가 제대로 조정되지 않을 수 있습니다.
기기-메모리
기술적으로 기기 메모리의 일부
API, Device-Memory는
대략적인 양
메모리
현재 기기의 GiB 단위:
Device-Memory: 2
이 힌트는 메모리가 제한된 기기의 브라우저로 전송되는 경우 자바스크립트가 리소스를 많이 사용하는 콘텐츠 유형의 브라우저는 일반적으로 로드를 참조하세요. 또는 디코딩하는 데 메모리를 적게 사용하므로 더 낮은 DPR 이미지를 보낼 수 있습니다.
네트워크 힌트
Network Information API는 사용자 네트워크의 성능을 설명하는 클라이언트 힌트 카테고리 연결. 제 생각에는 이것들이 가장 유용한 힌트입니다. 이를 통해 사용자에게 맞춤 환경을 제공할 수 있는 기능이 있어야 합니다. 클라이언트에게 리소스를 할당할 수 있습니다.
RTT
힌트는 RTT 힌트를 통해 대략적인 왕복 시간(밀리초 단위)을
애플리케이션 계층의 역할을 합니다 RTT 힌트는 전송 계층 RTT와 달리
시간을 절약할 수 있습니다
RTT: 125
지연 시간이 로드 성능에서 중요한 역할을 하므로 이 힌트가 유용합니다.
RTT 힌트를 사용하면 네트워크 응답성,
이렇게 하면 전체 경험 (예:
일부 요청을 생략할 수 있습니다.
다운링크
지연 시간은 로드 성능에서 중요하지만 대역폭은 영향력이 크지만
있습니다. 초당 메가비트 (Mbps) 단위로 표현되는 Downlink 힌트는 다음을 나타냅니다.
사용자 연결의 대략적인 다운스트림 속도:
Downlink: 2.5
RTT와 함께 Downlink는 콘텐츠 표시 방식을 변경하는 데 유용할 수 있습니다.
네트워크 연결 품질에 따라 사용자에게 전송됩니다.
ECT
ECT 힌트는 유효 연결 유형을 의미합니다. 그 값은
열거된 연결 유형 목록이며 각각 연결을 설명합니다.
RTT 및 Downlink의 지정된 범위 내
값을 참조하세요.
이 헤더는 다음의 실제 연결 유형이 무엇인지 설명하지 않습니다.
예를 들어 게이트웨이가 휴대폰 기지국인지 또는 Wi-Fi 액세스인지 보고하지 않습니다.
있습니다. 대신 현재 연결의 지연 시간과 대역폭을 분석하고
가장 유사한 네트워크 프로필을 결정합니다. 예를 들어
Wi-Fi를 통해 느린 네트워크에 연결하면 ECT가 2g 값으로 채워질 수 있습니다.
이는 유효한 연결에 가장 가까운 근사값입니다.
ECT: 2g
유효한 ECT 값은 4g, 3g, 2g, slow-2g입니다. 이 힌트는
연결 품질 평가를 위한 시작점으로 사용되며
RTT 및 Downlink 힌트를 사용하여 미세 조정합니다.
데이터 저장
Save-Data는 사용자만큼 네트워크 조건을 설명하는 힌트가 아닙니다.
페이지에서 데이터를 더 적게 전송해야 한다고 명시하는 환경설정
저는 Save-Data를 네트워크 힌트로 분류하는 것을 선호합니다. 많은 것이
다른 네트워크 힌트와 유사합니다. 사용자는
지연 시간이 길고 대역폭이 낮은 환경에서 사용할 가능성이 높습니다. 이 힌트는
항상 다음과 같습니다.
Save-Data: on
Google에서 지금까지 설명한 것처럼
Save-Data
성능에 미치는 영향은 막대할 수 있습니다. 사용자가 광고를 보고
여러분에게 콘텐츠를 더 적게 보내달라고 요청하고 있습니다. 그 말을 듣고 조치를 취하면
사용자는 환영할 것입니다.
종합하기
클라이언트 힌트를 사용하여 실행하는 작업은 개발자에 따라 다릅니다. 너무나 많은 것을 여러 가지 옵션이 있습니다 아이디어를 얻을 수 있도록 Sconnie에 대한 클라이언트 힌트를 줄 수 있습니다. Timber - 가상의 목재 시골 어퍼 중서부에 위치해 있습니다. 원격 교육에서 흔히 그러하듯이 지역, 네트워크 연결은 취약할 수 있습니다. 클라이언트 힌트와 같은 테크가 사용자에게 큰 변화를 가져올 수 있습니다.
반응형 이미지
가장 간단한 반응형 이미지 사용 사례를 제외한 모든 사용 사례는 복잡해질 수 있습니다. 만약
서로 다른 화면에 동일한 이미지를 여러 가지 방식으로 처리한 및 변형이 있는 경우
어떻게 다른가요? 이러한 마크업은 매우 복잡합니다. 매우
신속하게 찾을 수 있습니다.
오해하기 쉽고 잊어버리거나 오해하기 쉽습니다.
개념 (예: sizes)
<picture>와 srcset도 훌륭한 도구이기는 하지만,
개발 및 유지 관리에 많은 시간이 소요됩니다. 우리는
생성하지만 이는 또 다른 어려움이 있습니다.
<picture> 및 srcset가 제공하는 서비스는 자동화가 필요할 만큼 복잡합니다.
이러한 작업은 그들이 제공하는 유연성을 유지하는 방식으로 수행되어야 합니다.
클라이언트 힌트는 이를 단순화할 수 있습니다. 클라이언트와 이미지 응답 협상 힌트는 다음과 같을 수 있습니다.
- 워크플로에 해당하는 경우 먼저 이미지 처리 (예:
예술 지향 이미지)
Viewport-Width힌트를 확인하세요. Width힌트와DPR힌트를 확인하여 이미지 해상도를 선택합니다. 이미지의 레이아웃 크기 및 화면 밀도에 맞는 소스 선택 (유사한srcset에서x및w설명자가 작동하는 방식).- 브라우저에서 지원하는 최적의 파일 형식 (
Accept)을 선택합니다. )을 사용하면 대부분의 브라우저에서 이 작업을 할 수 있습니다.
가상의 목재 회사 고객이 걱정했었는데, 저는 클라이언트 힌트를 사용하는 PHP의 반응형 이미지 선택 루틴 이것은 다음을 의미했습니다. 모든 사용자에게 이 마크업을 보내는 대신:
<picture>
<source
srcset="
company-photo-256w.webp 256w,
company-photo-512w.webp 512w,
company-photo-768w.webp 768w,
company-photo-1024w.webp 1024w,
company-photo-1280w.webp 1280w
"
type="image/webp"
/>
<img
srcset="
company-photo-256w.jpg 256w,
company-photo-512w.jpg 512w,
company-photo-768w.jpg 768w,
company-photo-1024w.jpg 1024w,
company-photo-1280w.jpg 1280w
"
src="company-photo-256w.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="The Sconnie Timber Staff!"
/>
</picture>
개별 브라우저 지원에 따라 다음과 같이 줄일 수 있었습니다.
<img
src="/image/sizes:true/company-photo.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="SAY CHEESY PICKLES."
/>
이 예에서 /image URL은 매개변수가 뒤에 오는 PHP 스크립트입니다.
재작성:
mod_rewrite가 필요합니다. 그것은
이미지 파일 이름과 추가 매개변수를 가져와서 백엔드 스크립트를
주어진 조건에서 가장 좋은 이미지를 선택합니다.
“그러나 <picture>와 srcset를
제공할 수 있나요?가 첫 번째 질문입니다.
어떤 면에서는 그렇습니다. 하지만 중요한 차이점이 있습니다. 고객이 미디어 응답을 작성하기 위한 힌트를 얻을 수 있지만 작업의 대부분은 이를 수행할 수 있는 서비스 (예: CDN)를 포함하여 자동화하기가 더 쉽습니다. 확인할 수 있습니다 반면에 HTML 솔루션을 사용하면 새로운 마크업을 작성하여 모든 사용 사례에 제공합니다 물론 마크업 생성을 자동화할 수 있습니다. 만약 하지만 이러한 변화에 적응해야 하는 향후 자동화 전략을 다시 논의해 보세요
클라이언트 힌트를 사용하면 무손실 고해상도
모든 조합에 적합하도록 동적으로 크기를 조절할 수 있는 이미지
설계할 수 있습니다. 고정 값을 열거해야 하는 srcset와는 달리
브라우저에서 선택할 수 있는 이미지 후보 목록을 정의하기 위해
더 유연할 수 있습니다 srcset를 사용하면 브라우저에 대략적인 세트를 제공하도록 강제합니다.
256w, 512w, 768w, 1024w 등의 변형이
는 대규모 마크업 더미 없이 모든 너비에 서비스를 제공할 수 있습니다.
물론 이미지 선택 로직을 직접 작성할 필요는 없습니다. Cloudinary
w_auto를 사용할 때 클라이언트 힌트를 사용하여 이미지 응답을 작성합니다.
매개변수,
조사 결과 중앙값 사용자가 브라우저를 사용할 때 다운로드 바이트가 42% 감소했다는 것을
클라이언트 힌트를 지원합니다.
하지만 조심해야 합니다. Chrome 67 데스크톱 버전의 변경사항으로 인해 지원 중단 교차 출처 클라이언트의 경우 힌트. 다행히 이러한 제한사항은 Chrome의 모바일 버전에는 영향을 미치지 않으며 기능에 대한 작업이 완료되면 모든 플랫폼에서 Policy가 완료되었습니다.
네트워크 속도가 느린 사용자 지원
적응형 실적은 리소스 제공 방식을 조정할 수 있다는 아이디어입니다. 정보를 기반으로 할 수 있습니다. 특히 사용자 네트워크 연결의 현재 상태에 관한 정보
Sconnie Timber의 사이트에서 Google은
네트워크가 느림, Save-Data, ECT, RTT, Downlink 헤더
살펴보겠습니다. 이 작업이 완료되면 Google은 네트워크의 품질을
더 나은 사용자를 위해 개입해야 하는지 판단하는 데 사용할 수 있는 점수
경험해 볼 수 있습니다 이 네트워크 점수는 0에서 1 사이이며, 여기서 0이(가) 가장 좋지 않습니다.
네트워크 품질이 가장 우수하며 1이(가) 최고입니다.
처음에는 Save-Data가 있는지 확인합니다. 맞으면 점수가 다음과 같이 설정됩니다.
0를 사용하는 경우
더 가볍고 빨라진 환경을 경험하세요.
그러나 Save-Data가 없으면 계속 이동하여 ECT의 값을 가중치로 적용합니다.
네트워크를 설명하는 점수를 계산하는 RTT 및 Downlink 힌트
연결 품질입니다. 네트워크 점수 생성 소스
코드
GitHub에서 제공됩니다 핵심은, 우리가 여기에서 네트워크 관련 힌트를 사용하면
일부 패션에서는 저속한 사용자에게 더 나은 환경을 제공할 수 있습니다.
네트워크
광고주가 제공하는 정보를 바탕으로 사이트가 조정되는 경우 Google에서 채택할 필요가 없습니다. '전부 아니면 전무' 접근법을 사용합니다. 어떤 리소스를 생성할지 지능적으로 결정하고 전송합니다. 반응형 이미지 선택 로직을 수정하여 더 낮은 화질로 전송할 수 있습니다. 네트워크 품질 시 로드 성능을 높이기 위해 특정 디스플레이의 이미지 좋지 않습니다
이 예에서는 클라이언트 힌트가 네트워크 속도가 느린 사이트의 성능을 개선하는 데 도움이 됩니다. 다음은 WebPagetest입니다. 클라이언트 힌트에 적응하지 못하는 느린 네트워크에서 사이트의 폭포식 구조
이제 동일한 느린 연결에서 동일한 사이트의 폭포식 구조이지만 사이트는 클라이언트 힌트를 사용하여 중요하지 않은 페이지 리소스를 제거합니다.
클라이언트 힌트가 페이지 로드 시간을 45초 이상에서 1분으로 합니다. 이 시나리오에서 클라이언트 힌트를 얻는 것은 매우 강조되며 중요한 메시지를 찾는 사용자에게 큰 도움이 될 수 있습니다. 데이터를 전송할 때 전송할 수 있습니다
또한 경험을 유지하면서 클라이언트 힌트를 사용할 수 있습니다.
이 기능을 지원하지 않는 브라우저에서도
사용할 수 있습니다. 가령 리소스를 조정하려는 경우
ECT 힌트 값을 사용하는 동시에 전체
사용하지 않는 경우 기본 값으로 대체를 설정할 수 있습니다.
다음과 같습니다.
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
여기서 "4g"는 ECT 헤더의 최고 품질 네트워크 연결을 나타냅니다.
나타냅니다. 클라이언트를 지원하지 않는 브라우저에서 $ect를 "4g"로 초기화하면
힌트는 영향을 받지 않습니다. FTW를 선택하세요.
캐시를 명심하세요!
HTTP 헤더를 기반으로 응답을 변경할 때마다
캐시가 해당 리소스에 대한 향후 가져오기를 처리하는 방식을 지정합니다. Vary
헤더는
캐시 항목을 요청 헤더의 값에 연결하므로
제공됩니다. 간단히 말해, 지정된 HTTP 응답을 기반으로 응답을 수정하는 경우
요청 헤더의 경우 거의 항상 Vary에 해당 헤더를 포함해야 합니다.
다음과 같습니다.
Vary: DPR, Width
단, 이 경우 큰 주의사항이 있습니다. 캐시 가능한 Vary가
자주 변경되는 헤더 (예: Cookie)에 대한 응답을
리소스는 사실상 캐시 불가능하게 됩니다. 이 사실을 알았으므로
RTT 또는 Downlink과 같은 클라이언트 힌트 헤더에 Vary 작업을 수행해야 합니다.
연결 요소가 몇 가지 있습니다.
응답의 경우 ECT 헤더만 입력하는 것이 좋습니다. 이렇게 하면
캐시 부적중을 최소화합니다.
물론 이는 애초에 응답을 캐시하는 경우에만 적용됩니다.
예를 들어 콘텐츠가 동적인 경우 HTML 애셋은
재방문 시 사용자 경험이 저하될 수 있습니다. 이 같은 경우에는
필요에 따라 이러한 대답을 자유롭게 수정할 수 있으며
Vary에 대해 걱정할 필요가 없습니다.
서비스 워커의 클라이언트 힌트
콘텐츠 협상은 더 이상 서버만을 위한 것이 아닙니다. 왜냐하면 서비스 워커는
클라이언트와 서버 간의 프록시 역할을 하므로 리소스가 어떻게
JavaScript를 통해 제공됩니다 여기에는 클라이언트 힌트가 포함됩니다. 서비스 워커에서
fetch 이벤트에 대한 이벤트 발생 시 event 객체의
request.headers.get
메서드를 사용하여 리소스의 요청 헤더를 읽을 수 있습니다.
self.addEventListener('fetch', (event) => {
let dpr = event.request.headers.get('DPR');
let viewportWidth = event.request.headers.get('Viewport-Width');
let width = event.request.headers.get('Width');
event.respondWith(
(async function () {
// Do what you will with these hints!
})(),
);
});
선택한 모든 클라이언트 힌트 헤더를 이 방식으로 읽을 수 있습니다. 하지만
이 정보의 일부를 얻을 수 있는 유일한 방법은 아닙니다. 네트워크별 힌트
navigator 객체의 동등한 JavaScript 속성에서 읽을 수 있습니다.
| 클라이언트 힌트 | JS 해당 |
|---|---|
| 'ECT' | `navigator.connection.effectiveType` |
| 'RTT' | `navigator.connection.rtt` |
| `데이터 저장` | `navigator.connection.saveData` |
| '다운링크' | `navigator.connection.downlink` |
| '기기-메모리' | `navigator.deviceMemory` |
이러한 API는 기능 확인이 필요한 모든 곳에서 사용할 수 없기 때문에
in
연산자:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
여기에서는 서버에서 사용하는 것과 유사한 로직을 사용할 수 있습니다. 클라이언트 힌트를 사용하여 콘텐츠를 협상하기 위해 서버가 필요하지 않습니다. 서비스 보다 빠르고 복원력이 뛰어난 환경을 제공할 수 있는 사용자가 오프라인일 때 콘텐츠를 제공해야 하는 추가 기능을 제공합니다.
요약
클라이언트 힌트를 사용하면
발전시켜 나갈 것입니다. 사용자 기기에 따라 미디어를 게재할 수 있습니다.
이러한 기능에 의존하는 것보다 반응형 이미지를 더 쉽게 제공할 수 있는 방식으로
특히 복잡한 사용 사례의 경우 <picture> 및 srcset에서 지원됩니다. 이를 통해
개발 측면의 시간과 노력을 줄일 뿐만 아니라
사용자의 화면을 타겟팅하는 방식으로 리소스, 특히 이미지
더 중요한 것은 불량한 네트워크 연결을 찾아서 우리가 보내는 내용, 그리고 보내는 방법을 수정하여 사용자를 위한 격차를 줄일 수 있습니다. 이렇게 하면 취약한 네트워크에 있는 사용자가 사이트에 더 쉽게 액세스할 수 있도록 많은 노력을 이어가고 있습니다. 서비스 워커와 결합하면 매우 빠른 속도로 오프라인 사용 설정
클라이언트 힌트는 Chrome 및 Chromium 기반에서만 사용할 수 있습니다 브라우저, 브라우저, 브라우저, 브라우저, 브라우저계 등에 이를 방해하지 않는 방식으로 이 기능을 지원하지 않는 브라우저는 클라이언트 힌트를 사용하여 모든 사용자의 기기를 인식하는 포용적이고 적응형 경험 연결되어 있는 네트워크에 영향을 미칩니다. 다른 브라우저 공급업체가 그 가치를 보고 구현하려는 의도를 보여줍니다.
리소스
- 클라이언트가 사용한 자동 반응형 이미지 힌트
- 클라이언트 힌트 및 반응형 이미지 - Chrome 변경사항 만 67세
- (클라이언트) 힌트를 받으세요. (Slides)
- Google Cloud로 빠르고 가벼운 애플리케이션 제공
Save-Data
일리야 그리고릭님, 감사합니다. 에릭 포르티스, 제프 포스닉, 요아브 Weiss, Estelle Weyl이 이 도움말에 대한 귀중한 의견과 수정에 대해 설명해 드리겠습니다.