인라인과 외부 자바 스크립트는 언제 사용해야합니까?
성능과 유지 관리 용이성 측면에서 외부 스크립트를 포함 시키거나 HTML 코드와 함께 인라인으로 작성해야하는시기를 알고 싶습니다.
이것에 대한 일반적인 관행은 무엇입니까?
실제 시나리오-클라이언트 측 양식 유효성 검사가 필요한 여러 HTML 페이지가 있습니다. 이를 위해이 모든 페이지에 포함 된 jQuery 플러그인을 사용합니다. 그러나 문제는, 나는 :
- 이 스크립트를 인라인으로 구성하는 코드를 작성 하시겠습니까?
- 이 모든 HTML 페이지에서 공유하는 하나의 파일에 모든 비트를 포함 하시겠습니까?
- html 페이지마다 하나씩 별도의 외부 파일에 각 비트를 포함 시킵니까?
감사.
이 답변이 처음 게시되었을 때 (2008), 규칙은 간단했습니다. 모든 스크립트는 외부 여야합니다. 유지 보수 및 성능 모두.
(성능은? 코드가 분리되어 있으면 브라우저에서 쉽게 캐시 할 수 있기 때문입니다.)
JavaScript는 HTML 코드에 속하지 않으며 <, 와 같은 특수 문자가 포함되어 있으면 >문제가 발생할 수도 있습니다.
요즘에는 웹 확장 성이 변경되었습니다. 여러 HTTP 요청의 대기 시간으로 인해 요청 수를 줄이는 것이 유효한 고려 사항이되었습니다. 이렇게하면 답이 더 복잡해집니다. 대부분의 경우 JavaScript 외부를 유지하는 것이 좋습니다. 그러나 특정 경우, 특히 매우 작은 코드 조각은 사이트의 HTML에 삽입하는 것이 좋습니다.
유지 관리 성은 분명히 외부를 유지하는 이유이지만 구성이 한 줄짜리 (또는 일반적으로 HTTP 오버 헤드보다 짧아서 파일을 외부로 만들 때 얻을 수있는 경우) 인라인으로 유지하는 것이 성능면에서 더 좋습니다. 각 HTTP 요청은 실행 시간 및 트래픽 측면에서 약간의 오버 헤드를 생성한다는 점을 항상 기억하십시오.
당연히이 모든 것이 코드가 두 줄보다 길고 실제로 한 페이지에만 국한되지 않는 순간에는 관련이 없습니다. 해당 코드를 재사용 할 수있는 순간을 외부 코드로 만드십시오. 그렇지 않으면 크기를보고 결정하십시오.
자바 스크립트 외부화는 야후 성능 규칙 중 하나입니다 : 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 월)
As JS applications continue to grow, and some of my payloads now stack up to 3+ megabytes of minified code, it's becoming obvious that at the very least common libraries should no longer be inlined.
i think the specific to one page, short script case is (only) defensible case for inline script
Actually, there's a pretty solid case to use inline javascript. If the js is small enough (one-liner), I tend to prefer the javascript inline because of two factors:
- Locality. There's no need to navigate an external file to validate the behaviour of some javascript
- AJAX. If you're refreshing some section of the page via AJAX, you may lose all of your DOM handlers (onclick, etc) for that section, depending on how you binded them. For example, using
jQueryyou can either use theliveordelegatemethods to circumvent this, but I find that if the js is small enough it is preferrable to just put it inline.
Another reason why you should always use external scripts is for easier transition to Content Security Policy (CSP). CSP defaults forbid all inline script, making your site more resistant to XSS attacks.
I would take a look at the required code and divide it into as many separate files as needed. Every js file would only hold one "logical set" of functions etc. eg. one file for all login related functions.
Then during site developement on each html page you only include those that are needed. When you go live with your site you can optimize by combining every js file a page needs into one file.
The only defense I can offer for inline javascipt is that when using strongly typed views with .net MVC you can refer to c# variables mid javascript which I've found useful.
Three considerations:
- How much code do you need (sometimes libraries are a first-class consumer)?
- Specificity: is this code only functional in the context of this specific document or element?
- Every code inside the document tends to make it longer and thus slower. Besides that SEO considerations make it obvious, that you minimize internal scripting ...
External scripts are also easier to debug using Firebug. I like to Unit Test my JavaScript and having it all external helps. I hate seeing JavaScript in PHP code and HTML it looks like a big mess to me.
On the point of keeping JavaScript external:
ASP.NET 3.5SP1 recently introduced functionality to create a Composite script resource (merge a bunch of js files into one). Another benefit to this is when Webserver compression is turned on, downloading one slightly larger file will have a better compression ratio then many smaller files (also less http overhead, roundtrip etc...). I guess this saves on the initial page load, then browser caching kicks in as mentioned above.
ASP.NET aside, this screencast explains the benefits in more detail: http://www.asp.net/learn/3.5-SP1/video-296.aspx
Another hidden benefit of external scripts is that you can easily run them through a syntax checker like jslint. That can save you from a lot of heartbreaking, hard-to-find, IE6 bugs.
In your scenario it sounds like writing the external stuff in one file shared among the pages would be good for you. I agree with everything said above.
During early prototyping keep your code inline for the benefit of fast iteration, but be sure to make it all external by the time you reach production.
I'd even dare to say that if you can't place all your Javascript externally, then you have a bad design under your hands, and you should refactor your data and scripts
Google has included load times into it's page ranking measurements, if you inline a lot, it will take longer for the spiders to crawl thru your page, this may be influence your page ranking if you have to much included. in any case different strategies may have influence on your ranking.
well I think that you should use inline when making single page websites as scripts will not need to be shared across multiple pages
Always try to use external Js as inline js is always difficult to maintain.
Moreover, it is professionally required that you use an external js since majority of the developers recommend using js externally.
I myself use external js.
참고URL : https://stackoverflow.com/questions/138884/when-should-i-use-inline-vs-external-javascript
'IT story' 카테고리의 다른 글
| 직렬화 가능이란 무엇입니까? (0) | 2020.07.09 |
|---|---|
| Ubuntu 11.04에서 R 패키지를 설치할 수 없습니다. (0) | 2020.07.09 |
| 텍스트 파일을 Windows 명령 줄과 연결하여 선행 줄 삭제 (0) | 2020.07.09 |
| 유닉스에서 지난 1 시간 동안 생성 된 파일을 찾는 방법 (0) | 2020.07.09 |
| Angular 2 서비스에서 Observable 생성 및 반환 (0) | 2020.07.09 |