[2주차 메인토픽] 브라우저 렌더링

[zigsong]

하브루타 3기 2주차 메인토픽이자 우테코 Lv2의 마지막 주제!

프론트엔드가 이런 것까지 알아야 해 😬
네! 그렇다고 합니다!

👉 브라우저 렌더링 👈

☘️ 하위키워드 예시

• DOM
• CSSOM
• 렌더트리
• 리플로우
• 리페인트
• 렌더링 최적화

[zigsong]

공유하고싶은 자료 & 개인적으로 정리한 블로그 등이 있다면 여기👇👇👇에 댓글로 공유해주세요 😆

[zigsong]

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

[365kim]

Google Developers - 렌더링 트리 생성, 레이아웃 및 페인트

[yungo1846]

렌더링 성능
csstriggers.com
TECH CONCERT: FRONT END 2019 - 오늘부터 나도 FE 성능분석가

[zigsong]

웹 렌더링 성능 최적화

[dudtjr913]

To.썬 @SunYoungKwon

• 브라우저 랜더링 과정에서 성능을 향상시키는 것을 시도해 본 적이 있나요? 어떻게 성능을 향상시킬 수 있을까요?

lazy 로딩, 인터렉션 과정에서 reflow와 repaint를 발생시키지 않는 것이 좋다. cssTriggers에 들어가보면 알 수 있다. 
그래서 opacity와 transform을 사용하는 것이 좋다. 
브라우저의 초기 랜더링의 속도를 줄이는 방법
- 웹팩으로 css와 js파일을 하나로 묶는 것도 방법이 될 수 있다. 
- 여러 아이콘 이미지를 하나의 파일로 몰아넣는 스프라이트 기법이 성능 향상에 도움이 된다. 
- 뷰포트 밖에 있는 것을 없애는 것도 도움이 된다.
- http/1.1은 한 번의 연결에 하나의 파일만 가져올 수 있고, http/2.0부터는 다중 응답 처리가 가능해서 성능에 좋다. 
- 주석, 공백을 제거하는 것도 성능 향상에 도움이 된다. 
- 이미지 크기 자체를 줄이기, 메타 정보도 제거를 하자. 
- preload를 사용해 미리 로드를 해놓는 것도 도움이 된다.
- head태그에는 필수적인 것만 넣자.

• layout, paint, compositing이 각각 어떤 역할을 담당하고 있나요? 그리고 이렇게 3단계로 나눠야하는 이유가 있을까요?

layout 
- 위치와 크기를 지정
paint 
- 화면에 그림
composition
- 레이어를 조합 

역할이 다르기 때문에 나누는 것이 맞다. 페인트만 해야할 땐 레이아웃을 하지 않아도 돼서 성능 상에 이점이 있을 것이다.

[swon3210]

To.피터 @iborymagic

저는 리액트에서 가상 돔이 실제 돔에 변경사항을 '한번에' 반영한다는 말이 가상 돔이 구축한 HTML 문자열을 innerHTML로 root div 에 한번에 집어넣는다는 말인 줄 알았습니다. 그러나 곧 그게 아니라는 것을 알게 되었는데요.

새로운 문자열로 전체 DOM 을 재구축해버리면 단순히 변경사항이 한번에 반영되는 것이 아니라 어플리케이션 상의 모든 애니메이션이 전부 다시 트리거 되는 것을 보았기 때문입니다. 즉, innerHTML 에 문자열 넘기는 식으로는 DOM 요소들이 모두 재구축 되어버리는 것입니다.

여기서 문제입니다.

1. innerHTML 을 통해 많은 DOM 영역을 재구축 해버리면 정확히 어떤 브라우저 렌더링 과정을 거치게 될까요?

스타일(Style) → [레이아웃 → 페인트 → 합성]

다른 일반적인 경우와 마찬가지로 위의 과정을 거치게 됩니다. 다만 이때의 차이점은 innerHTML 안의 요소들을 나타내는 엘리먼트 객체들이 아예 삭제되어버리고, 문자열을 parsing 해서 완전히 새로운 노드를 recreate 하는 과정을 거치게 됩니다. 이 때문에 초기에만 실행되어야 하는 해당 요소의 애니메이션 또한 다시 수행되는 것입니다.

