본문 바로가기
읽은 책

Even Faster Web Sites

by 쑤구니 2010. 7. 2.

Even Faster Web Sites book cover

High Performance Web Site의 후속편이라고 할 수 있는 책. 아직 읽고 있는 중이긴 하지만, 전체적인 구성이 그다지 깔끔해 보이지 않는다. 전체 14장 중 절반 정도는 script와 관련된 성능 얘기이고 뒷 부분은 전작에서 다루지 못했던 front-end 관련된 성능 이슈들이다. 3개 chapter 정도 읽었는데(관심 부분만 먼저 골라 읽는 중) 뭔가 확실한 솔루션을 내놓기 보다는, 문제가 있고 이렇게 하면 된다 식의 개략적인 언급만 하고 있어 아쉬운 부분들이 있다.

성능이라는 이슈, 특히 웹의 front-end에서의 성능은 너무나 다양한 요인들에 의해 영향을 받게 된다. 더군다나 이러한 요인들을 정확히 측정할 수 없는 현실이 가진 한계도 존재하는 상황에서, 아쉬운 점들이 있긴 하지만 이 정도로 정리된 책이 있다는 점은 다행인듯. 그래서 강추! 물론 High Performance Web Site를 먼저 읽어 볼 것!

참고로 저자는 Steve Souders이지만 6개의 chapter들은 개별 저자들에 의해 작성되어 있다.

요약

1. Understanding Ajax Performance

2. Creating Responsive Web Applications

  • 충분히 빠르다는 의미는? Jakob Nielsen의 내용을 인용. http://www.useit.com/papaers/responsetime.html
  • Latency time(대기/응답 시간)의 측정 방법에는 수작업과 자동화된 툴 이용 방법 있다. 수작업은 실행 코드에 시간 측정 코드를 추가하는 것을 의미. 자동화된 툴은 profiler를 의미하며 Firebug가 가장 많이 알려져 있음. Profiler를 사용할 경우 그 자체도 응답 시간에 영향 주므로 주의해야 한다. 하지만 percent의 상대적 측정값을 사용하면 의미 있는 결과 얻을 수 있다.
  • 궁극적으로 응답 속도를 높이기 위해서는 다중 쓰레드로 실행되게 해야 하지만, JavaScript에서는 이를 지원하지 않는다. 대신 HTML5의 Web Workers를 이용할 수 있고, 이를 지원하지 않는 브라우저에서는 Google Gears를 이용하면 된다. Web Workers API는 Google Gears에 영향을 받아 만들어진 표준이다. 이들을 모두 사용하지 못하는 경우에는 timer를 이용하여 흉내를 낼 수 있으나, 현재 컴퓨터들이 대부분 multi-core로 되어 있어, 오히려 효과가 반감될 수 있다.
  • 효과적으로 메모리를 사용하는 것도 필요하다.

3. Splitting the initial payload

미리 로딩되는 JavaScript 코드는 초기 페이지 렌더링에 사용되는 것과 그렇지 않은 것들이 있다. 대부분의 웹사이트들에서 미리 로딩되는 JavaScript 코드의 75%가 초기 페이지 렌더링에 사용되지 않으며, 따라서 이를 분리하여 페이지 로딩 완료 후에 로딩하도록 하는 것이 좋다. Doloto는 이와 관련된 분석 도구로 자동으로 코드를 분리해 준다. 수동으로 수행할 경우 페이지 로딩시 사용자의 반응에 따라 문제가 생길 수 있는데, inline 이벤트 핸들러가 걸려 있을 경우가 그러하다. 이 경우 undefined symbol 에러가 발생할 수 있고, 이를 해결하기 위한 방법은 1. 로딩중 UI 적용, 2. lazy-loaded code 사용 3. stub function 사용 으로 나눠볼 수 있다. 개인적으로는 Unobtrusive JavaScript 관점에서 2번 추천함.

...