웹 애플리케이션의 성능을 끌어올릴 야후! 개발자의 자바스크립트 비법

웹 개발자라면 웹 애플리케이션의 UI를 위해 자바스크립트를 많이 사용하고 있을 것이다. 웹 애플리케이션이 느리게 반응한다면 사용자는 다른 웹 사이트로 간단히 떠나 버린다. 사용자와 상호작용하며 빠른 응답성을 지닌 웹 애플리케이션을 개발해야 한다. 문제는 자바스크립트 코드가 증가할수록 웹 애플리케이션의 성능이 떨어진다는 점이다. 이 책에서는 야후!의 선임 프런트 엔드 엔지니어이자 야후! UI(YUI) 라이브러리 개발에 참여한 니콜라스 자카스가 자바스크립트 성능 최적화를 위한 방법을 제시한다. [script] 태그의 위치가 성능에 영향을 미치는 이유부터 시작해서 D- M 처리, 페이지 수명 주기, 실행 시간 개선을 위한 방법을 알려준다.




주요내용

- 문제 코드를 식별하고 더 빠른 코드로 대체하기

- 데이터 접근과 저장 방법과 스크립트 개선 방법

- D- M과 상호작용하면서도 성능 저하 없는 코드 작성하기

- 런타임 성능 개선을 위한 최적화 테크닉

- UI 응답성을 보장하기 위한 기법

- 클라이언트- 서버 통신을 더 빠르게 하는 방법

- 빌드 시스템을 이용한 파일 크기 최적화와 HTTP 압축 전송




어떤 독자를 위한 책인가?

자바스크립트를 주로 개발하고 성능 개선의 필요성을 느끼는 개발자

Ajax, HTML5 등의 웹 기술을 주로 이용하는 개발자

스마트폰의 웹 앱 개발자

1장 로딩과 실행
01 스크립트의 위치
02 스크립트 묶기
03 비차단 스크립트
지연 스크립트
동적 [script] 태그
XMLHttpRequest 스크립트 삽입
04 추천하는 비차단 패턴
YUI 3에서 쓰는 방법
LazyLoad 라이브러리
LABjs 라이브러리
05 요약

2장 데이터 접근
01 스코프 관리
스코프 체인과 식별자 해석
식별자 해석 성능
스코프 체인 확장
동적 스코프
클로저, 스코프, 메모리
02 객체 멤버
프로토타입
프로토타입 체인
중첩 멤버
객체 멤버의 값 캐시하기
03 요약

3장 DOM 스크립팅
01 브라우저 세계의 DOM
태생부터 느립니다
02 DOM 접근과 수정
innerHTML VS DOM 메서드
노드 복제
HTML 컬렉션
DOM 이동
03 리페인트와 리플로우
리플로우가 일어날 때
렌더 트리 변경을 모았다가 한 번에 처리하기
리플로우와 리페인트 최소화하기
레이아웃 정보 캐시
애니메이션할 때 요소를 흐름 밖으로 꺼내기
인터넷 익스플로러와 :hover
04 이벤트 위임
05 요약

4장 알고리즘과 흐름 제어
01 루프
루프의 종류
루프 성능
함수에 기반을 둔 반복
02 조건문
if-else VS switch
if-else 최적화
참조 테이블
03 재귀
콜 스택 제한
재귀 패턴
반복
메모이제이션
04 요약

5장. 문자열과 정규 표현식
01 문자열 병합
플러스(+) 연산자와 플러스 이퀄(+\u003d) 연산자
배열 병합
Stringprototypeconcat
02 정규 표현식 최적화
정규 표현식이 동작하는 방법
역추적 이해하기
역추적 폭주
벤치마크 시 참고할 것
정규 표현식의 효율성을 올리는 더 많은 방법
정규 표현식을 쓰지 않는 것이 좋을 때
03 문자열 트리밍
정규 표현식으로 트리밍 구현
정규 표현식 없이 트리밍 구현
장점만 취한 해결책
04 요약

