호스팅 된 스크립트의 장단점 [닫기]

일부 개발자는 호스팅 스크립트를 사용하여 라이브러리를 연결하는 것을 보았습니다.

cdn.jquerytools.org 하나의 예입니다.

또한 사람들이 호스팅 된 스크립트 링크가 도용 당했다고 불평하는 것을 보았습니다.

실제로 호스팅 된 스크립트를 사용하는 것이 얼마나 안전합니까? 스크립트가 자동으로 업데이트됩니까? 예를 들어, jQuery 5가 6으로 이동하면 자동으로 버전 6을 얻거나 링크를 업데이트해야합니까?

또한 Google에는 호스팅을위한 이러한 스크립트 설정이 많이 있습니다.

장단점은 무엇입니까?

찬성

• 스크립트가 더 빠르게로드 됩니다. 단일 도메인에서로드해야하는 리소스가 풍부 할 경우 일반적으로 브라우저가 병목 현상을 일으켜 동일한 호스트에 대한 소수의 병렬 요청 만 갖습니다. 따라서 16 개의 개별 스크립트, 여러 이미지 및 여러 CSS 문서를로드하는 경우 각 리소스의 차례가로드 될 때까지 대기합니다. (CSS와 Javascript 파일을 연결하는 방법을 확실히 살펴보십시오. 두 개의 스크립트 리소스 만로드하면 속도가 훨씬 빠릅니다.)
• 그러나 이러한 리소스를 별도의 도메인으로 분리하면 브라우저에 해당 서버에 대한 추가 연결을 여는 데 문제가 없으므로 더 많은 리소스가 동시에로드되어 페이지 실행이 빨라집니다. 또한 다른 서버가 페이지 로딩의 일부를 처리하게하여 여러 스크립트 실행 요청이있는 서버에 적합합니다.
• 또한 이러한 CDN 서버 (콘텐츠 devivery 네트워크)가 동작하도록 구성되는 대로 의 CDN. 그들은 일반적으로 쿠키가 없으며 (더 작은 패킷 크기의 경우) 자원을 제공하고 일반적으로 사용되는 자원을 캐싱하는 것과 관련이 있고 초보적인 표준과 같은 일상적인 리프팅과는 크게 관련이없는 매우 가벼운 서버로 설정됩니다 아파치 서버가 작동합니다.
• Google 또는 Akami와 같은 CDN을 사용하면 다른 이점도 있습니다. Google은 특히 전 세계에 서버를 보유하고 있으며 라우팅 시스템은 리소스 요청을 가장 가까운 지리적 사본과 페어링 할 수있을만큼 똑똑합니다. 서버가 러시아에서 jQuery.js를 Vladimir에 제공하려고 할 수 있습니다. Google은 아마도 Vladimir에서 동일한 리소스를 가지고 있기 때문에 대기 시간이 줄어 듭니다.
• 또한 많은 웹 사이트에서 이미 이러한 CDN을 사용하고 있기 때문에 사용자가 제공하는 리소스가 이미 캐시되었을 가능성이 높습니다. 서버의 jQuery.js와 Google 서버의 jQuery.js는 정확히 같은지 여부에 관계없이 동일한 파일로 취급되지 않습니다. Google에서로드하면 이전 사이트의 캐시 된 사본을 사용할 수 있습니다. 사용자가 방문했습니다.
• 파일 자체는 특히 Javascript 프레임 워크와 같은 스크립트 자원의 경우 변경되지 않습니다. 새 버전이 나오면 Google은 CDN이 계속 정상적으로 작동하고 잘못된 요청을 처리하지 않도록 이전 버전 (버그가 아무리 크든 상관없이)을 계속 호스팅합니다. 이것이 CDN 파일에 적절한 버전 번호가 붙은 이유입니다.

단점

1. CDN을 사용하지 못할 수 있습니다. 그러나 사이트가 다운되는 것보다 가능성이 적습니다. Google 및 Akami와 같은 더 큰 CDN에는 여러 계층의 페일 오버가 있습니다.
2. 자신의 서버에서로드 할 하나 또는 두 개의 리소스 만있는 경우 새 연결을 만들면 가치가 없을 수 있습니다.
3. 제공되는 파일을 제어 할 수 없으므로 사용자 정의 버전의 jQuery를 사용하거나로드하려는 다른 항목을 사용하는 것은 CDN 비용을 지불하지 않는 한입니다.

