OSCON 네째날 III – 웹 사이트 성능 향상

OSCON에서는 단순히 오픈 소스만 다루는 것이 아니라 웹 서비스와 연관되어 있기 때문에 상대적으로 웹과 관련된 세션도 적지 않은 비중을 차지하고 있습니다.

오늘은 이 블로그 독자들의 비중이 높은 “Front-end” 개발자를 위한 세션 두개에 들어갔습니다. 하나는 CSS를 통한 자바스크립트 UI 성능 향상이고 또 하나는 자바스크립트를 이용한 웹 사이트 성능 향상에 대한 것입니다.

CSS for High Performance JavaScript UI
Gavin Doughtie는 구글에서 파카사웹을 만드는 사람이고 XDraw는 JS 기반 드로잉 서비스를 만들기도 했습니다. 자바스크립트로 도형을 그리거나 하는 것은 어렵고 복잡한 코딩에 속도도 느리기 때문에 이를 위해 CSS를 이용하는 것이 편리함을 강조했습니다.

CSS로 박스, 테이블, 텍스트, 이미지 등을 그리고 크기를 바꾸거나 할 때 CSS의 기초적인 float, positioning, negative margins, relative units, pseudo-selectors 등을 사용하면 편리하게 할 수 있음을 보여 주었습니다. 즉, body {
margin: 0; padding: 0; height: 100%; width: 100%; overflow: hidden;}
으로 미리 정의해 놓고 position을 absolute로 한 후 좌표값을 계산하는 것이죠. 특히 도형을 그릴 때는 img { position: relative; width: 100%; height: 100%; } 처럼 img를 정의하고 계산하면 편리하다는 방법입니다.

자신만의 노하우를 담은 샘플 예제를 중심으로 발표를 진행했는데 곧 발표 자료를 홈페이지에 올린 답니다. 샘플을 계속해서 보여주어서 제대로 설명하기는 좀 힘들 군요.

이 친구 발표 중에 이런 이야기를 하더군요. 자기는 뭐든지 자유롭게 구현 가능한 Safari와 Webkit 엔진을 가장 좋아한다고 합니다. 특히, 요즘 웹 브라우저들로 할 수 있는 것이 많기 때문에 자신이 제시한 구현을 통해 좀 더 좋은 기능을 제공하려면 IE6를 포기하는 것도 고려해 볼만 하다는 거죠.

즉 IE7+, Firefox 3+, Safari 3+, Opera 9.5+ 등과 같이 높은 사양의 웹 브라우저만을 지원하는 것인데 만약 서비스가 매우 유용하다면 사용자들이 바꿀 것이라는 겁니다. (즉, IE6이 문제가 아니라 개발자 우리 자신에게 문제가 있는 것이라는 이야기입니다.)

Even Faster Web Sites
이 세션을 진행한 구글에 계신 Steve Souders 이름을 들어본 분이 많을 겁니다. 야후!에 웹 서비스 기술 책임자로 있을 때 14가지 웹 서비스 성능 최적화 기법이라는 것을 소개하고 High Performance Web Sites라는 책도 발간하셨던 유명한 분입니다. 특히, Firebug 기반의 Y!Slow라는 퍼포먼스 측정 도구를 만드신 분이기도 합니다.

그의 성능 향상의 결론은 바로 ‘프론트 엔드의 자바스크립트를 경량화’하라는 것입니다. 그의 이야기에 따르면 서버 기반 코드가 생성되는 것은 전체 웹 로딩 속도의 10%에 불과하고 80~90%는 프론트 엔드 코드의 렌더링에 따른 것이고 아무리 백엔드 코드 성능을 향상 시켜도 사용자 체감 속도는 별로 안높아진다는 겁니다.

이번 세션에서는 이전의 14가지 기법을 재탕하는 것은 아니구요. 새롭게 2탄으로 추가된 내용입니다.

기존의 1탄

새로운 2탄

2탄에 있는 10가지를 다 알려 주면 얼마나 좋겠습니까마는 이번 세션에서는 앞의 3가지만 해준다고 합니다. 2탄의 대부분은 자바스크립트에 관한 것인데 그 이유는 자바스크립트가 문제의 대부분이기 때문에 그렇다고 합니다. 그가 Y!Slow를 통해 여러 웹 사이트의 문제점을 보여주었는데 로딩 타임의 대부분이 자바스크립트 병목에서 오고 있었습니다. (Cuzillan의 결과 참조)

로딩 부담을 나눠라! Split the initial payload
첫번째 방법은 js파일의 로딩 부담을 나누라는 것입니다. js파일을 웹 페이지가 렌더링 되는 중간 중간 나눠서 로딩하고 이를 위해 doloto같은 도구를 이용하라고 조언 합니다.

중단 없이 스크립트를 읽어라! Load scripts without blocking
대개 js파일은 대개 직렬적으로 읽고스타일 시트가 로딩 되는 동안 다른 것이 block 되는 등 초기의 여러 조건에 따라 로딩 속도가 차이가 나게 되는데 이를 위해 block이 되는 조건을 잘 찾아서 적절한 방법을 사용하라고 조언 합니다.

이를 위해 대개 다음 6가지 방법을 제시했습니다. (상세한 방법론은 PT에 있는데 밖으로 유출하지 말라는 구글 회사 계약 내용 때문에 웬만하면 사진을 찍지말라고 했지만 제가 찍긴 했습니다. 필요하시면 저에게 메일로 알려주시길…)

  1. XHR Eval (must have same domain as page)
  2. XHR Injection (same domain)
  3. Script in iFrame (same domain)
  4. Script DOM Element (domains can differ)
  5. Script Defer (only supported in IE, domains can differ)
  6. document.write (not recommended, parallelization only works in IE)

그런데 위의 기능을 사용하는 데 있어서도, 웹 페이지에 따라 스크립트와 CSS 파일의 위치와 로딩 순서 등 몇 가지 조건이 있고 조건에 따라 다른 방법을 사용해야 한다고 합니다. 가급적 Cuzillan과 Y!Slow를 이용해서 자신의 웹 페이지에 있는 css, javascript 등의 로딩 순서를 한번 체크해 보고 가장 맞는 방법으로 최적화 하는 것이 좋겠습니다.

인라인 스크립트를 남발하지 말라! Don’t scatter inline scripts
Firefox에서는 스타일 시트가 스크립트의 병렬 다운로드를 막고, IE는 인라인 스크립트에서 스타일시트를 막습니다. 따라서 가급적 인라인 스크립트를 안쓰는 게 좋다는 이야기입니다. 방법은 인라인 스크립트를 스타일시트 위에서 먼저 실행하거나 또는 @import를 쓰지 말고 link로 css를 부르는 것이 좋습니다.

그 밖에 Mozilla 프로젝트가 Firebug 개발을 지원하기 시작했고, Firebug Light 버전과 HTTPWatch for Firefox이 출시된다는 점을 소개했습니다. 아마 이분 위의 10가지를 가지고 책하나 더 쓰실 예정인가 봅니다.

여러분의 생각

  1. 좋은 내용 잘 보았습니다.
    갖가지 현란함에 눈을 뗄수가 없네요
    그동안 그냥 보기만 하다가 남기네요.^ ^;

의견 쓰기

이름* 이메일* 홈페이지(선택)