2. innerHTML 로 문자열을 넘겨주는 방식과 돔 자체를 여러 번 조작해서 리렌더링을 수행하는 것 중 어느 것이 더 성능이 좋을 것이라고 생각하시나요? 그 이유는 무엇인가요?

innerHTML 로 리렌더링을 수행하는 방식은 reparsing 과 recreate 과정을 수반합니다. 그러나 documentFragment 를 통해 반영사항을 여러번 수행하는 것은 메모리 상에 저장된 노드에 변경을 수행하는 것이기 때문에 여러번의 렌더링을 수반하지 않으며 파싱과정도 없습니다. 결과적으로 documentFragment 를 활용하는 방식이 더 성능적으로 효과적이라고 말할 수 있겠습니다.

3. 실제 DOM 전체를 재구축하지 않고 여러 개의 변경사항도 스타일 - 레이아웃 - 페인트- 합성 사이클을 한 번만 동작시켜서 수행할 수 있는 방법이 있다고 생각하시나요? 있다면 과연 무엇인가요?

documentFragment를 활용하면 DOM 객체에 한 번만 접근할 수 있고, 문자열 parsing도 하지 않습니다. 그래서 createDocumentFragment로 경량화된 객체를 만들면 해당 객체는 메모리 상에 존재하기 때문에 자식노드를 붙이는 행위도 메모리 상에서 일어나게 되죠. 그래서 자식을 붙여주는 와중에도 page reflow가 일어나지 않습니다. 그러면 최종적으로 real DOM에 한 번만 접근해서 documentFragment를 붙여주면 가장 효율적인 방법으로 DOM을 변경할 수 있게 됩니다.

[365kim]

@zigsong 🙋🏻‍♀️

Q1

브라우저 렌더링 중 레이아웃(layout, reflow) 과정이 일어나는 경우는 어떤 경우가 있을까요? 이 과정은 왜 주의해야 할까요?

👉 layout 과정이 일어나는 경우는 repaint만 일어나는 경우 보다 더 오래걸리기 때문에 렌더링 엔진에 부하가 커지고 앱 성능에 영향을 줄 수 있어 주의해야한다. 가능하다면 repaint만 일으키는 방향으로 코드를 작성하는 것이 좋다!

👉 레이아웃을 다시 계산하는 과정이 필요한 경우 리플로우가 발생한다. 이에 해당하는 경우는 다음과 같다.

• 페이지 초기 렌더링
• 노드 추가
• 노드 삭제
• 요소의 크기 변경
• 요소의 위치 변경
• 윈도우 크기변경
• 폰트 변경
• 텍스트 내용 변경
• 이미지 크기 변경 등!

Q2

우리가 만든 앱에서 초기 렌더링 속도를 줄이기 위해서는 어떤 점을 고려해볼 수 있을까요? 디테일한 방법도, 거시적인 방법도 모두 좋습니당~!

👉 주요 렌더링 경로의 웹페이지 로딩을 최적화하면 초기 렌더링 속도를 줄일 수 있다!

• 블록 리소스(CSS, 자바스크립트) 최적화
  • color: #fff;
  • position: absolute; top: -9999px;
• 리소스 요청 수 줄이기
  • 이미지 스프라이트(sprite) 활용
• 리소스 용량 줄이기
  • 웹팩의 compress 과정

Q3

렌더링에 대해 공부하며 다음 용어를 처음 접했는데요. 이런 지표를 관리하는 것도 프론트엔드 엔지니어로서의 역할일까요? 그리고 관리가 정말 필요하다면 어떻게 관리하면 좋을까요?

• TTFB: Time to First Byte (첫 번째 바이트까지의 시간) - 링크를 클릭한 후 처음으로 들어오는 콘텐츠 비트 사이의 시간
• FP: First Paint - 픽셀이 처음으로 사용자에게 표시되는 시점.
• FCP: First Contentful Paint - 요청 콘텐츠(기사 본문 등)가 표시되는 시점
• TTI: Time To Interactive - 페이지가 상호작용 가능하게 될 때까지의 시간 (이벤트 발생 등).

