자체 호스팅 타사 리소스: 좋은 점, 나쁜 점, 나쁜 점

최근 몇 년 동안 프런트엔드 프로젝트를 최적화하기 위한 플랫폼이 점점 더 많아지고 있으며 자체 호스팅 또는 타사 리소스 프록시를 위한 기회를 제공하고 있습니다. Akamai에서는 다음을 설정할 수 있습니다. 특정 매개변수 자체 생성된 URL의 경우. Cloudflare에는 Edge Workers 기술이 있습니다. Fasterzine은 할 수 있습니다 고쳐 쓰기 사이트의 기본 도메인에 있는 제XNUMX자 리소스를 가리키는 페이지의 URL입니다.

프로젝트에 사용되는 타사 서비스가 자주 변경되지 않고 이를 클라이언트에 전달하는 프로세스가 개선될 수 있다는 것을 알고 있다면 아마도 그러한 서비스를 프록시하는 것에 대해 생각하고 있을 것입니다. 이 접근 방식을 사용하면 이러한 리소스를 사용자에게 더 가까이 가져오고 클라이언트 측에서 캐싱을 보다 완벽하게 제어할 수 있습니다. 또한 이를 통해 타사 서비스의 "충돌"이나 성능 저하로 인한 문제로부터 사용자를 보호할 수 있습니다.

좋음: 성능이 향상되었습니다.

다른 사람의 리소스를 자체 호스팅하면 매우 확실한 방법으로 성능이 향상됩니다. 브라우저는 DNS에 다시 액세스할 필요가 없으며 TCP 연결을 설정하고 타사 도메인에서 TLS 핸드셰이크를 수행할 필요가 없습니다. 다음 두 수치를 비교하면 다른 사람의 리소스를 자체 호스팅하는 것이 성능에 어떤 영향을 미치는지 확인할 수 있습니다.

타사 리소스는 외부 소스에서 다운로드됩니다(다음에서 가져옴). 따라서)

타사 리소스는 사이트의 나머지 자료와 동일한 위치에 저장됩니다(다음에서 가져옴). 따라서)

브라우저가 기본 도메인과 이미 설정된 HTTP/2 연결의 데이터를 다중화하고 우선순위를 지정하는 기능을 사용한다는 사실로 인해 상황도 개선됩니다.

타사 리소스를 호스팅하지 않으면 기본 리소스와 다른 도메인에서 로드되므로 우선순위를 지정할 수 없습니다. 이로 인해 클라이언트의 대역폭을 놓고 서로 경쟁하게 됩니다. 이로 인해 페이지를 구축하는 데 중요한 콘텐츠의 로딩 시간이 이상적인 상황에서 달성할 수 있는 것보다 훨씬 길어질 수 있습니다. 여기에 이 모든 것을 잘 설명하는 HTTP/2 우선순위에 대해 이야기하세요.

외부 리소스에 대한 링크에서 속성을 사용한다고 가정할 수 있습니다. preconnect 문제 해결에 도움이 될 것입니다. 그러나 서로 다른 도메인에 대한 링크가 너무 많으면 실제로 가장 중요한 순간에 통신 회선에 과부하가 걸릴 수 있습니다.

타사 리소스를 직접 호스팅하는 경우 이러한 리소스가 클라이언트에 제공되는 방식을 정확하게 제어할 수 있습니다. 즉, 우리는 다음에 대해 이야기하고 있습니다.

• 각 브라우저에 가장 적합한 데이터 압축 알고리즘(Brotli/gzip)이 사용되는지 확인할 수 있습니다.
• 가장 잘 알려진 공급자를 사용하더라도 일반적으로 특별히 길지 않은 리소스의 캐싱 시간을 늘릴 수 있습니다(예: GA 태그에 해당하는 값이 30분으로 설정됨).

관련 콘텐츠를 캐싱 관리 전략(URL 해시, 버전 관리 등)에 통합하여 리소스의 TTL을 XNUMX년까지 연장할 수도 있습니다. 이에 대해서는 아래에서 이야기하겠습니다.

▍제XNUMX자 서비스 운영 중단 또는 종료로부터 보호

자체 호스팅 타사 리소스의 또 다른 흥미로운 측면은 타사 서비스 중단과 관련된 위험을 완화할 수 있다는 것입니다. 사용 중인 타사 A/B 테스트 솔루션이 페이지의 헤드 섹션에 로드되는 차단 스크립트로 구현되었다고 가정해 보겠습니다. 이 스크립트는 느리게 로드됩니다. 해당 스크립트를 로드하지 못하면 페이지가 비어 있게 됩니다. 로드하는 데 시간이 너무 오래 걸리면 페이지가 오랫동안 지연되어 나타납니다. 또는 프로젝트가 타사 CDN 리소스에서 다운로드한 라이브러리를 사용한다고 가정합니다. 이 리소스에 장애가 발생했거나 특정 국가에서 차단되었다고 가정해 보겠습니다. 이러한 상황은 사이트의 논리를 위반하게 됩니다.