보안

이 El Stack 게시물 과 주제에 대한 충분한 인터넷 검색을 권장 합니다 . 각 CDN은 다를 수 있지만 간단히 말해서 이것이 작은 관심사라고 생각합니다.

언급되지 않은 것은 Google의 또 다른 추적 옵션입니다. 그들은이 모든 서비스를 아무런 이유없이 무료로 제공하지는 않습니다. 애드 센스와 웹 로그 분석은 충분하며 적어도 필터링 할 수 있습니다. 그것은 나의 책에서 큰 사기입니다.

장점 :

• 파일 서비스와 관련된 대역폭을 지불 할 필요가 없으며 일반적으로

단점 :

• 귀하는 사용중인 호스팅 제공 업체의 이용 가능 여부에 영향을받습니다 (어떤 이유로 든 다운 된 경우에도 다운됩니다).
• 호스팅 제공 업체가 보유한 스크립트 버전에 상관없이

CDN을 사용하면 다른 이점이 있지만 3 차 스크립트 호스팅 서비스를 사용하는 것과 직접 관련이 없습니다.

모범 사례가 진행되는 한, 페이지로드를 최적화하는 일반적인 접근 방식은 Jarrod가 언급 한 것처럼 단일 도메인에 대한 제한된 연결 수로 인해 모든 JS 자원을 번들로 묶는 것이며, 먼 미래를 설정하면 응답에서 헤더가 만료됩니다.

Jarrod가 지적한 것처럼 CDN이 이러한 혼합, 특히 인기있는 것들을 가져 오는 것은 사용자가 이미 URL에 액세스했으며 연결을 설정하지 않고도 클라이언트 캐시에서 즉시 JS 리소스를 검색 할 수 있다는 것입니다.

이를 위해 CDN을 모두 사용하고 모범 사례를 사용하면 사용자가 처음 URL에 액세스 할 때 ~ 10-50KB를 추가로 검색하지 않고 페이지를 더 빨리로드 할 수 있습니다.

내가 할 강력 추천 두 가지 이유 CDN 서비스를 사용 : 재 러드가 언급 한 단점이있다 사실,하지만 완전히 무의미하고 이미 하나의 문서로 소스를 묶는 경우, 당신은 말의 정적 jQuery를 부분을 검색하는 모든 사람을 강제로 수 있습니다 번들로 제공되는 리소스 중 하나를 업데이트 할 때마다 문서 (~ 33KB)

나는 그것이 당신에게 들리는 것이 얼마나 중요한지 모르겠지만, 거대한 사용자 기반으로 인해 대역폭이 크게 줄어들고 비용이 크게 절약되어 포르노 스트리밍 및 맥주 구매와 같은 더 시급한 문제로 전환 할 수 있습니다.

하지마

개인적으로, 나는 타사 호스팅 스크립트에 의존하지 않을 것입니다. 당신이 다른 사람들의 대본을 활용한다면 당신은 그들의 자비에 있습니다. 고려해야 할 몇 가지 사항이 있습니다.

1. 사이트가 다운되면 페이지가 시간 초과되거나 오류가 발생할 수 있습니다.
2. 그들이 사업을 중단하고 호스팅을 끄면 모든 기능을 잃어 버렸습니다.
3. 그들이 해킹 당하면 해킹 당할 수도 있습니다.
4. 크로스 사이트 스크립팅은 SSL 인증서로 혼란 스러울 수 있습니다
5. 페이지로드 시간이 크게 증가 할 수 있습니다
6. 인터페이스가 변경되면 모든 함수 호출을 수정해야합니다.

자신의 사이트에서 코드를 호스팅하는 것이 더 안전합니다. 당신은 한 번만 태워야하고 250 개의 웹 사이트를 구축하고 호스팅하면 작동을 멈춘 제 3의 부분 호스팅 스크립트를 신뢰했기 때문에 재미있게 행동하기 시작합니다.