👉 해당 성능지표는 고객확보 여부에 큰 영향을 미치기 때문에 관리해야한다.

• 출처: 토스 SLASH 21 - JavaScript Bundle Diet

👉 이미 만들어진 성능테스트 도구를 적극적으로 활용해볼 수 있다.

•  프론트엔드 성능 체크리스트 - 도구

• 활용 예시

  • GT metrix

• 크롬 개발자도구 Lighthouse 탭

[seojihwan]

@yujo11

1. lighthouse 의 Performance 평가 지표 6가지 입니다.

각 평가 지표가 의미하는 것과 높은 평가를 받기위한 조건에 대해 알아볼까요?

Light house 6 Performance 측정

평가 지표와 반영 비율

변동성

• 평가 환경에 따라 같은 코드임에도 다른 점수가 발생함
• 평가할 때에는 동일 환경에서 비교해야함
  • https://github.com/GoogleChrome/lighthouse/blob/master/docs/variability.md
• 상대적으로 평가됨

측정

• Performance: 페이지 로딩 속도 측정

• 6가지 지표

  • First Contentful Paint

    • first piece of DOM content( 텍스트, 이미지 ) 가 나타나는데 걸리는 시간

  • Speed Index

    • 얼마나 빨리 content가 시각적으로 완성되는지 측정

  • Largest Contentful Paint

    • 가장 큰 element가 화면에 나타나는 속도 측정

  • Time to Interactive

    • 페이지가 완전히 상호작용 가능해지는데 걸리는 시간 측정
    • 2.2초 기준 99점 (상위 1%)

  • Total Blocking Time

    • 마우스 클릭, 화면 탭 또는 키보드 누름과 같은 사용자 입력에 응답하지 못하도록 차단 된 총 시간을 측정
    • FCP와 TTI 사이의 기간에서 측정

  • Cumulative Layout Shift

    • 누적 레이아웃 이동
    • 충격 비율: 두 프레임의 누적 영역
    • 거리 비율: 프레임간 이동 거리
    • 충격 비율 x 거리 비율이 높으면 평가 점수가 낮음
    • 0.1이 75점

    향상 방법

    • css의 transform이용하면 layout을 밀어내지 않고 애니메이션 적용가능
    • 이미지 및 동영상 요소에 크기 속성을 포함
    • 작업 요청시 처리 시간 -50ms : 50ms이상의 작업은 긴작업으로 간주
    • 누적 300ms 이하가 Good

  공통된 향상 방법

  • 렌더링 차단 리소스 제거
    • CSS, JS
      • Code Splitting
  • 압축
  • 메인 스레드의 작업을 최소화
  • 자바스크립트 실행시간의 단축
  • webfont를 다운받기 이전에 text의 visibility를 보장하기

[365kim]

오!

Google Lighthouse는 웹 페이지의 품질을 측정하기위한 오픈 소스 자동 도구입니다.
공개 또는 인증이 필요한 모든 웹 페이지에 대해 실행될 수 있습니다.
Google Lighthouse는 웹 페이지의 성능, 접근성 및 검색 엔진 최적화를 심사합니다.

[zigsong]

https://ui.toast.com/fe-guide/ko_PERFORMANCE

[yujo11]

@seojihwan 🙋‍♂️

1. 리플로우와 리페인트의 차이에 대해 얘기를 나눠보아요!

• reflow는 layout을 연산 - width
• repaint는 px을 만들어간다. - bdColor emdemd
• reflow 이후 repaint가 일어난다.
• reflow가 생기면 무조건 repaint가 일어난다.

2. 브라우저가 렌더링 되는 순서에 대해 얘기를 나눠보아요!

1. HTML, CSS를 파싱해서 DOM tree와 CSSOM tree로 만든다.
   • link tag등 resource가 필요한 요소들은 다운 받는다.
