JavaScript 파일을 웹페이지에 추가하는 방법은 여러 가지가 있는데, 과거엔 주로 head tag에다 추가해 줄 때가 많았으나, 이렇게 하면 브라우저가 JavaScript 파일을 다 읽어 들이는 동안 웹페이지의 렌더링이 잠깐 멈추게 되는 부작용이 있어서, 최근엔 웹페이지를 되도록 빠르게 화면에 뿌려주려고 body tag 마지막에 얹어 주는 것을 권장하고 있다.

그런데 최근 날로 웹 애플리케이션의 개발과 그 활용 방법론이 많이 알려지면서 JavaScript 파일이 점점 더 커지는 경향이 있는데, 무조건 내려받게 되는 이런 JavaScript 파일의 용량을 조금이라도 줄이려는 노력도 따라서 필요해진다. 그래서 페이지에 얹어진 JavaScript 파일 중에 특정 기능이 빈번히 사용되지 않고 특별한 경우에만 쓰이는 것이라면, 이마저도 주요 JavaScript 파일에서 빼어내 특정 조건에 따라 필요할 때만 로딩해주는 기술이 쓰일 수 있다.

jQeury에선 이럴 때에 꼭 안성맞춤인 jQuery.getScript() 함수를 제공하고 있는데, 사용법은 다음과 같다.

$.getScript("ajax/test.js", function(datatextStatusjqxhr) {
   console.log(data); //data returned 
   console.log(textStatus); //success 
   console.log(jqxhr.status); //200 
   console.log('Load was performed.');
});

jQuery를 쓰지 않고 일반 JavaScript로 구현하려면 javascript_loader.js를 참고해서 구현해 볼 수도 있다.
웹페이지 로딩 후, 필요할 때에만 특정 JavaScript 파일을 읽어 들이는 방법(이)란 제목의 글 마저 읽기 →

WebKit nightly builds가 HTML5 표준에 정의되어 있는 script 요소의 async와 defer 속성을 지원하기 시작했다는 소식.

기본적으로 웹 브라우저가 외부 자바스크립트를 불러오는 일반 script 태그를 만나게 되면, 우선 해당 스크립트를 내려받아 해석하고 실행(execute)할 때까지 웹 문서의 HTML 코드 parsing 작업을 잠시 뒤로 미룬다. 그래서 용량이 큰 스크립트를 문서 해석 초기에 만나게 되면 해당 페이지를 불러오는 속도마저 지체되는 현상을 일으키게 되어 결국 전체적 성능을 떨어뜨리는 결과를 가져오는데, 이런 성능의 병목 현상을 막기 위해 여러 다양한 꼼수들이 쓰여왔다. 이런 부작용을 근본적으로 막기 위해 소개된 것이 script 태그의 async와 defer 속성이다.

사용 예를 보면 아주 단순하다:

<script async src="myAsyncScript.js" onload="myInit()"></script>
<script defer src="myDeferScript.js" onload="myInit()"></script>

위와 같이 async 혹은 defer 된 스크립트는 문서 parsing 작업의 중단 없이 동시에 내려받게 되며, 선택적으로 onload handler를 지정해서 일반적인 초기화 작업도 진행할 수 있다.
둘의 차이를 결정짓는 중요한 것은 바로 스크립트가 실행되는 시점이 서로 다르다는 것인데, async script는 window의 load event 전 내려받는 즉시 바로 실행되는 데 반해 defer script는 문서의 parsing 작업이 끝난 후 DOMContentLoaded event 전에 문서에 삽입된 순서에 따라 실행된다.

둘의 JavaScript 실행 시점의 차이는 Peter Beverloo씨가 그린 도표를 보면 훨씬 더 명확해진다.

script가 문서를 직접 만지고 조작하거나 서로 간 로딩 순서가 중요할 때에는 defer 속성을 쓰고, 그렇지 않다면 async 속성을 써서 웹 페이지 로딩 속도를 줄일 수 있다.

앞으로 WebKit 기반 브라우저가 이 속성을 모두 지원할 예정이라지만, 이미 Firefox는 3.6 버전부터 두 속성 모두를 지원하고 있으며, Internet Explorer 역시 예전부터 defer 속성을 지원하고 있었으나 async 속성은 아직 지원하지 않는다.

결국, 큰 용량의 JavaScript로 말미암은 페이지 로딩 지체 현상을 방지하려면 두 속성의 지원 상황이 나아질 때까지 아직 꼼수가 필요하다. – 웹 브라우저의 async와 defer 속성 지원 여부 알아보기.

덧붙임(2011-2-3): HTML5 spec에 async=false 속성을 쓰면 스크립트가 삽입된 순서대로 실행되도록 하는 기능이 추가됨. async 속성의 기본값은 true.

