무하프로젝트

Chrome Developer Tool 사용법

1. Elements Panel

페이지 소스보기(동적 변경 포함) 및  Element 트리 내부의 모든 구성 요소 조작(선택, 추가, 수정, 삭제)이 가능합니다.

PS. 페이지상의 각 요소 선택 시 아래 돋보기 아이콘을 활용합니다.

1.1 Computed style:

브라우저 내부에서 미리 계산된(Reflow) 모든 수치 데이터를 확인합니다.

1.2 Styles:

Element 스타일의 데이터 조작(확인, 추가, 수정, 삭제)이 가능합니다.

1.3 Metrics:

Element Box Model에 대한 수치 데이터 조작(확인, 추가, 수정, 삭제)이 가능합니다.

1.4 Properties:

Element 속성 데이터 조작(확인, 추가, 수정, 삭제)이 가능합니다.

1.5 Dom Breakpoints:

Element 속성 수정 시 해당 Element에 Breaking point(종단점)를 걸어 확인합니다.

1.6 Event Listeners:

Element 이벤트 흐름을 확인합니다.

1.7 Search

DOM 트리를 검색합니다.

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/elements

2. Resources Panel

페이지의 모든 리소스 요소를 여러 가지 분류(HTML5 WebDB(SqlLite), Local Storage, Session Storage, Cookie, AppCache등)를 통해 확인합니다.

2.1 Frames:

페이지에 로드된 모든 리소스(font, images, other(flash, xml 등), script, stylesheets)를 확인합니다.

2.2 Databases:

생성된 HTML5 WebDB를 확인합니다.

2.3 Local Storage:

생성된 Storage(Local)를 확인합니다.

2.4 Session Storage:

생성된 Storage(Session)를 확인합니다.

2.5 Cookie:

생성된 Cookie 데이터를 확인합니다.

2.6 Application cache:

생성된 AppCache 데이터를 확인합니다.

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/resources

3. Network Panel

페이지 요청에 따른 각 리소스들의 상세 내역(HTTP 요청 / 응답, 헤더 데이터등)을 타임라인으로 확인합니다.

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/network

4. Sources

Inline Script 및 External File Script의 소스 내역을 확인할 수 있으며, BreakPoints(종단점) 삽입 및 리얼타임 디버깅이 가능합니다.

4.1 Watch Expressions:

JS 표현식을 사용하여 리얼타임 조작이 가능합니다.

4.2 Call Stack:

JS Starck을 호출합니다.

4.3 BreakPoints:

JS 디버깅 시 소스 내역에 BreakPoints(종단점) 겁니다.

4.4 Dom Breakpoints:

DOM 디버깅 시 소스 내역에 BreakPoints(종단점) 겁니다.

4.5 XHR BreakPoints:

JS 디버깅 시 해당 XHR 요청에 BreakPoints(종단점) 겁니다.

4.6 Event Listener BreakPoints:

Event 디버깅 시 요소의 모든 Event Handler에 BreakPoints(종단점) 겁니다.

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/scripts

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/timeline

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/profiles

7. Audits Panel

페이지 감사를 실행하여 그에 따른 최적화(페이지 로딩 시간 최소화) 방안을 제시합니다.

8. Console Panel

페이지의 모든 구성요소(HTML, JS, CSS등)에 대한 디버깅(오류 분석)을 Console 명령어를 통해 손쉽게 접근 할 수 있습니다.

참고 URL:

https://developers.google.com/chrome-developer-tools/docs/console

- Tool 참고 URL:

1. 웹킷 검사기: 

http://jtaby.com/2012/04/23/modern-web-development-part-1.html

2. Console 사용법:

http://ohgyun.com/tag/Chrome%20Developer%20Tools

3. Chrome 개발자 도구의 유용한 기능!(개발자 도구 환경 설정에 대한 이야기)

http://regularmotion.kr/chrome-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%8F%84%EA%B5%AC%EC%9D%98-%EC%9C%A0%EC%9A%A9%ED%95%9C-%EA%B8%B0%EB%8A%A5/

Chrome 확장 기능 Dev HTTP Client 사용기

@niceaji 님의 포스트를 통해 알게 된 크롬 확장 기능(Dev HTTP Client)을 직접 사용 후 아래와 같이 정리 해봤습니다.

1. Request:

HTTP 요청에 대한 여러 옵션(QueryString Parameter, HTTP Headers, HTTP Method, HTTP Protocol 등)을 조작하여 테스트할 수 있다.

또한, "Send" 버튼 오른쪽의 "Save" 버튼 클릭 시 설정된 모든 옵션을 Repository(데이터 집합체 보관 장소)에 저장시킨다.

