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 type="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 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를 위한 꼼수들을 차곡차곡 모아 두어도 절대 개운한 기분은 아니군.

iPhone의 caching 한계값(25 Kbytes)을 넘는 치장 목적의 커다란 배경 그림은 필요 없겠지.

/* iPhone */
@media only screen and (max-device-width: 480px) {
    #page {background-image: none;}
}

정작, iPhone Simulator에서만 제대로 적용되는 것을 확인함.
그나저나, CSS3의 Media Queries는 iPhone에 내장된 Safari 말고도, Opera Mobile v9 그리고 Opera Mini v4도 지원한다.
참고 – A List Apart: Articles: Return of the Mobile Style Sheet