6장 응답성 좋은 인터페이스
01 브라우저 UI 스레드
브라우저의 한계
얼마나 길면 너무 긴 걸까요?
02 타이머 다루기
타이머 기초
타이머 정확도
타이머를 이용한 배열 처리
할 일 나누기
코드 타이밍
타이머와 성능
03 웹 워커
워커 환경
워커 통신
외부 파일 불러오기
현실적인 사용
04 요약

7장 Ajax
01 데이터 전송
데이터 요청
데이터 보내기
02 데이터 포맷
XML
JSON
HTML
커스텀 포맷
데이터 포맷 결론
03 Ajax 성능 가이드
데이터를 캐시하십시오
당신이 쓰는 Ajax 라이브러리의 한계를 파악하십시오
04 요약

8장 프로그래밍 사례
01 이중 평가를 피하십시오
02 객체/배열 리터럴을 사용하십시오
03 작업을 반복하지 마십시오
게으른 로딩
조건에 따른 미리 읽기
04 빠른 부분을 이용하십시오
비트 연산자
내장 메서드
05 요약

9장 고성능 자바스크립트 애플리케이션 빌드와 배포
01 아파치 앤트
02 자바스크립트 파일 결합
03 자바스크립트 파일 전처리
04 자바스크립트 최소화
05 빌드 타임 VS 런타임 빌드 과정
06 자바스크립트 압축
07 자바스크립트 파일 캐시
08 캐시 문제 완화
09 콘텐츠 전송 네트워크를 사용합니다
10 자바스크립트 자원 배포
11 애자일 자바스크립트 빌드 과정
12 요약

10장 도구
01 자바스크립트 프로파일링
02 YUI Profiler
03 익명 함수
04 파이어버그
콘솔 패널 프로파일러
콘솔 API
Net 패널
05 인터넷 익스플로러 개발자 도구
06 사파리 웹 인스펙터
프로파일 패널
리소스 패널
07 크롬 개발자 도구
08 스크립트 차단
09 Page Speed
10 Fiddler
11 YSlow
12 dynaTrace
13 요약

1996년 자바스크립트가 넷스케이프 내비게이터와 함께 처음 소개되었을 때 성능은 그다지 중요하지 않았습니다. 인터넷은 초기 단계였고 항상 느렸습니다. 성능이 좋지 않은 가정용 컴퓨터에서 다이얼 업 네트워킹으로 접속하던 그 당시의 웹 서핑은 인내심을 기르는 훈련 같을 때가 많았습니다. 사용자는 웹 페이지가 로드될 때까지 기다리는 것을 당연하게 생각했고 페이지가 잘 로드되면 기꺼이 축배라도 들 기분이었습니다.
자바스크립트의 원래 목적은 웹 페이지에서 폼 입력 오류 등으로 인한 사용자의 시간 낭비를 줄이는 것이었습니다. 폼에 입력된 값이 유효한지 검사하는 등의 간단한 작업을 위해 서버까지 갔다가 돌아오는 대신 이러한 기능을 자바스크립트가 페이지에서 직접 수행했습니다. 이렇게 해서 서버까지 왕복하는 시간을 줄일 수 있었습니다. 입력할 내용이 많은 폼을 다 작성하고, 서버로 전송하고, 1분 가까이 기다렸더니 필드 하나를 잘못 입력했다는 응답을 받은 기분을 상상해 보세요. 자바스크립트는 이러한 부분에서 초기 인터넷 사용자의 시간을 많이 줄여준 공로를 인정받아야 합니다.

 

