자주 있는 일은 아니지만, 웹 페이지에 삽입될 링크를 JavaScript에서 생성해서 추가할 일이 있다면 다음과 같이 string-concatenating을 쓴 용법이 사용될 텐데,

var anchor = '<a href="' + url + '">' + text + '</a>';

String.link method를 쓰면 아래와 같이 깔끔하게 짤 수 있다.

var anchor = 'This is a link.'.link('http://appletree.or.kr');
// "<a href="http://appletree.or.kr">This is a link.</a>" 

ECMAScript 표준에는 정의되어 있지는 않지만, 오래전부터 모든 브라우저에서 지원하고 있단다.

이 밖에도 여러 특이한 JavaScript의 HTML wrapper methods가 있는데, 그 용법이 제한적이라 사용될 일은 별로 없다.

꼬리표:

 없음.

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.

아래 snippet은 Touch Events를 지원하는 iPhone/iPad에서 기존 mousedown/mouseup events를 대신하는 touchstart/touchend event 탐지 목적에 쓰일 수 있다.

if ('createTouch' in document) {
  // Touch events are supported. 
  // So we can use touch events like 'touchstart' or 'touchend' instead of mousedown/mouseup. 
}

iPad에서의 click event handling은 약간 지체되는 느낌이 있으므로, 되도록이면 대응하는 touch events를 써주는 것이 좋을 것이다.

그리고 참고로, Android에선 Touch Events를 지원하지만 위의 방법을 사용할 수 없다고 하니, 어쩔 수 없이 navigator.userAgent도 살펴봐야 한다.

function supportsTouch() {
  var android = navigator.userAgent.indexOf('Android') != -1;
  return android || !!('createTouch' in document);
}

Safari 5가 발표되면서 반가움이 컸는지 연달아 Safari 얘기만 적게 되는데, 이 번엔 새로 추가된 JavaScript event인 “beforeload” 이벤트에 관한 글을 올려 놓는다.

이 놈은 웹페이지에 포함된 모든 스크립트와 iframe, 이미지, 스타일쉬트 등 그 어떤 리소스도 읽어들이기 전에 발사되는데, Apple은 우연찮게 그 사용의 한 예시로 광고 차단에 활용할 수 있는 기술로 서술하고 있다.

자연스럽게, 위 기술은 광고 차단 목적의 AdBlock for Safari Extention에 그대로 사용되었고, 원하지 않는 광고는 그 내용을 읽어들이기도 전에 차단해버린다. 그래서 광고 도배 사이트의 경우 통신량이 줄어서 페이지 로딩 속도가 더 빨라지는 효과를 얻을 수 있다.

한편, 별로 관련이 없는 얘기일 수도 있지만, 문득 스치는 생각.
Apple은 현재 주도권을 쥐고 있는 모바일 플렛폼에서 iAd를 통해, 점점 그 파이가 커져가고 있는, 휴대장비의 광고 시장을 장악하려 한다는 것은 잘 알려진 사실. 반면, 데스크탑에선 Safari Reader를 위시한 여러 차단막 강화로 사용자들에게 “annoying ads”로부터의 해방을 도모하고 있으니 참 오묘한 형국이다.

물론, 이것은 무엇보다도 사용자 경험을 중시하려는 전략으로 생각할 수도 있는데, 과연 일반 사용자와 개발자 그리고 광고 생산자와 제공자 모두에게 지지를 얻을 수 있을지는 더 지켜볼 일이다.

결국, 광고 시장은 사용자를 향한 접근 방식의 끊임없는 변화를 모색하려 하겠지만, 이 흐름을 가지고 누가 주도권을 잡느냐에 따라 그 경쟁은 더욱 치열해질 것이란 점은 누구나 쉽게 예상할 수 있다.

아래는 Google로 찾아낸 재미난 사진. 😆

Google 회장 Eric Schmidt씨를 향상 스티브 잡스씨의 은밀한 고백.

이 글은 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를 웹 문서에 추가하는 방법(이)란 제목의 글 마저 읽기 →