일부 외부 서비스를 사용할 수 없을 때 사이트가 어떻게 작동하는지 알아보려면 다음의 SPOF 섹션을 사용하세요. 웹페이지 테스트.org.

webpagetest.org의 SPOF 섹션

▍브라우저에서 자료를 캐싱하는 데 문제가 있나요? (힌트: 신화입니다)

공용 CDN을 사용하면 자동으로 리소스 성능이 향상될 것이라고 생각할 수도 있습니다. 이러한 서비스는 상당히 높은 품질의 네트워크를 보유하고 있으며 전 세계에 배포되기 때문입니다. 그러나 실제로 모든 것이 조금 더 복잡합니다.

website1.com, website2.com, website3.com 등 여러 사이트가 있다고 가정해 보겠습니다. 이들 사이트는 모두 jQuery 라이브러리를 사용합니다. 예를 들어 googleapis.com과 같은 CDN을 사용하여 연결합니다. 브라우저가 라이브러리를 한 번 다운로드하고 캐시한 다음 세 사이트 모두에서 사용할 것으로 예상할 수 있습니다. 이렇게 하면 네트워크 부하를 줄일 수 있습니다. 아마도 이를 통해 어딘가에서 비용을 절약하고 리소스 성능을 향상시키는 데 도움이 될 것입니다. 실용적인 관점에서 보면 모든 것이 다르게 보입니다. 예를 들어 Safari에는 다음과 같은 기능이 있습니다. 지능형 추적 방지: 캐시는 문서 소스와 타사 리소스 소스를 기반으로 이중 키를 사용합니다. 여기에 이 주제에 대한 좋은 기사.

오래된 연구 Yahoo и 페이스북, 뿐만 아니라 최근의 исследование Paul Calvano는 예상한 만큼 리소스가 브라우저 캐시에 저장되지 않음을 보여줍니다. “프로젝트 자체 리소스와 타사 리소스의 캐싱 시간 사이에는 심각한 차이가 있습니다. 우리는 CSS와 웹 글꼴에 대해 이야기하고 있습니다. 즉, 기본 글꼴의 95%는 캐시 수명이 일주일 이상인 반면 타사 글꼴의 50%는 캐시 수명이 일주일 미만입니다! 이는 웹 개발자에게 글꼴 파일을 직접 호스팅해야 하는 강력한 이유를 제공합니다!”

결과적으로, 다른 사람의 콘텐츠를 호스팅하는 경우 브라우저 캐싱으로 인해 발생하는 성능 문제를 발견할 수 없습니다.

이제 타사 자체 호스팅의 장점을 다루었으므로 이 접근 방식의 좋은 구현과 나쁜 구현을 구별하는 방법에 대해 이야기하겠습니다.

나쁜 점: 악마는 디테일에 있다

타사 리소스를 자신의 도메인으로 자동으로 이동하는 것은 해당 리소스가 제대로 캐시되었는지 확인하지 않고는 수행할 수 없습니다.

여기서 주요 문제 중 하나는 캐싱 시간입니다. 예를 들어 버전 정보는 다음과 같이 타사 스크립트 이름에 포함됩니다. jquery-3.4.1.js. 이러한 파일은 나중에 변경되지 않으므로 캐싱에 문제가 발생하지 않습니다.

그러나 파일 작업 시 일부 버전 관리 체계를 사용하지 않으면 파일 이름은 변경되지 않은 채 내용은 변경되는 캐시된 스크립트가 오래된 것이 될 수 있습니다. 예를 들어 클라이언트가 가능한 한 빨리 받아야 하는 스크립트에 자동화된 보안 패치를 추가할 수 없기 때문에 이는 심각한 문제가 될 수 있습니다. 개발자는 캐시에서 이러한 스크립트를 업데이트하기 위해 노력해야 합니다. 또한 캐시의 클라이언트에 사용된 코드가 프로젝트의 서버 부분이 설계된 최신 버전의 코드와 다르기 때문에 애플리케이션 오류가 발생할 수 있습니다.

사실, 자주 업데이트되는 자료(태그 관리자, A/B 테스트용 솔루션)에 대해 이야기한다면 CDN 도구를 사용하여 이를 캐싱하는 것은 해결할 수 있는 작업이지만 훨씬 더 복잡합니다. 태그 관리 솔루션인 Commanders Act와 같은 서비스는 새 버전을 게시할 때 웹후크를 사용합니다. 이를 통해 CDN에서 캐시 플러시를 강제로 수행할 수 있거나 해시 또는 URL 업데이트를 강제로 수행할 수 있는 기능이 제공됩니다.

▍고객에게 적응형 자재 전달

또한 캐싱에 관해 이야기할 때 CDN에서 사용되는 캐싱 설정이 일부 타사 리소스에 적합하지 않을 수 있다는 사실을 고려해야 합니다. 예를 들어, 이러한 리소스는 사용자 에이전트 스니핑(적응형 제공) 기술을 사용하여 해당 브라우저에 특별히 최적화된 콘텐츠 버전을 특정 브라우저에 제공할 수 있습니다. 이러한 기술은 정규식이나 HTTP 헤더 정보 데이터베이스를 사용하여 브라우저 기능을 파악합니다. User-Agent. 어떤 브라우저를 사용하고 있는지 알게 되면 해당 브라우저에 맞게 설계된 자료를 제공합니다.