이 글은 Friendly Bit에 실린 Lazy Loading Asyncronous Javascript의 글을 정리해 놓은 것이다.

외부 JavaScript 파일을 문서에 추가하는 방법에는 여러 가지가 있지만, 여기엔 onload event를 지연시키지 않으면서 병렬 비동기식으로 불러와서 추가하는 방법을 소개한다.

Script tag

가장 보편적으로 쓰이는 벙법이다.

<script src="http://yourdomain.com/script.js"></script>

물론, 제일 단순한 방법이지만, 비동기식(asynchronous) 파일 내려받기를 지원하지 않으며 그 만큼 onload event도 지연된다. (빨간 선은 Load event 발생 시점을 나타냄.)


느긋하게 비동기식으로 JavaScript를 웹 문서에 추가하는 방법(이)란 제목의 글 마저 읽기 →

귀가 너무 얇은 탓일까? WordPress Cache를 위한 plugin으로 여태 잘 쓰고 있던 WP Super Cache에서 Hyper Cache로 갈아탔다.

갈아타게 만든 계기는 여러 WordPress Caching plugin들을 비교한 글에서 보여준 비교적 높은 성능 때문이다.
Hyper Cache 성능 비교 결과 - 캐쉬 미사용시 때보다 837% 더 빠르다.
그런데, 처음 설치하고 나서 설정 페이지를 열어보았더니, 다음과 같은 반갑지 않은 메시지를 맞이하였다.

Hyper Cache was not able to create the folder “cache” in its installation dir. Create it by hand and make it writable.

여기서, cache 디렉토리의 권한을 설정해 주려고 Hyper Cache 공식 페이지에 나와있는대로 /wp-content/hyper-cache/cache 디렉토리를 생성해서 권한을 변경해 주었는데도 경고 메시지가 사라지지 않았다.

확인해 보니 버전이 갱신되면서 기존 캐쉬 디렉토리가 다음과 같은 위치로 바뀌었단다. :
wp-content/plugins/hyper-cache/cache

설치를 마치고 둘러본 바, 워낙 트랙픽이 저조한 곳이라 큰 차이점은 못 느겼지만, 기름칠 한 번 더 해주었다고 생각해야지. 🙂

웹에서 넓리 사용되는 PNG 그림 형식에는 크게 두 종류로 나뉘는데 PNG-8과 PNG-24 버전이 있다. 물론 PNG-24 버전은 거의 완벽한 alpha transparency 재현이 가능하지만, 잘 알려졌다시피 IE 6에서 보기 흉하게 보이는 이유 때문에, 이를 해결하기 위한 몇몇 IE 6 PNG fix 관련 JavaScript 라이브러리들이 존재한다. 하지만, 기술적 의존도와 겹쳐저서 깔끔한 해결책이 될 수 없기에 찜찜함이 남는다.

이런 상황에서, 또 하나의 해결책이 될 수 있는 방법으로 Adobe의 Fireworks를 사용 여러 단계의 부드러운 alpha transparency가 적용된 PNG-8 파일을 생성하는 법이 주목받았지만, 문제는 다른 그래픽 어플리케이션에서는 이와 같은 방법을 그대로 사용할 수 없다는 것이 제약으로 다가올 수 밖에 없다.

그래서, 다른 방법을 찾아보다 위의 글에서도 잠깐 언급되었던 터미널 도구인 pngnq에 주목.
물론 Fireworks에서 저장하는 것처럼 언제나 휼륭한 결과물을 얻을 수는 없겠지만, 대부분 만족할 만한 효과를 낼 수 있어서 대체 방법으로 충분하다. pngnq 바이너리 파일은 여러 플랫폼들을 지원하고 있는데, 불행히도 정상적인 작동을 위해서 필요한 libpng가 Mac OS X에는 기본적으로 설치되어 있지 않아서, Mac에서 libpng 설치를 위한 간단한 패키지 인스톨러를 가지고 libpng 라이브러리 설치한 후, 내려받은 pngnq 바이너리를 /usr/bin이나 /usr/local/bin에 복사해서 사용.

pngnq 설명서를 보면 얼핏 복잡해 보이지만 기본적인 사용법은 상당히 간단하다:

$pngnq [input files]

터미널에서 위와 같이 입력하면, 원래 그림의 같은 디렉토리에, 이름 뒤 -nq8.png가 붙은 새로운 alpha transparency가 적용된 PNG-8 그림 파일을 얻을 수 있다. 변환 후 PNG 압축 도구를 이용한 후 처리도 필수.

헌데, 이렇게 IE6를 위한 꼼수들을 차곡차곡 모아 두어도 절대 개운한 기분은 아니군. 🙁