2. Response:

해당 요청에 대한 응답 HTTP Headers 및 Body를 보여준다. (formatted, raw 방식 전환)

3. History:

해당 요청에 대한 History를 저장한다.

4. Repository:

Request 단에서 미리 저장(Save 버튼을 통한..)된 요청을 Export 버튼 클릭 시 JSON 형식의 파일로 저장(새창(JSON 텍스트가 출력된)에서 Ctrl + S 단축키를 통해 *.txt파일로 저장한다.(크롬 브라우저 기준))할 수 있으며, 

Import 버튼을 통해 저장된 *.txt 파일을 다시 불러와 해당 요청을 재사용할 수 있다.

JSON 형식 출력 결과:

@niceaji: 유용한 정보 공유 감사 드립니다.!! ^^

Dev HTTP Client 다운:

https://chrome.google.com/webstore/detail/aejoelaoggembcahagimdiliamlcdmfm

Reflow or Repaint(or ReDraw)과정 설명 및 최적화 방법

1. Reflow or  Repaint 과정이란?

1.1 Reflow 발생:

생성된 DOM 노드의 레이아웃 수치(너비, 높이, 위치 등) 변경 시 영향 받은 모든 노드의(자신, 자식, 부모, 조상(결국 모든 노드) ) 수치를 다시 계산하여(Recalculate), 렌더 트리를 재 생성 하는 과정.

또한, Reflow 과정이 끝난 후 재 생성된 렌더 트리를 다시 그리게 되는데 이 과정을 Repaint 라 한다.

Reflow 발생 코드:

Reflow 발생 그래프:

그래프 단계 별 설명:

1. Click 이벤트 handler

2. Recalcurate(변경된 스타일 수치 계산 수행)

3. Layout(Reflow 과정 수행)

4. Paint(Repaint 과정 수행)

1.2  Repaint 발생 :

Reflow 발생 이유와 같이 스타일의 모든 변경이 레이아웃 수치에 영향을 받는것은 아니다.

즉, 아래 그래프 처럼 노드의 background-color, visibillty, outline 등의 스타일 변경 시에는 레이아웃 수치가 변경되지 않으므로 Reflow 과정이 생략된 Repaint 과정만 일어나게 된다.

Repaint 발생 코드:

Repaint 발생 그래프:

그래프 단계 별 설명:

1. Click 이벤트 handler

2. Recalcurate(변경된 스타일 수치 계산 수행)

3. Paint(Repaint 과정 수행)

2. Reflow 과정이 일어나는 상황

1. 노드의 추가 또는 제거.

2. 요소의 위치 변경 시.

3. 요소의 크기 변경 시.(margin, padding, border, width, height, 등..)

4. 폰트 변경 과(텍스트 내용) 이미지 크기 변경 시.(크기가 다른 이미지로 변경 시)

5. 페이지 초기 랜더링 시.(최초 Layout 과정)

6. 윈도우 리사이징 시.

3. Reflow 최적화 방법

3.1 클래스 변화에 따른 스타일 변경 시, 최대한 DOM 구조 상 끝단에 위치한 노드에 

주어라.

- 가급적 말단에 위치한 노드 수치 변경 시 리플로우 수행 반경을 전체 노드가 아닌 일부 노드로 제한 시킬 수 있다. 

즉, Reflow 수행 비용을 줄일 수 있다는 말과 같다.(하지만 실무 작업 시 적용 가능한 범위가 크지 않다)

3.2 인라인 스타일을 최대한 배제하라.

- 아래 3.9 규칙과 중복되는 내용이며, 적용 시 코드 가독성과 Reflow 비용을 줄일 수 있습니다.

3.3 애니메이션이 들어간 노드는 가급적 position:fixed 또는 position:absolute로 지정하여 전체 노드에서 분리 시킨다.

- 보통 (JS(Javascript) + CSS)를 활용한 에니메이션 효과는 해당 프레임에 따라 무수히 많은 Reflow 비용이 발생하게 됩니다.

하지만 position 속성을 "fixed" 또는 "absoute"로 값을 주면 지정된 노드는 전체 노드에서 분리됩니다.

즉,  전체 노드에 걸쳐 Reflow 비용이 들지 않으며, 해당 노드의 Repaint 비용만 들어가게 됩니다.

- 또한, 노드의 position 값을 초기에 적용하지 않았더라도 에니메이션 시작 시 값을 변경(fixed, absolute)하고 종료 시 다시 원복 시키는 방법을 사용해도 무관 합니다.

