사용자 인터페이스와 성능의 결합
Seb Ruiz 가 Crucible 에 대해 이야기 합니다.
Crucible 팀에서 일반적으로 직면하는 싸움 중 하나는 어마하게 많은 DOM 구조의 리뷰 보기 시 웹 브라우저의 성능문제 입니다.
저는 예전 저 의 이전 블로그 에서 어떻게 Crucible 팀이 이벤트 델리게이션과 라이브 이벤트를 사용하여 많은 페이지 요소를 가지는 오버헤드가 큰 바인드 호출을 대치하 수 있는지 언급하였습니다.
이번에는, 많은 작업을 보여주는 페이지를 처리할 때, 선능을 개선하기 위한 다른 2가지 방법을 공유하고자 합니다.
리플로(reflows) 회피
만약 여러분이 성능과 관련된 웹 개발 작업을 하였었다면, 이미 가능한 경우의 페이지 리플로(reflow)를 회피하는 개념에 대해 익숙하실 것입니다.
Steve Souders 의 말에 따르면:
리플로(reflow)는 CSS 규칙이 재적용 되는 것을 필요로 하며, 이것은 브라우저가 한번 이상 모든 CSS 셀렉터를 매칭해야 하는 것을 의미합니다.
만약 CSS 셀렉터가 효율적이지 않다면, 리플로(reflow)는 많은 시간이 소요될 것입니다. - 사용자가 인식할 만큼의 긴 시간 말입니다.
이 인용문에서, Souders는 셀렉터를 평가하는 것이 얼마나 효과적인 방법인지를 가지고 리플로(reflow)의 영향에 대해 이야기 하고 있습니다. 언급되지 않았지만, 리플로 타임 또한 그러한 스타일 규칙 (DOM 크기 같은) 을 적용하는 페이지의 항목 수에 매우 의존적입니다.
페이지에서 리플로를 발생시키는 방법은 일반적으로 많습니다만, 때로는 리플로를 구동하는 횟수를 줄이려는 시도에 대한 내용도 아셔야 할 필요가 있습니다.
만약 이전에 이런 내용을 본적이 없다면, 여기 위키피디어를 로팅할 때 페인트 액션을 보여주는 좋은 비디오가 있습니다:
(골드 피처 주) 비디오는 가져오기 기능이 되지 않아 이곳 에서 확인하시기 바랍니다. |
UI 고스팅(Ghosting)
구성요소의 차수를 변경하는 것은 분명히 리플로(reflow)를 발생시킵니다. 일반적인 Crucible 리뷰의 페이지 구조는 아래 그림과 같습니다.
우측칸은 문서 구조의 (대략 80%) 대부분을 포함합니다. 왼쪽칸은 크기가 조정될 수 있는데 이 때 두 칸 모두의 차수가 변경되며, 이것은 브라우저가 컨텐츠를 리플로(reflow) 하도록 만듭니다.
여러분의 브라우저 윈도우를 상상해 보십시요. 크기변경바를 드래그 하면, 윈도우는 자연스럽게 크기가 변경되고 거의 실시간으로 컨텐츠를 재 구성하여 업데이트 합니다. 이것은 대부분의 경우 요구되는 것이지만, 컨텐츠를 다시 그리고 계산하는 작업이 리사이즈 이벤트 사이의 시간보다 적게 소요되는 경우에만 해당합니다. (혹은 그러기에 오버헤드가 크기않은 경우)
이전 Crucible 릴리스에서는, 이 컨텐츠 사이의 스플리터(splitter)의 크기를 조정하면 바로 컨텐츠를 다시그리기 하였습니다. 그렇지만 이것은 아주 큰 데이터의 리뷰의 경우는 부분적으로 적합한 내용인데 왜냐하면 리플로(reflow) 작업이 매우 많은 시간이 걸리는 경우가 있을 수 있기 때문입니다. (거의 수백 밀리초)
우리는 이것을 깔끔한 방법으로 처리하였는데, 바로 UI 고스팅 입니다.
중복된 구성요소를 불투명하게 오버레이함으로서, 사용자가 최종 크기를 결정하기 전까지는 리플로(reflow)를 발생하지 않도록 하였습니다. 확인해 보십시요:
jQuery UI를 사용한다면, 이러한 효과를 크기변경가능한 위젯의 ghosting option을 통해 간단히 수행할 수도 있습니다.
여기 또다른 컨텐츠 채움을 요구하는 경우가 있습니다. 매우 큰 DOM 으로 인해 윈도우 크기조정에 문제가 있는 경우 대부분의 트리가 보이는 시각에서 벗어나는 경우가 있습니다.
이것은 그것을 보일 필요가 없고 바로 필요한 내용이 아닌 경우 DOM 에서 컨텐츠를 안정하게 제거할 수 있음을 의미합니다.
만약 스크롤바가 모든곳에 존재하는 것을 우려한다면, 실제 컨텐츠의 높이를 아는 동안만은, CSS 스타일로 이것을 처리할 수 있습니다.
사용자가 페이지를 스크롤할 때, 바로 보이는 부분에 근거하여 컨텐츠를 추가 혹은 삭제할 수 있습니다.
더욱 편리한 접근을 위해 Ajax를 통해 컨텐츠를 요청하거나 혹은 JavaScript로 컨텐츠를 로드할 수도 있습니다. 기본 개념은 아래와 같습니다:
이 방법을 통해 페이지는 언제나 빠르게 느껴지고, 이것은 실제 페이지에서 컨텐츠가 적게 로드되기 때문입니다. 우리는 이 방법을 매우 효과적으로 이용하여 다른 여러곳에서 새로운side-by-side diffs를 처리하였습니다.
이 블로그를 통해 여러분이 매우 큰 웹 페이지를 처리해야 하는데 성능상의 문제가 있을 때 여러분의 경험을 늘리기 위한 정보를 활용하십시요.
'Crucible' 카테고리의 다른 글
코드리뷰 적용 작은(?) 성공담 (0) | 2010.05.12 |
---|---|
이클립스에서 Crucible 코드리뷰를 직접 해 보십시요 (0) | 2010.04.26 |
Crucible 2.2 릴리스노트 (0) | 2010.02.26 |
Crucible 2.1 릴리스 노트 (0) | 2009.12.23 |
Crucible 2.0 버전 릴리스 (0) | 2009.08.10 |