성능과 유지 관리 용이성 측면에서 외부 스크립트를 포함 시키거나 HTML 코드와 함께 인라인으로 작성해야하는시기를 알고 싶습니다.
이것에 대한 일반적인 관행은 무엇입니까?
실제 시나리오-클라이언트 측 양식 유효성 검사가 필요한 여러 HTML 페이지가 있습니다. 이를 위해이 모든 페이지에 포함 된 jQuery 플러그인을 사용합니다. 그러나 문제는, 나는 :
감사.
답변:
이 답변이 처음 게시되었을 때 (2008), 규칙은 간단했습니다. 모든 스크립트는 외부 여야합니다. 유지 보수 및 성능 모두.
(성능은? 코드가 분리되어 있으면 브라우저에서 쉽게 캐시 할 수 있기 때문입니다.)
JavaScript는 HTML 코드에 속하지 않으며 <, 와 같은 특수 문자가 포함되어 있으면 >문제가 발생할 수도 있습니다.
요즘에는 웹 확장 성이 변경되었습니다. 여러 HTTP 요청의 대기 시간으로 인해 요청 수를 줄이는 것이 유효한 고려 사항이되었습니다. 이렇게하면 답이 더 복잡해집니다. 대부분의 경우 JavaScript 외부를 유지하는 것이 좋습니다. 그러나 특정 경우, 특히 매우 작은 코드 조각은 사이트의 HTML에 삽입하는 것이 좋습니다.
유지 관리 성은 분명히 외부를 유지하는 이유이지만 구성이 한 줄짜리 (또는 일반적으로 HTTP 오버 헤드보다 짧아서 파일을 외부로 만들 때 얻을 수있는 경우) 인라인으로 유지하는 것이 성능면에서 더 좋습니다. 각 HTTP 요청은 실행 시간 및 트래픽 측면에서 약간의 오버 헤드를 생성한다는 점을 항상 기억하십시오.
당연히이 모든 것이 코드가 두 줄보다 길고 실제로 한 페이지에만 국한되지 않는 순간에는 관련이 없습니다. 해당 코드를 재사용 할 수있는 순간을 외부 코드로 만드십시오. 그렇지 않으면 크기를보고 결정하십시오.
자바 스크립트 외부화는 yahoo 성능 규칙 중 하나입니다. http://developer.yahoo.com/performance/rules.html#external
스크립트를 항상 외부화해야한다는 강력하고 빠른 규칙은 일반적으로 좋은 방법이지만, 경우에 따라 일부 스크립트와 스타일을 인라인하고 싶을 수도 있습니다. 그러나 성능을 향상시킬 수있는 인라인 만 인라인해야합니다 (이를 측정했기 때문에).
성능에만 관심이 있다면이 스레드의 대부분의 조언이 잘못되어 SPA 시대에 점점 더 잘못되고 있습니다. 여기서 JS 코드 없이는 페이지가 쓸모 없다고 가정 할 수 있습니다. SPA 페이지로드 시간을 최적화하고 다른 브라우저에서 이러한 결과를 확인하는 데 많은 시간을 보냈습니다. 전반적으로 HTML을 다시 조정하여 성능이 향상 될 수 있습니다.
최상의 성능을 얻으려면 페이지를 2 단계 로켓으로 생각해야합니다. 이 두 단계는 대략 <head>및 <body>단계에 해당 하지만 대신 <static>및 로 생각하십시오 <dynamic>. 정적 부분은 기본적으로 가능한 한 빨리 응답 파이프를 밀어 넣는 문자열 상수입니다. 쿠키를 설정하는 미들웨어를 많이 사용하는 경우 (http 콘텐츠를 보내기 전에 설정해야 함), 원칙적으로 응답 버퍼를 플러시하고 템플릿 코드 (면도기, PHP, 등) 서버에. 이것은 어렵게 들릴 수 있지만, 사소한 것이므로 잘못 설명하고 있습니다. 짐작 하셨겠지만이 정적 부분에는 모든 자바 스크립트가 인라인되고 축소되어 있어야합니다. 그것은 다음과 같이 보일 것입니다
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>이 부분을 무선으로 전송하는 데 드는 비용이 들지 않기 때문에 클라이언트는 서버에 연결 한 후 약 5ms + 대기 시간이 걸리기 시작할 것입니다. 서버가 상당히 가까이 있다고 가정하면이 대기 시간은 20ms에서 60ms 사이 일 수 있습니다. 브라우저는이 섹션을 가져 오자마자이 섹션을 처리하기 시작하며 처리 시간은 일반적으로 20 배 이상의 전송 시간을 지배합니다. 이제이 <dynamic>부분 의 서버 측 처리를위한 상환 기간 입니다.
브라우저 (크롬, 나머지 20 % 느리게)가 인라인 jquery + signalr + angular + ng animate + ng touch + ng route + lodash를 처리하는 데 약 50ms가 걸립니다. 그것은 그 자체로도 놀랍습니다. 대부분의 웹 응용 프로그램은 인기있는 모든 라이브러리에 비해 코드가 적지 만, 많이 가지고 있다고 가정하면 클라이언트에서 대기 시간 + 100ms의 처리 시간을 얻습니다 (이 대기 시간 승리는 두 번째 전송 청크에서 발생합니다). 두 번째 청크가 도착할 때까지 모든 js 코드와 템플릿을 처리했으며 DOM 변환을 시작할 수 있습니다.
이 방법이 인라인 개념과 직교한다고 반대 할 수도 있지만 그렇지 않습니다. 인라인 대신 cdns 또는 자신의 서버에 연결하는 경우 브라우저는 다른 연결을 열고 실행을 지연시켜야합니다. 이 실행은 기본적으로 무료이므로 (서버 측이 데이터베이스와 통신하기 때문에) 이러한 점프는 점프하지 않는 것보다 비용이 많이 든다는 것이 분명해야합니다. 외부 js가 더 빠르게 실행된다는 브라우저 문제가 있다면 어떤 요소가 지배적인지 측정 할 수 있습니다. 내 측정에 따르면이 단계에서 추가 요청이 성능을 저하시키는 것으로 나타났습니다.
SPA 앱의 최적화 작업을 많이합니다. 사람들은 데이터 볼륨이 큰 문제라고 생각하지만 일반적으로 지연 시간이 길고 실행이 지배적이라고 생각하는 것이 일반적입니다. 내가 나열된 축소 된 라이브러리는 최대 300kb의 데이터를 추가하며 2mbit 3g / 4g 전화에서 68kb gzipped 또는 200ms 다운로드로 동일한 데이터를 가지고 있는지 확인하기 위해 동일한 전화에서 걸리는 대기 시간입니다. 모바일 대기 시간 세금 (전화 대 타워 대기 시간)이 여전히 적용되기 때문에 프록시 캐시 된 경우에도 캐시에 이미 저장되어 있습니다. 한편, 첫 번째 홉 대기 시간이 짧은 데스크톱 연결은 일반적으로 더 높은 대역폭을 갖습니다.
요컨대, 지금 (2014), 모든 스크립트, 스타일 및 템플릿을 인라인하는 것이 가장 좋습니다.
편집 (2016 년 5 월)
JS 응용 프로그램이 계속 커지고 페이로드 중 일부가 이제 최대 3MB 이상의 축소 코드를 쌓을 때 최소한 공통 라이브러리가 더 이상 인라인되지 않아야한다는 것이 분명해졌습니다.
한 페이지 에만 해당하는 짧은 스크립트 사례 는 인라인 스크립트에 대한 (단지) 방어 가능한 사례 라고 생각합니다.
사실, 인라인 자바 스크립트를 사용하는 꽤 확실한 경우가 있습니다. js가 충분히 작 으면 (한 줄짜리) 두 가지 요인 때문에 자바 스크립트 인라인을 선호하는 경향이 있습니다.
항상 외부 스크립트를 사용해야하는 또 다른 이유는 컨텐츠 보안 정책 (CSP)으로 쉽게 전환하기 위함 입니다. CSP는 기본적으로 모든 인라인 스크립트를 금지하여 사이트를 XSS 공격에 더욱 강하게 만듭니다.
JavaScript를 외부에 유지하는 요점 :
ASP.NET 3.5SP1은 최근 Composite 스크립트 리소스를 생성하는 기능을 도입했습니다 (많은 js 파일을 하나로 병합). 이것에 대한 또 다른 이점은 웹 서버 압축이 켜져있을 때 약간 큰 파일 하나를 다운로드하면 더 작은 압축 파일 (http 오버 헤드, 라운드 트립 등)보다 작은 압축 비율이 더 좋아집니다. 초기 페이지로드를 절약 한 다음 위에서 언급 한대로 브라우저 캐싱이 시작됩니다.
ASP.NET 외에도이 스크린 캐스트는 다음과 같은 이점을 자세히 설명합니다. http://www.asp.net/learn/3.5-SP1/video-296.aspx