2. DOM, CSSOM를 이용하여 Render Tree 생성
3. reflow를 통한 Layout 생성
4. repaint를 통한 실제 화면 생성

[SunYoungKwon]

To. @dudtjr913

Q1. CSS 애니메이션이 일어나면 브라우저가 어떤 과정으로 화면에 렌더링하는지에 대해 이야기해봅시다.

• 인터렉션 성능 최적화는 브라우저의 메인 스레드를 건드리지 않는 것이 포인트
• composite은 GPU를 사용
• transform은 리플로우와 리페인팅이 일어나지 않음. composite만 일어난다.
• CSS Triggers에서 각 CSS속성이 변화될때 어떤 일이 일어나는지 확인할 수 있다.
• (참고) CSS GPU 애니메이션 제대로 하기 - WIT 블로그

Q2. 각 렌더링 엔진(게코, 웹킷, 블링크)의 차이점에 대해 이야기해봅시다

• 각 엔진의 동작에 대한 차이점은 너무 찾기 어려워서ㅠㅜ 각 엔진에 대한 간략 소개로 대체

웹킷

• 애플에서 KHTML을 기반으로 만든 오픈소스
• IOS의 크롬은 웹킷을 사용함

블링크

• 웹킷을 기반으로 구글에서 만듦
• 크롬, 엣지, 오페라, 삼성 인터넷, 네이버 웨일에서 사용 중
• 리치 알림기능

게코

• 파이어폭스에서 사용
• C++에서 러스트로 변경 중
• 이미 시작을 독점한 서비스에서 웹킷과 블링크를 사용하고 있어, 성능 대비 조명받지 못하고 있다는 평가가 있음

[zigsong]

@365kim 소요시간 1시간 30분

Q1. 브라우저의 Repaint 과정을 줄일 수 있는 방법은 무엇이 있을까요?

1. 사용하지 않는 노드에는 visibilty: invisible 보다 display: none을 사용하기

2. Reflow, Repaint 가 발생하는 속성 사용 피하기

3. 영향을 주는 노드 줄이기
position: absolute 또는 fixed → reflow 연산 과정 X

4. 프레임 줄이기

5. repaint를 줄이는 것보다 reflow를 줄이는 방법!

https://boxfoxs.tistory.com/408
https://csstriggers.com/

Q2. 브라우저 렌더 트리의 구성 요소 중 화면에 표현되지 않는 요소는 무엇이 있을까요?

• display: none 속성이 설정된 노드는 화면에 어떠한 공간도 차지하지 않기 때문에 Render Tree를 만드는 과정에서 제외된다.
• visibility: invisible 은 display: none과 비슷하게 동작하지만, 공간은 차지하고 요소가 보이지 않게만 하기 때문에 Render Tree에 포함된다.
• DOM과 CSSOM을 합쳐서 실제로 화면에 표현되는 것들로만 구성한 것이 Render Tree!
  • opacity, visibility 등의 속성은 Render Tree에 포함되어 있어도 보이지 않음 but 화면에 차지되고 있기 때문에 다른 요소들과의 영향 O
  • 아무튼 렌더 트리의 모든 것은 화면에 표현된다!
• DOM, CSSOM에 있는데 render tree에 안 들어가는 친구들
  • script, meta 태그 등
  • display: none인 요소들
    • html 문서에 있어도, 렌더 트리에는 들어가지 않는다!

Q3. 최신 브라우저의 합성(compositing)이란 무엇일까요?

웹 페이지의 각 부분을 레이어로 분리해 별도로 래스터화하고 컴포지터 스레드(compositor thread)라고 하는 별도의 스레드에서 웹 페이지로 합성하는 기술