인터넷은 진화했습니다
십 년 동안 컴퓨터와 인터넷은 진화를 거듭했고, 둘 다 무척 빨라졌습니다. 프로세서의 성능은 급격하게 좋아졌고 메모리 가격은 낮아졌으며 광섬유 연결이 등장해 인터넷은 새로운 시대로 진입했습니다. 그때까지는 볼 수 없었던 빠른 연결이 일반화되어 웹 페이지에 더 많은 정보와 멀티미디어 파일을 담으면서 무거워졌습니다. 문서만 링크하던 밋밋한 웹 페이지에 다양한 디자인과 인터페이스를 담게 되었습니다. 모든 것이 변했지만 자바스크립트만 예전 그대로입니다.
서버까지의 왕복을 줄이는 용도로 쓰이던 자바스크립트가 어디에든 쓰이게 되었습니다. 예전에는 수십 줄이면 충분했던 코드가 이제는 수백 줄을 넘어서 수천 줄이 되었습니다. 페이지를 다시 불러오지 않아도 페이지의 모양을 바꿀 수 있는 DHTML과 인터넷 익스플로러 4의 등장으로 자바스크립트의 비대화는 예견된 것이었습니다. 브라우저 발전에서 가장 중요한 단계는 인터넷 익스플로러 5, 넷스케이프 내비게이터 6, 오페라에서 제각기 구현한 DHTML에 대한 통일안인 DOM(Document Object Model: 문서 객체 모델)의 등장입니다. DOM이 도입된 직후 ECMA-262 3판에서 자바스크립트의 표준화가 이루어졌습니다. 모든 브라우저가 DOM을 지원하고 같은 버전의 자바스크립트를 지원하면서 웹 애플리케이션 플랫폼이 탄생했습니다. ECMA-262에서 표준화되고 DOM 같은 공통 API가 도입되면서 자바스크립트가 많이 발전했는데도 정작 그 코드를 실행할 자바스크립트 엔진은 거의 변하지 않았습니다.

 

왜 최적화가 필요한가
수십 줄의 코드를 실행하면서 웹 페이지를 보조하던 1996년이나, 수천 줄의 코드를 실행하는 요즘이나 자바스크립트 엔진은 같습니다. 브라우저가 자바스크립트를 잘 관리하고 기반 작업에 신경썼다면 자바스크립트는 크게 성공할 수 있었을 겁니다. 브라우저가 자바스크립트에 별로 신경쓰지 않았다는 것은, 발표 당시에는 안전성과 속도를 널리 인정받았던 인터넷 익스플로러 6이 얼마 안 있어 느린 속도와 버그로 웹 애플리케이션 플랫폼으로는 최악이라는 악명을 떨치게 된 것만 봐도 알 수 있습니다.
사실 인터넷 익스플로러 6이 느려진 것이 아니라 해야 할 일이 늘어났을 뿐입니다. 2001년 인터넷 익스플로러 6이 발표되던 당시의 웹 애플리케이션은 2005년에 개발된 것에 비해 아주 단순하고 가벼웠으며 코드도 무척 짧았습니다. 코드의 양이 늘어나면서 브라우저는 자바스크립트를 잘 관리하지 않은 부작용이 눈에 띄게 드러나게 되었는데, 그 단적인 예가 인터넷 익스플로러 6의 가비지 컬렉션 루틴입니다. 인터넷 익스플로러 6의 자바스크립트 엔진은 메모리에 있는 객체가 일정 숫자까지 증가했는지 살펴서 가비지 컬렉션 시기를 결정합니다. 초기 웹 애플리케이션 개발자는 인터넷 익스플로러 6에서 정해 놓은 한계선을 넘기는 일이 드물었지만 자바스크립트 코드가 길어지면서 메모리에 남는 객체의 숫자도 늘어났고 복잡한 웹 애플리케이션은 이 한계선을 자주 넘깁니다. 문제가 무엇인지 분명해졌습니다. 자바스크립트 개발자와 웹 애플리케이션은 진화했지만 자바스크립트 엔진은 그렇지 않기 때문입니다.
다른 브라우저에서 더 논리적인 메모리 반환 루틴을 도입하고 실행 성능을 좀 더 끌어올리기는 했지만 대다수는 여전히 자바스크립트 인터프리터로 코드를 실행합니다. 코드 인터프리터는 자바스크립트 코드를 실제로 컴퓨터가 실행하는 코드로 바꿔야 하기 때문에 근본적으로 컴파일러보다 느립니다. 인터프리터를 아무리 잘 설계하고 최적화하더라도, 항상 더 느릴 수밖에 없습니다.
컴파일러는 개발자가 효율성을 걱정할 필요 없이 원하는 대로 코드를 작성할 수 있도록 온갖 종류의 최적화를 합니다. 또한 개발자가 작성한 코드를 그 언어의 문법대로 분석해서 하는 일을 알아낸 다음 컴퓨터가 실행할 수 있는 가장 빠른 저수준 언어로 바꿔줍니다. 인터프리터는 컴파일러가 하는 최적화를 거의 하지 못하므로 코드가 작성된 그대로 실행될 때가 많습니다. 결과적으로 다른 언어에서는 컴파일러가 하는 최적화 작업을 자바스크립트에서는 개발자가 직접 할 수밖에 없습니다.

 