테스트 코드:

테스트 결과:

3.4 퀄리티와 퍼포먼스 사이에서 타협하라.

위 3.3 규칙의 사례중 하나인 에니메이션 효과는 보통 무수히 많은 Reflow 비용이 들어가게 된다.

물론, 디바이스 환경에 따라 큰 성능 차이를 보일 수 있겠지만, 스마트폰 기기와 같은 경우 그리 좋은 성능을 보이지 못한다.

따라서 에니메이션 효과와 같은 CPU 퍼포먼스 비용이 큰 작업은 언제나 퀼리티와 퍼포먼스 사이에 적당한 타협이 필요하다.

3.5 테이블 레이아웃을 피하라.

테이블로 구성된 페이지 레이아웃은 점진적(progressive) 페이지 렌더링이 적용되지 않으며, 모두 로드되고 계산(Recalculate)된 후에야 화면에 뿌려지게 된다. 

하지만 해당 테이블에 table-layout:fixed 속성을 주는 것이 디폴트값인 auto에 비해 성능면에서 더 좋다고 한다.

3.6 IE의 경우, CSS에서의 JS표현식을 피하라.

이미 오래된 규칙이지만 매우 효과적인 규칙이다. 

CSS 표현식(expression)의 비용이 매우 높은 이유는, 문서 전체 또는 문서 중 일부가 Reflow될 때마다 표현식이 다시계산되기 때문이다. 

결국 애니메이션과 같은 변화에 의해 리플로우가 발생했을 때, 경우에 따라 초당 수천, 수만번의 표현식 계산이 진행될 수 있다는 것을 의미한다.

CSS expression 적용 코드:

3.7 CSS 하위선택자는 필요한 만큼만 정리하라.

- 이 규칙에 대한 설명은 아래 참조 링크를 확인 하시기 바랍니다.

3.8. position:relative 사용 시 주의하자.

- 이 규칙에 대한 설명은 아래 참조 링크를 확인 하시기 바랍니다.

3.9 cssText 및 클래스를 활용해 Reflow or Repaint 최소화.

- DOM과 스타일 변경을 하나로 묶어 리플로우 수행을 최소화 한다.

해당 노드의 style 객체를 여러번 호출해 적용된 코드.

style 객체 속성인 cssText를 통해 한번에 적용된 코드.

CSS에 정의된 class를 통해 한번에 적용된 코드.

테스트 결과.

테스트 결과:

상황 별 Reflow 비용에 드는 시간.

첫 번째 상황: 112ms

두 번째 상황: 104ms

세 번째 상황: 104ms

3.10 캐쉬를 활용한 Reflow 최소화.

브라우저는 레이아웃 변경을 큐에 저장했다가 한번에 실행하는 방법으로 Reflow 수를 줄입니다.

하지만 offset, scrollTop, scrollLeft, 값과 같은 계산된 스타일 정보를 요청할 때마다 정확한 정보를 제공하기 위해 큐를 비우고 모든 변경을 다시 적용합니다.

즉, 중복되는 수치에 대한 스타일 정보를 변수에 저장(캐쉬)해 요청수를 줄임으로써 Reflow 비용을 최소화 시킨다.

비록, 실무에서 사용되는 코드는 아니지만, 해당 규칙만 이해 하시기 바랍니다.

3.11 DOM 사용을 최소화하여 Reflow 비용 줄이기.

- 아래 포스트와 같이 여러 가지 방법을 활용하여 Reflow 비용을 줄일 수 있다.

DOM 사용 최소화 하기

http://mohwaproject.tistory.com/entry/DOM-%EC%82%AC%EC%9A%A9-%EC%B5%9C%EC%86%8C%ED%99%94-%ED%95%98%EA%B8%B0

참고 사이트:

Reflow 원인과 마크업 최적화 TIP

http://lists.w3.org/Archives/Public/public-html-ig-ko/2011Sep/att-0031/Reflow_____________________________Tip.pdf

Webkit / Gecko Rendering 엔진의 Life Cycle

위 그림은 아래 소스를 실행 시킨 과정을 도식화 한 이미지 입니다.

1. Loading: 

웹 서버로부터 브라우저가 렌더링할 문서 컨텐츠(Source Text)를 내려받는다.(일반적으로 8kb 크기 단위)

2. Parsing: 

웹 서버로부터 내려받은 문서 컨텐츠(Source Text)를 브라우저가 파싱한다.

-  Parsing 이란? 

웹 서버로부터 내려받은 문서 컨텐츠(Source Text)를 기계(브라우저)가 이해하고 사용할 수 있는 구조(DOM  트리 )로 문서를 변환하여 반환하는 과정.