• Layout 과정을 거쳐 화면에 UI를 화면에 표현하기 위한 계산이 끝나면 Paint 과정을 거친다. Layout 과정에서 Render Layer가 2개 이상 생성되면 각각의 Layer 를 Painting 한 뒤 하나의 이미지로 Composite하는 과정을 추가로 거쳐 브라우저에 표현한다.
• 페이지의 여러 부분이 잠재적으로 여러 레이어로 그려졌기 때문에 페이지가 정확히 렌더링되려면 정확한 순서로 화면에 그려야 한다. 실수로 한 요소가 다른 요소 위에 잘못 나타날 수 있기 때문에 이는 다른 요소와 겹치는 요소가 있는 경우에 특히 중요하다. (브라우저가 요소 순서 그대로만 화면을 그려내면 z-index가 적용되지 않는 문제)
• JS/CSS → 스타일 → 페인트 → 합성

[sunhpark42]

@yungo1846

1. 브라우저 렌더링을 최적화하는 방법중 document fragment를 이용하는 방법이 있는데, createElement로 div와 같이 한 태그를 지정해 두고 해당 엘리먼트에 자식요소를 붙인 후 root의 innerHTML에 넣는 방법과, fragment에 자식요소를 삽입한 후 root의 innerHTML에 넣는방법은 어떤 차이가 있을까요?

/* Fragment */
const list = document.querySelector('#list')
const fruits = ['Apple', 'Orange', 'Banana', 'Melon']

const fragment = new DocumentFragment()

fruits.forEach(function (fruit) {
  const li = document.createElement('li')
  li.innerHTML = fruit
  fragment.appendChild(li)
})

list.appendChild(fragment)

/* createElement */
const list = document.querySelector('#list')
const fruits = ['Apple', 'Orange', 'Banana', 'Melon']

const containerDiv = document.createElement('div')

fruits.forEach(function (fruit) {
  const li = document.createElement('li')
  li.innerHTML = fruit
  containerDiv.appendChild(li)
})

list.appendChild(fragment)

실질적으로 돔에 10000개의 요소를 추가했을 때 시간차이는 크게나지 않음. 그러나 fragment를 사용하면, appendChild이후 fragment가 비워지기때문에 메모리 관리에서는 더 효율적이라고 생각한다.

2. 브라우저 렌더링을 최적화하는것이 왜 중요할까요?

결국엔 사용자 경험을 위해서라고 생각한다. 보다 빠르고 정확하게 사용자에게 서비스 경험을 제공하기 위함

3. 브라우저 렌더링 최적화를 위해 사용해보신 방법이 있으신가요? 함께 이야기 나눠봅시다~

* 사용해 본 것은 레이지로딩정도
* 그 외에 GPU가속, Minify 이용, Head tag에 link태그 이용, 코드 스플리팅 등이 있다.

[iborymagic]

@swon3210
1. 브라우저 렌더링 성능 향상을 위해 노력해 본 경험이 있다면 함께 이야기해봅시다.

크롬 브라우저에 내장된 Performance 탭을 이용해서 애니메이션 성능을 측정해 본 경험이 있다.
근데 사실 그 측정 결과를 바탕으로 최적화를 수행해 본 경험은 따로 없음.

2. TTFB는 구글의 SEO에 큰 영향을 미치는 수치라고 알고있는데, 이 TTFB를 줄일 수 있는 방법에는 무엇이 있을까요?

TTFB(Time To First Byte): 링크를 클릭한 후 처음으로 들어오는 컨텐츠 비트 사이의 시간

파일 최적화 - 크기가 조정(최적화된 이미지)된 이미지를 제공하거나, 
CSS나 Javascript 파일의 크기를 줄여서 제공하거나, Lazy Import를 통해 Javascript를 불러오는 것을 나누는 방법도 있다.

캐싱 활용 - 캐시에 저장된 페이지의 요청이 수신되면 캐시를 이용해서 훨씬 더 빠르게 처리된다.
캐싱을 활용하는 방법중에는 PWA(Progressive Web App)를 이용하는 방법도 있다.
PWA를 이용하면 사용자의 컴퓨터에 웹 서비스를 저장하는 게 가능하다. (오프라인 상태일 때도 사용 가능)
그러면 빌드한 것처럼 서비스의 버전을 나눠서 관리할 수도 있다.
PWA의 목표는 Native app과 웹 서비스의 간격을 줄이는 것으로 알고 있음.
아마 PC버전의 유튜브 뮤직도 PWA인 것으로 알고 있음.