차세대 자바스크립트 엔진
2008년 자바스크립트 엔진은 첫 번째로 성능이 향상되었는데, 구글에서 완전히 새로운 브라우저, 크롬을 발표했습니다. 크롬은 코드 최적화 기능이 있는 자바스크립트 엔진을 탑재한 최초의 브라우저입니다. 코드네임 V8이라 불리는 이 엔진은 자바스크립트 코드를 기계어로 바꿔서 실행하는(JIT) 자바스크립트 컴파일 엔진입니다. 이 엔진은 자바스크립트 실행 성능을 크게 향상시켰습니다.
다른 브라우저도 곧 독자적인 자바스크립트 최적화 엔진을 도입했습니다. 사파리 4는 적시 변환 자바스크립트 엔진 Squirrel Fish Extreme(Nitro라고도 합니다)을 선보였고 파이어폭스 3.5는 자주 실행하는 코드를 최적화하는 TraceMonkey 엔진을 도입했습니다. 새로운 자바스크립트 엔진은 당연히 최적화를 담당해야 할 곳인 컴파일러에서 최적화합니다. 언젠가는 개발자가 코드를 짜면서 성능 최적화에 신경쓰지 않아도 되는 날이 올 겁니다. 하지만 아직은 아닙니다. 아직은 성능에 신경 써야 합니다
자바스크립트 코어의 실행 시간이 많이 단축되기는 했지만 자바스크립트에는 새로운 엔진과 무관한 문제점이 있습니다. 페이지의 외관에 영향을 미치는 작업과 네트워크 지연율 때문에 생기는 지연 시간은 브라우저에서 더 개선해야 합니다. 인라인 함수, 코드 축소, 문자열 병합 알고리즘 같은 간단한 최적화는 컴파일러에서 쉽게 처리할 수 있지만, 웹 애플리케이션의 동적이고 다면적인 구조는 엔진 최적화로 쉽게 해결할 수 없는 문제이기 때문에 최적화는 성능 문제의 일부분만 해결할 수 있습니다.
새로운 자바스크립트 엔진이 등장해 훨씬 빠른 인터넷을 사용하는 미래를 상상할 수 있지만, 지금 성능을 연구하는 것도 미래에 여전히 쓸모 있고 중요할 것이라고 예견할 수 있습니다. 이 책에서는 실행 시간, 내려받기, DOM과의 상호작용, 페이지의 라이프 사이클 등 자바스크립트의 다양한 부분에 관한 테크닉과 접근 방법을 살펴봅니다. 자바스크립트 엔진이 발전하면 코어(ECMAScript) 성능에 관한 일부는 필요 없어지겠지만, 아직은 아닙니다.
다른 주제는 DOM과의 상호작용, 네트워크 지연 시간, 자바스크립트 내려받기의 두 가지 양상(차단과 병행) 등 자바스크립트 엔진이 빨라지더라도 별 도움이 되지 않는 문제에 관한 것입니다. 저수준 자바스크립트 실행 성능이 계속 향상되더라도 이러한 주제는 여전히 중요하고, 앞으로도 더 많은 관심과 연구의 대상이 될 것입니다.