즉, 변환된 결과는 브라우저가 이해하고 사용할 수 있는 구조인 DOM 트리 구조로 반환되는 것이다.

- 생성된 DOM 트리는 다른 말로 (Contnet 트리, Parse 트리, Syntex 트리)라고도 불린다.

WebKit 렌더링 엔진의 모든 실행 과정이 이와 같이 점진적으로 이루어지나, 엔진 성능 최적화를 위해 내려받은 문서 컨텐츠의 모든 파싱 처리가(DOM 트리 변환) 완료 될 때까지 기다렸다 Render 트리를 생성하지는 않는다.

즉, 일괄 처리가 아닌 부분 처리로 컨텐츠를 파싱하여 랜더 트리를 더욱 빠르게 생성한다.

Parser 에 대한 더 자세한 설명은 아래 링크를 참조하시기 바랍니다.

Virgule's notes님의 브라우저 파싱과 DOM 트리 생성:

http://fantalon.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%A0%EA%B9%8C-3-%ED%8C%8C%EC%8B%B1%EA%B3%BC-DOM-%ED%8A%B8%EB%A6%AC-%EC%83%9D%EC%84%B1

3. JS Execution

외부/인라인 Javascript를 파싱 후 실행시키는 과정.

4. Dom 트리 노드 생성

WebKit 렌더링 엔진은 HTML 문서 컨텐츠 상의 Source Text(HTML, Jascript, CSS, Image 등..)를 "Content 트리" 라고 불리는 트리 형태의 DOM 트리 노드로 반환한다.

5. Render 트리 생성

- Render 트리 란?

이미 생성된 DOM 트리 노드와 컨텐츠 내의 모든 스타일(CSS) 정보(외부 / 인라인 CSS)를 파싱하여 그에 따른 시각적인 정보(Rander Style 트리)가 포함된 렌더 트리를 생성한다.

즉, 생성된 렌더 트리는 문서의 모든 시각적인 요소(CSS 박스 모델과 연관된 모든 요소)가 포함된 형태를 갖게 되며, DOM 트리 노드 중 숨겨진 DOM 요소에 대응하는 노드는 랜더 트리에 포함되지 않습니다.

5.1  Render Style 트리

1. 모든 CSS Style(외부 / 인라인) 정보를 가짐.

2. Render 트리가 소유.

3. Render Object는 Style을 공유.

5.2 Render Layer 트리

특정 조건에 의해 생성되는 트리(렌더트리와 달리 무조건 생성되지 않는다.)

생성 조건.

1. 웹페이지 루트(Render View)

2. CSS Position이 명확한 경우(relative, absolute, fixed)

3. CSS transform이 적용된 경우

4. 투명도가 적용된 경우(CSS opacity)

5. overflow, alpha mask, reflection이 적용된 경우

6. <canvas>(3D context) 엘리먼트가 적용된 경우

7. <video> 엘리먼트가 적용된 경우

6. Layout

각 노드가 화면 상 어느 위치에 나타날 것인지 정확한 좌표를 지정하는 과정.

7. Painting

생성된 렌더 트리를 순회하며 각 노드를 UI 백엔드 레이어(각 브라우저에서 제공되는 사용자 인터페이스 레이어(Select 박스, 버튼, 각종 폼 등..)를 이용해 화면에 그리는 과정.

8. WebKit 엔진과 GenKo 엔진의 플로우 차이점.

- WebKit 렌더링 엔진 메인 플로우

- GenKo 렌더링 엔진 메인 플로우

위와 같이 모질라의 GenKo 렌더링 엔진 또한 WebKit 엔진과 거의 흡사한 형태를 가지고 있다.

8.1 WebKit 과 GenKo 엔진의 용어 차이점 정리: 

WebKit: Render 트리

GenKo: Frame 트리

WebKit: Layout

GenKo: Reflow

WebKit: Attachment: 렌더 트리를 만들기 위해 DOM 노드와 시각적인 정보를 연결하는 작업.

GenKo: Content Sink: 렌더 트리를 만들기 위해 DOM 노드와 시각적인 정보를 연결하는 작업.

참고 사이트:

브라우저의 작동원리:

http://fantalon.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EA%B0%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9E%91%EB%8F%99%ED%95%A0%EA%B9%8C

브라우저의 렌더링 엔진:

http://fantalon.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%A0%EA%B9%8C-2-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%97%94%EC%A7%84

웹 브라우저는 어떻게 동작하는가?:

http://www.slideshare.net/joone/ss-9766705