여기서는 두 가지 서비스를 기억할 수 있습니다. 첫 번째는 googlefonts.com입니다. 두 번째는 폴리필.io(polyfill.io)입니다. Google Fonts 서비스는 특정 리소스에 대해 브라우저 기능에 따라 다양한 CSS 코드를 제공합니다(다음을 사용하여 woff2 리소스에 대한 링크 제공). unicode-range).

다음은 다양한 브라우저에서 수행된 몇 가지 Google Fonts 쿼리 결과입니다.

Chrome의 Google Fonts 쿼리 결과

IE10에서 실행된 Google Fonts 쿼리 결과

Polyfill.io는 브라우저에 필요한 폴리필만 제공합니다. 이는 성능상의 이유로 수행됩니다.

예를 들어, 다양한 브라우저에서 다음 요청을 실행하면 어떤 일이 발생하는지 살펴보겠습니다. https://polyfill.io/v3/polyfill.js?features=default

IE10에서 실행된 요청에 대한 응답으로 34KB의 데이터가 수신됩니다. 그리고 Chrome에서 실행되는 이에 대한 답변은 비어 있습니다.

Angry: 일부 개인 정보 보호 고려 사항

이 점은 순서상 마지막이지만 매우 중요합니다. 요점은 프로젝트의 기본 도메인이나 하위 도메인에서 타사 리소스를 자체 호스팅하면 사용자의 개인 정보를 위험에 빠뜨리고 기본 웹 프로젝트에 부정적인 영향을 미칠 수 있다는 것입니다.

CDN 시스템이 올바르게 구성되지 않은 경우 도메인의 쿠키가 제XNUMX자 서비스로 전송될 수 있습니다. CDN 수준에서 적절한 필터링이 구성되지 않으면 일반적으로 JavaScript에서 사용할 수 없는 세션 쿠키( httponly), 외부 호스트로 전송될 수 있습니다.

이것이 바로 Eulerian이나 Criteo와 같은 추적기에서 발생할 수 있는 일입니다. 타사 추적 프로그램이 쿠키에 고유 식별자를 설정했을 수 있습니다. 사이트 자료의 일부인 경우 사용자가 다른 웹 리소스로 작업하는 동안 재량에 따라 식별자를 읽을 수 있습니다.

요즘 대부분의 브라우저에는 이러한 유형의 추적기 동작에 대한 보호 기능이 포함되어 있습니다. 결과적으로 추적기는 이제 기술을 사용합니다. CNAME 클로킹, 다양한 프로젝트에 대한 자체 스크립트로 가장합니다. 즉, 추적기는 사이트 소유자에게 특정 도메인의 설정에 CNAME을 추가하도록 제안합니다. 해당 도메인의 주소는 일반적으로 임의의 문자 집합처럼 보입니다.

모든 하위 도메인(예: *.website.com)에서 웹사이트 쿠키를 사용할 수 있도록 설정하는 것은 권장되지 않지만 많은 사이트에서 이를 수행합니다. 이 경우 해당 쿠키는 위장된 제XNUMX자 추적기로 자동 전송됩니다. 결과적으로 우리는 더 이상 개인 정보 보호에 관해 이야기할 수 없습니다.

또한 HTTP 헤더에서도 동일한 일이 발생합니다. 클라이언트 힌트, 생성하는 데 사용할 수 있으므로 기본 도메인으로만 전송됩니다. 디지털 지문 사용자. 사용하는 CDN 서비스가 이러한 헤더를 올바르게 필터링하는지 확인하세요.

결과

곧 타사 리소스의 자체 호스팅을 구현할 계획이라면 몇 가지 팁을 알려드리겠습니다.

• 가장 중요한 JS 라이브러리, 글꼴 및 CSS 파일을 호스팅하세요. 이렇게 하면 타사 서비스의 결함으로 인해 사이트에 필수적인 리소스를 사용할 수 없게 되어 사이트 오류나 성능 저하가 발생할 위험이 줄어듭니다.
• CDN에 타사 리소스를 캐시하기 전에 파일 이름을 지정할 때 일종의 버전 관리 시스템이 사용되는지, 새 버전을 게시할 때 CDN 캐시를 수동 또는 자동으로 재설정하여 이러한 리소스의 수명 주기를 관리할 수 있는지 확인하세요. 스크립트.
• CDN, 프록시 서버 및 캐시 설정에 주의하세요. 이렇게 하면 프로젝트나 헤더에 쿠키가 전송되는 것을 방지할 수 있습니다. Client-Hints 제XNUMX자 서비스.

독자 여러분! 프로젝트 운영에 매우 중요한 다른 사람의 자료를 서버에 호스팅하고 있습니까?

출처 : habr.com