쿼리 줄이기 - 데이터베이스 쿼리 수, 느린 쿼리 및 전혀 완료되지 않은 쿼리는 모두 사이트의 TTFB에 직접적인 영향을 준다. 
데이터베이스에 대한 쿼리를 최소화하면 된다.

호스팅 서버의 사양을 높이는 방법도 있음.

3. Audits 패널(lighthouse)의 First Contentful Paint, First Meaningful Paint, Time To Interactive 지표에 대해 설명해주세요.

FCP(First Contentful Paint): 요청 컨텐츠(기사 본문 등)가 표시되는 시점(텍스트나 이미지가 출력되기 시작하는 순간)

FMP(First Meaningful Paint): 사용자에게 의미 있는 컨텐츠가 그려지기 시작하는 첫 순간. 
컨텐츠를 노출하는 데에 필요한 CSS, 자바스크립트 로드가 시작되고 스타일이 적용되어 주요 컨텐츠를 읽을 수 있다.

TTI(Time To Interactive): 페이지가 상호작용 가능하게 될 때까지의 시간(이벤트)

FCP에 대해 조금 더 자세히 얘기해보자면, 이미지와 텍스트가 최대한 빨리 보여야 하는 게 핵심.
요즘 웹 폰트를 막 갖다 쓰는데, 웹 폰트가 모두 로드될 때까지 글자가 안 보이기 때문에 FCP를 늦추는 범인 중의 하나. 
근데, FCP를 늦추지 않으면서 웹 폰트를 쓰는 방법이 있다! 
두둥 그건 바로.. 
60초 후에 공개 (실제로 화장실 갔다 옴)

font-display: swap;을 사용해라!

그러면은 웹 폰트가 로드되기 전까지는 기존의 폰트로 먼저 출력을 하고
로드가 완료되면 웹 폰트로 swap 한다!

추가로, 웹 폰트도 여러가지 형식이 존재한다. 
최근에 나온 폰트 형식일수록 압축률이 높아서 로딩시간이 짧음. 
그래서 최근에 나온 폰트 형식을 위에다가 적어주면, 
위에서 아래로 순서대로 import를 시도하기 때문에 순서를 지켜서 불러오는 것이 좋다.

src: local('Spoqa Han Sans Regular'), local('Spoqa-Han-Sans-Regular'), 
url('./assets/fonts/korean/SpoqaHanSans_subset/SpoqaHanSansRegular.woff2') format('woff2'), 
/* Super Modern Browsers */ 
url('./assets/fonts/korean/SpoqaHanSans_subset/SpoqaHanSansRegular.woff') format('woff'), 
/* Modern Browsers */ 
url('./assets/fonts/korean/SpoqaHanSans_subset/SpoqaHanSansRegular.ttf') format('truetype'); 
/* Safari, Android, iOS */

그 밖의 Tip에는, 이미지 스프라이트를 사용해서 이미지를 최적화하는 방법과
Lazy Loading을 통해 코드를 분리해주는 방법도 있다.
또, 저화질 이미지와 고화질 이미지를 모두 준비해놓고, 저화질 이미지를 먼저 로딩한 후에
고화질 이미지가 모두 로딩되면 해당 이미지로 교체해주는 방법도 있음.
ex) https://kentcdodds.com/blog/

4. 브라우저의 reflow, repaint를 일으키는 행위와 각각을 최소화할 수 있는 방법이 있다면 공유해주세요.

right, left, top, bottom 속성 대신 transform을 사용하라고 추천하는 편.
브라우저는 각 element들의 속성을 기반으로 판단을 하여, element들을 별개의 레이어로 나눈다.
주로 대상들의  위치가 겹치거나 할 때 걔네들을 구분해주기 위해 레이어로 나누는 편.
포토샵과 동일하다고 생각하면 되는 편.

(아마) 레이아웃 과정에서 레이어를 나누고.
페인트 과정에서 각각의 레이어를 칠하고.
합성 과정에서 걔네를 하나로 합쳐서 페이지를 만든다.

