head.js라는 Javascript를 백그라운드에서 병렬로 로딩하여 실행해 주는 라이브러리가 있다. 그 외에도 이와 같은 일을 하는 라이브러리가 몇가지 더 있다.
여기서 역할이 두 가지임에 주의해야 한다.
1. 백그라운드에서 비동기로 Javascript 적재 - 웹페이지의 표시 시점이 빨라짐
2. 순차 적재가 아닌 병렬 적재(여러 JS를 동시에 읽어 들임) - javascript 적재가 빨라짐
(기본적으로 <script>태그를 HTML 상단 즉, <head>에다 두면 HTML 표시가 느려진다는 사실은 다들 알고 계시리라...)
이번에 우리 프로젝트에서 이 라이브러리를 도입하여 속도를 높여볼까 하다가, 실제 성능 측정을 해보고는 그만 두었다.
이유는
1. 백그라운드에서 비동기 Javascript 적재는 단순히 <script> 태그를 </body> 앞으로 옮기는 것 만으로도 동일한 효과(웹페이지 표시 시점 빠르게)가 이뤄지기 때문이다.
2. Javascript 병렬 적재는 이미 IE 8을 비롯한 메이저 브라우저가 다 기본적으로 지원해 주고 있기 때문이다.
그런데 head.js 의 성능 테스트 페이지를 보면 (head.js사용시, script아래로했을시) head.js를 사용했을 때가 압도적으로 빠르게 나오는 듯 보인다.
그러나 내가 분석한 결과 저 테스트는 잘못되었다.
저 테스트에서 로딩이 끝나는 시점을 window.onload 시점으로 잡았는데, 이는 문제가 있다.
실제로 우리가 측정해야 할 시점은 1. HTML이 표시되는 시점, 2. Javascript가 사용가능해 지는 시점 이 두가지 인데, head.js 사이트의 테스트에서는 엉뚱하게 window.onload 시점을 기준으로 잡은 것이다.
head.js 사이트의 테스트를 내가 직접 해본 결과로는 IE 9 에서는 일관성있게 head.js를 사용했을 때가 빠르게 나오지만, 파이어폭스와 크롬 브라우저에서는 대중 없이 이게 빨랐다 저게 빨랐다 한다. 내가 로컬 웹서버에 웹 페이지를 만들어 올려 놓고 해봐도 마찬가지 결과가 나왔다.
그래서 나 스스로 직접 성능 테스트를 rough 하게 해 보았는데, 결과는 거의 내 예상대로 head.js 를 사용했을 때의 이득이 없었다. 테스트는 Script를 아래로 내렸을 때(즉, </body> 바로 위에 script를 두었을 때)와 head.js를 사용했을 때로 나누어서 해보았으며 HTML 출력이 끝난 시점과 javascript가 사용가능해진 상태($(document).ready() 상태 혹은 head.ready() 상태)의 시간을 측정해 보았다(아래 결과만 보고 FF가 느리다고 하지는 마시길. 내 메인 브라우저가 FF라서 플러그인만 20개 정도가 깔려있다. 다른 브라우저는 플러그인을 하나도 안 깐 상태이다. 상대적인 값만을 보시길).
위 값은 모두 각 브라우저에서 10회씩 Ctrl-Shift-R 혹은 Ctrl-F5를 눌러서 페이지를 로딩해서 나온 값의 평균이다.
* IE 9는 head.js를 사용했을 때 현저한 성능 저하를 보였다.
보면 알겠지만 어떨 때는 Script아래로 했을 때가 성능이 더 좋기도 하고 어떨 때는 head.js를 사용할 때가 더 좋게 나오기도 하지만 대체로 Script를 아래로 했을 때가 성능이 더 좋다는 것을 볼 수 있다.
내 예상대로 작동한 경우는 Chrome 뿐이다. 내 상식에 따르면 Chrome 와 같은 반응을 보이는게 옳다. 뭔지는 모르지만 각 브라우저내의 독특한 javascript를 다루는 방식이 결과에 영향을 주는 것 같다.
우리팀의 목표는 HTML 출력 시점을 앞당기는 것이므로, <script>를 아래로 두는 것이 더 적합하고, 이는 아마도 대부분의 일반적인 웹사이트들도 마찬가지 일 것이다.
아무튼 이렇게 하여 내가 내린 결과는 굳이 head.js를 써서 복잡도를 높여가며 성능을 향상시키려 애쓸 필요가 없다는 것이다.
그냥 <script> 태그를 </body>위에 두는 것 만으로도 훌륭한 효과를 볼 수 있다.
혹자는 말할것 같다. head.js에는 javascript 병렬 로딩 뿐만 아니라, 다른 JS들은 로딩 중이고, 특정 Javascript만 적재가 끝났을 때 어떠한 명령을 실행시키는게 가능하다고.
그런데.. 그걸 직접 해보시기 바란다.
내가 보기엔 유지보수 복잡도의 증가 때문에 견디기 힘들 상황이 될 듯하다.
그에 반해 얻는 속도의 이점은 고작 몇 ms 에 그칠 것이고 그나마도 브라우저 따라 오히려 느려지는 경우도 발생할 것 같다는게 내 예상이다.
자신의 사이트가 HTML보다는 Javascript를 더 많이 사용하는 (Google Map같은?) 그런 곳이라면 어쩌면 head.js를 사용하는 것이 나을지도 모른다. 하지만 내가 보기엔 HTML 출력이 더 중요한 일반적인 웹페이지에서는 저렇게 복잡도를 높여가며 Javascript 로딩 속도를 높이는게 의미가 있어보이진 않는다.
참조 : HTML5에는 async라고 head.js가 해주는 비동기 적재 역할을 표준으로 지원하는 옵션이 생겼다. 그리고 과거부터 있어온 defer라는 옵션은 <script>를 아래로 내리지 않고도 아래로 내린것과 같은 효과를 내게 해준다.(2012년 현재 모든 브라우저가 지원하지는 않고 있음)
테스트에 사용한 소스와 결과 데이터(ODS/Libre Office로 열어볼 것)는 첨부파일로 넣어 두었다.
scripttest.7z
여기서 역할이 두 가지임에 주의해야 한다.
1. 백그라운드에서 비동기로 Javascript 적재 - 웹페이지의 표시 시점이 빨라짐
2. 순차 적재가 아닌 병렬 적재(여러 JS를 동시에 읽어 들임) - javascript 적재가 빨라짐
(기본적으로 <script>태그를 HTML 상단 즉, <head>에다 두면 HTML 표시가 느려진다는 사실은 다들 알고 계시리라...)
이번에 우리 프로젝트에서 이 라이브러리를 도입하여 속도를 높여볼까 하다가, 실제 성능 측정을 해보고는 그만 두었다.
이유는
1. 백그라운드에서 비동기 Javascript 적재는 단순히 <script> 태그를 </body> 앞으로 옮기는 것 만으로도 동일한 효과(웹페이지 표시 시점 빠르게)가 이뤄지기 때문이다.
2. Javascript 병렬 적재는 이미 IE 8을 비롯한 메이저 브라우저가 다 기본적으로 지원해 주고 있기 때문이다.
그런데 head.js 의 성능 테스트 페이지를 보면 (head.js사용시, script아래로했을시) head.js를 사용했을 때가 압도적으로 빠르게 나오는 듯 보인다.
그러나 내가 분석한 결과 저 테스트는 잘못되었다.
저 테스트에서 로딩이 끝나는 시점을 window.onload 시점으로 잡았는데, 이는 문제가 있다.
실제로 우리가 측정해야 할 시점은 1. HTML이 표시되는 시점, 2. Javascript가 사용가능해 지는 시점 이 두가지 인데, head.js 사이트의 테스트에서는 엉뚱하게 window.onload 시점을 기준으로 잡은 것이다.
head.js 사이트의 테스트를 내가 직접 해본 결과로는 IE 9 에서는 일관성있게 head.js를 사용했을 때가 빠르게 나오지만, 파이어폭스와 크롬 브라우저에서는 대중 없이 이게 빨랐다 저게 빨랐다 한다. 내가 로컬 웹서버에 웹 페이지를 만들어 올려 놓고 해봐도 마찬가지 결과가 나왔다.
그래서 나 스스로 직접 성능 테스트를 rough 하게 해 보았는데, 결과는 거의 내 예상대로 head.js 를 사용했을 때의 이득이 없었다. 테스트는 Script를 아래로 내렸을 때(즉, </body> 바로 위에 script를 두었을 때)와 head.js를 사용했을 때로 나누어서 해보았으며 HTML 출력이 끝난 시점과 javascript가 사용가능해진 상태($(document).ready() 상태 혹은 head.ready() 상태)의 시간을 측정해 보았다(아래 결과만 보고 FF가 느리다고 하지는 마시길. 내 메인 브라우저가 FF라서 플러그인만 20개 정도가 깔려있다. 다른 브라우저는 플러그인을 하나도 안 깐 상태이다. 상대적인 값만을 보시길).
| 브라우저 | Script아래로 | head.js | ||
|---|---|---|---|---|
| HTML출력끝난시점 | JS사용가능상태 | HTML출력끝난시점 | JS사용가능상태 | |
| Firefox 11 | 23.3ms | 253.5ms | 40.8ms | 210.6ms |
| IE 9 | 24.5ms | 157.7ms | 19.2ms | 463.5ms |
| Chrome 17 | 8.4ms | 135ms | 15.5ms | 142.2ms |
위 값은 모두 각 브라우저에서 10회씩 Ctrl-Shift-R 혹은 Ctrl-F5를 눌러서 페이지를 로딩해서 나온 값의 평균이다.
* IE 9는 head.js를 사용했을 때 현저한 성능 저하를 보였다.
보면 알겠지만 어떨 때는 Script아래로 했을 때가 성능이 더 좋기도 하고 어떨 때는 head.js를 사용할 때가 더 좋게 나오기도 하지만 대체로 Script를 아래로 했을 때가 성능이 더 좋다는 것을 볼 수 있다.
내 예상대로 작동한 경우는 Chrome 뿐이다. 내 상식에 따르면 Chrome 와 같은 반응을 보이는게 옳다. 뭔지는 모르지만 각 브라우저내의 독특한 javascript를 다루는 방식이 결과에 영향을 주는 것 같다.
우리팀의 목표는 HTML 출력 시점을 앞당기는 것이므로, <script>를 아래로 두는 것이 더 적합하고, 이는 아마도 대부분의 일반적인 웹사이트들도 마찬가지 일 것이다.
아무튼 이렇게 하여 내가 내린 결과는 굳이 head.js를 써서 복잡도를 높여가며 성능을 향상시키려 애쓸 필요가 없다는 것이다.
그냥 <script> 태그를 </body>위에 두는 것 만으로도 훌륭한 효과를 볼 수 있다.
혹자는 말할것 같다. head.js에는 javascript 병렬 로딩 뿐만 아니라, 다른 JS들은 로딩 중이고, 특정 Javascript만 적재가 끝났을 때 어떠한 명령을 실행시키는게 가능하다고.
그런데.. 그걸 직접 해보시기 바란다.
내가 보기엔 유지보수 복잡도의 증가 때문에 견디기 힘들 상황이 될 듯하다.
그에 반해 얻는 속도의 이점은 고작 몇 ms 에 그칠 것이고 그나마도 브라우저 따라 오히려 느려지는 경우도 발생할 것 같다는게 내 예상이다.
자신의 사이트가 HTML보다는 Javascript를 더 많이 사용하는 (Google Map같은?) 그런 곳이라면 어쩌면 head.js를 사용하는 것이 나을지도 모른다. 하지만 내가 보기엔 HTML 출력이 더 중요한 일반적인 웹페이지에서는 저렇게 복잡도를 높여가며 Javascript 로딩 속도를 높이는게 의미가 있어보이진 않는다.
참조 : HTML5에는 async라고 head.js가 해주는 비동기 적재 역할을 표준으로 지원하는 옵션이 생겼다. 그리고 과거부터 있어온 defer라는 옵션은 <script>를 아래로 내리지 않고도 아래로 내린것과 같은 효과를 내게 해준다.(2012년 현재 모든 브라우저가 지원하지는 않고 있음)
테스트에 사용한 소스와 결과 데이터(ODS/Libre Office로 열어볼 것)는 첨부파일로 넣어 두었다.
scripttest.7z
덧글