자체 서버 대신 CDN에서 자바 스크립트 라이브러리를 제공하면 엄청난 이점이 있습니다. 서버에 대한 작업이 적고 CDN이 서버보다 사용자에게 더 가까운 사본을 가질 가능성이 있지만 가장 중요한 것은 사용자의 브라우저가 해당 URL에서 이미 캐시를 가지고있을 가능성이 높습니다. 마지막 것은 모든 사람의 총 작업량이 적다는 것을 의미하므로 모든면에서 분명히 승리하며 우리 (개발자)가 자바 스크립트를 제공하기 위해 CDN에 더 자주 의존 할 가능성이 높습니다.
그러나 인기있는 자바 스크립트 CDN (Google, Microsoft 등)은 적은 수의 파일 만 호스팅합니다. 다른 사람들을 위해 우리는 직접 호스팅하거나 소스 제어 서버를 일종의 CDN으로 사용하여 선택할 수 있습니다. Github 또는 이와 유사한 파일이 전역 적으로 제공되도록 최적화 된 지리적으로 분산 된 파일 캐시가있을 가능성은 거의 없습니다. 그러나 그것이 일반적인 관행이라면 사용자의 브라우저가 캐시를 가질 가능성이 있습니다. 서버에서 github로 작업을 오프 로딩한다는 주장은 Github가 자발적으로이를 수행 한 경우에만 유효합니다.
그래서, 그것은 일반적인 관행입니까? 우리는 서로를 격려해야합니까? Github가 마음에 드십니까? 공식 정책이 명시되어 있습니까?
답변
성능이나 IE9 호환성에 관심이 있다면 JavaScript 파일에 대해 그렇게해서는 안됩니다.
GitHub는 먼 미래의 만료 헤더가있는 “원시”파일을 제공하지 않습니다. 교차 사이트 캐싱의 가능성이 없으면 공용 CDN을 사용하여 JavaScript를 호스팅하는 가장 큰 이점을 잃게됩니다. 실제로 GitHub를 CDN으로 사용하는 것은 각 사용자가 파일에 대한 첫 번째 요청을 한 후 자체 서버에서 파일을 호스팅하는 것보다 느립니다 (서버에서 캐싱을 올바르게 구성했다고 가정).
또 다른 문제는 GitHub가 파일의 실제 MIME 유형과 일치하는 콘텐츠 유형 헤더가있는 “원시”파일을 제공하지 않는다는 것입니다. IE9 (및 기타 브라우저 / 프록시 / 방화벽 등)에서 올바른 콘텐츠 유형으로 제공되지 않는 JavaScript 파일은 기본적으로 차단됩니다. 예를 들어 BlockUI 데모 페이지에서 실제로 작동하는 것을 볼 수 있습니다.
답변
GitHub “원시”파일에 연결하면 Dave Ward의 답변에 설명 된대로 몇 가지 문제가 있습니다.
옵션으로 GitHub 페이지를 살펴 보는 것이 좋습니다.
이 기사 읽기 :
GitHub as a CDN. GitHub 페이지를 사용하여 자바 스크립트, 스타일 시트 및 웹 자산을 캐시합니다.
답변
이것은 최근 github의 지원 포럼에서 요청되었으며 공식적인 답변은 괜찮다는 것입니다.
github에 정말 않았다 : 나는 다른 답변에 동의했다 가졌 의미하지 구글과 마이크로 소프트가 그 특정 인프라가 동안, CDN합니다.
답변
답변
나는 지금 몇 달 동안 그것을하고 있고, 먼저 몇 가지 우려 사항이 있었지만 파일이 공개적으로 사용 가능한 데 문제가 없다면 완전히 멋지다. 걱정한다면 축소 버전을 사용하십시오.
하지만 여전히-Google과 MS가 jQuery 및 jQuery 템플릿의 공간을 지배하므로이를 위해 사용합니다.
답변