top, bottom, left, right는 기하적인 속성이기 때문에 레이아웃 과정을 거쳐서 레이어 자체를 다시 그리는 편. 
그렇기 때문에 reflow를 발생 시키는 편.

반면, transform은 기존에 존재하는 레이어를 조작해서 레이어 위치만 옮기거나 하는 편.

그래서 별도의 레이아웃 연산이 필요가 없다. 
기존에 존재하는 레이어를 움직이거나 하면 되기 때문에. 
그래서 얘는 reflow, repaint 전부 하나도 안일어난다. 그냥 합성만 다시 하는 편.
그래서 top, left같은 속성보다 transform을 이용하는 게 훨씬 경제적이다.

[365kim]

TTFB: Time to First Byte (첫 번째 바이트까지의 시간) - 링크를 클릭한 후 처음으로 들어오는 콘텐츠 비트 사이의 시간
요게 SEO 에도 영향이 있군요!

[iborymagic]

그렇다고 하네용.. 저도 얼마전에 뽜노의 PR에 올라온 글을 보고 알게 되었답니당

[yungo1846]

To. @sunhpark42
소요시간: 50분

Q1.

렌더링 파이프라인에서 javascript, style, layout, paint, compositing은 각각 어떤 역할을 할까요?

• Javascript: DOM 변경
• Style recalculate: DOM의 최종 스타일을 계산
• Layout: DOM의 배치와 크기 계산
• Paint: 화면에 그리기
• Compositing: 레이어 조합하기 (GPU 사용)

Q2.

왜 브라우저는 레이어를 만드는 것 일까요?

웹 페이지는 하나의 거대한 레이어다.
GPU는 각각의 레이어를 합치는 작업을 한다.

레이어로 구성될 때의 장점

• 각각의 레이어를 겹쳐서 화면에 구성하는 작업은 compositing이라고 한다. 이미 그려진 것들의 위상을 변경해서 겹치는 것이기 때문에 비용이 굉장히 작다. 그러기 위해서는 이 각각을 레이어로 만들어야 한다.

• GPU의 도움을 받기 위해 레이어를 만든다. (뇌피셜)

GPU의 side effect

• 레이어 초기 구성 작업은 CPU가 진행
• 레이어에 원래 비트맵 정보를 복사하기 때문에 메모리가 2배로 필요하다.
• 따라서 꼭 필요한 부분만 레이어로 만든다.

NAVER D2

Q3.

점진적 렌더링이란 무엇이고 우리가 점진적 렌더링을 도입하기 위해 할 수 있는 일은 무엇이 있을까요?

A. 프로그레시브 렌더링이란 콘텐츠를 가능한한 빠르게 표시하기 위해 웹 페이지의 성능을 향상시키는 데 사용되는 기술이다. (특히, 인식되는 로딩 시간을 향상시킨다)

• 우리가 일반적으로 태그 안에 태그를 쓰는 것도 일종의 점진적 렌더링을 위한 최적화이다. 몇몇 브라우저는 스타일이 변경되면 페이지의 요소를 다시 그리는 것을 피하기 위해 렌더링을 차단한다. 이때 사용자는 빈 하얀 페이지를 보게된다.

• 브라우저는 태그에 포함된 자원을 병렬적으로 다운로드 한뒤 모두 실행한다. 이후 태그부터 화면을 그리기 시작한다.

• 이미지 지연 로딩 - 페이지의 이미지를 한꺼번에 로딩하지 않는다.

• 보이는 콘텐츠의 우선순위 설정 (또는 스크롤 없이 볼 수 있는 렌더링) - 가능한 한 빨리 표시하기 위해 사용자 브라우저에서 렌더링될 페이지에 필요한 최소한의 CSS/콘텐츠/스크립트 만 포함하면 deferred 스크립트를 사용하거나 DOMContentLoaded/load 이벤트를 사용하여 다른 리소스와 내용을 로드할 수 있다.

• 서버와 클라이언트 관점에서의 점진적 렌더링 - 점진적 렌더링(Progressive Rendering) 이란?