프론트 엔드 성능 최적화 CRP에 대해 이야기하십시오.

CRP는 무엇입니까?

CRP중요한 렌더링 경로라고도 MDN하며 설명 을 인용 합니다.

중요한 렌더링 경로는 브라우저가 HTML, CSS 및 JavaScript를 화면의 픽셀로 변환하는 일련의 단계를 나타냅니다. 중요한 렌더링 경로를 최적화하면 렌더링 성능을 향상시킬 수 있습니다. 중요한 렌더링 경로에는 DOM (문서 개체 모델), CSSOM (CSS 개체 모델), 렌더링 트리 및 레이아웃이 포함됩니다.

중요한 렌더링 경로를 최적화하면 첫 화면 렌더링 시간을 개선 할 수 있습니다. 중요한 렌더링 경로를 이해하고 최적화하는 것은 리플 로우 및 다시 그리기를 초당 60 프레임으로 수행 할 수 있도록하고 고성능 사용자 상호 작용을 보장하며 의미없는 렌더링을 방지하는 데 필수적입니다.

CRP성능 최적화 를 결합하는 방법은 무엇입니까?

평범한 직업이든 면접이든 모두가 성능 최적화에 익숙하지 않다고 생각합니다.

일반적으로 몇 가지 요점에 대해서만 이야기하면 그다지 엄격하지 않다고 생각합니다.

오늘 우리는 매우 고전적인 인터뷰 질문을 결합 从输入URL到页面展示,这中间发生了什么?합니다 前端性能优化 CRP. 일부 링크에서 심도있게 이야기 합시다 .

URL 입력부터 페이지 표시까지 어떻게 되었습니까?

이 질문의 고전적인 수준에 대해 더 많이 말할 필요는 없습니다. 여기에서는 그림을 사용하여 일반적인 프로세스를 분류합니다. 이 프로세스는 대략 다음과 같이 설명 할 수 있습니다.

1, URI 분석

2. DNS 확인 (DNS 서버)

3. TCP 3 방향 핸드 셰이크 (클라이언트와 서버간에 연결 채널 설정)

4. HTTP 요청 보내기

5. 서버 처리 및 응답

6. TCP가 네 번 흔들림 (클라이언트와 서버 간의 연결 종료)

7. 브라우저 구문 분석 및 렌더링

8. 페이지가로드됩니다.

이 기사에서는 브라우저 렌더링 프로세스, 캐싱 및 DNS 최적화에서 성능 최적화에 대해 설명합니다.

브라우저 렌더링 프로세스

DOM 트리 구축

DOM트리를 만드는 일반적인 과정은 다음 그림과 같이 요약됩니다.

분석을 위해 다음 코드를 예로 들어 보겠습니다.

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>构建DOM树</title>
  </head>
  <body>
    <p>森林</p>
    <div>之晨</div>
  </body>
</html>

먼저 브라우저는 디스크 또는 네트워크 HTML원시 바이트 에서 읽고 지정된 파일에 따라 코딩하여 문자로 변환합니다.

그런 다음 Word는 동시에 생성 된 (즉, 토큰) Token에서 바이트 스트림으로 변환되고 Token, 다른 프로세스도 토큰을 소비 HTML head하고 노드 개체 로 변환 하여 노드 간 토큰의 시작과 끝을 나타냅니다. 관계.

모든 토큰이 소비되면 DOM(문서 개체 모델) 로 변환됩니다 .

최종 DOM구조는 다음과 같습니다.

CSSOM 트리 구축

DOM트리가 구축되고 다음 단계는 CSSOM트리를 구축하는 것입니다.

HTML변환과 유사하게 브라우저는 CSS올바른 토큰 을 식별 한 다음 이러한 토큰을 CSS노드 로 변환합니다 .

자식 노드는 계단식 규칙 및 계단식 스타일 시트에 해당하는 상위 노드의 스타일 규칙을 상속합니다.

DOM트리를 만드는 일반적인 프로세스는 다음 그림으로 요약 할 수 있습니다.

HTML의 예를 여기에 사용하고 다음 CSS가 있다고 가정합니다.

body {
  font-size: 16px;
}
p {
  font-weight: bold;
}
div {
  color: orange;
}

마지막으로 생성 된 CSSOM트리는 다음과 같습니다.

DOM하고 CSSOM, 당신은 그 레이아웃 트리 (나무 렌더링)를 합성 할 수 있습니다.

렌더 트리 구축

등등 DOM그리고 CSSOM당신은 좋은 레이아웃 렌더링 엔진이 트리를 구축 할 것입니다 구축해야합니다. 레이아웃 트리 구조는 실질적으로 복제 된 DOM트리 구조입니다. 단, DOM트리는 display:none요소 속성, head레이블, script태그 등과 같은 요소가 필터링되는 것을 보여주지 않습니다 .

좋은 기본 레이아웃 트리 구조를 복사 한 후 DOM해당 요소에 해당하는 스타일 정보를 선택 하는 렌더링 엔진 ,이 프로세스는 스타일 컴퓨팅입니다.

스타일 계산

객체 스타일 계산은 DOM각 요소 노드 별 스타일 을 계산하는 것으로,이 단계는 완료하는 데 세 단계로 나눌 수 있습니다.

CSS를 브라우저가 이해할 수있는 구조로 변환

그리고 HTML파일은 브라우저가 일반 텍스트 CSS스타일을 직접 이해하지 못하기 때문에 렌더링 엔진이 CSS텍스트를 수신하면 변환 작업을 수행하면 CSS브라우저가 이해할 수 있는 텍스트 변환 구조- styleSheets.

스타일 시트의 속성 값을 표준화하여 변환

이제 기존 CSS 텍스트를 브라우저가 이해할 수있는 구조로 변환 했으므로 다음 단계는 속성 값을 표준화하는 것입니다.

속성 값 표준화 란? 이 단락을 살펴 보겠습니다 CSS.

body {
  font-size: 2em;
}
div {
  font-weight: bold;
}
div {
  color: red;
}

위의 CSS텍스트를 볼 수 있으며 2em, 굵은 체, 빨간색과 같은 많은 속성 값이 있습니다. 이러한 유형의 값은 렌더링 엔진에서 쉽게 이해되지 않습니다. 모든 값을 렌더링 엔진에서 쉽게 이해할 수 있도록 변환해야합니다. 정규화 된 값이 계산되고 프로세스는 다음과 같습니다. 속성 값의 표준화.

정규화 된 속성 값은 어떻게 생겼습니까?

당신이 그림에서 볼 수 있듯이, 그것은 2em으로 구문 분석 32px, bold에 구문 분석 700, 및 red에 구문 분석 rgb(255,0,0)...

DOM 트리에서 각 노드의 특정 스타일을 계산합니다.

이제 스타일 속성이 표준화되었으므로 DOM각 노드의 스타일 속성에서 트리 를 계산해야하며 계산 방법은 무엇입니까?

여기에는 두 가지 요점이 포함됩니다 : CSS의 继承规则합계 层叠规则.

이것은이 기사의 초점이 아니기 때문에 간략하게 설명하겠습니다.

  • CSS상속은 각 DOM노드가 부모 스타일을 포함한다는 것입니다.

  • CSS기본 기능에 적층 되며 여러 소스에서 알고리즘을 병합하는 방법을 정의하는 속성 값입니다. 그것은 CSS핵심입니다, CSS전체 이름 "캐스 케이 딩 스타일 시트는"바로이 점을 강조한다.

스타일 계산이 완료된 후 렌더링 엔진은 레이아웃 트리에있는 각 요소의 기하학적 위치도 계산해야하며,이 프로세스는 레이아웃을 계산하는 것입니다.

계산 레이아웃

이제 DOM트리에 트리와 DOM스타일 요소가 있지만 DOM정보 요소의 기하학적 위치를 모르기 때문에 페이지를 표시하기에 충분하지 않습니다 . 그래서 DOM나무에 보이는 요소 기하학적 위치 를 계산해야합니다 . 우리는이 계산을 布局.

무승부

최종 레이아웃 트리의 구성은 스타일 계산 및 레이아웃 계산을 통해 완료됩니다. 그 후에는 후속 그리기 작업을 할 시간입니다.

이 시점에서 브라우저의 렌더링 프로세스는 기본적으로 끝났으며 다음 그림을 통해 분류됩니다.

이 시점에서 브라우저 구문 분석 및 렌더링의 전체 프로세스를 분류 했으므로 성능을 어디에서 최적화 할 수 있습니까?

브라우저의 렌더링 프로세스에서 수행 할 수있는 최적화 지점

일반적으로 페이지에는 로딩 단계, 대화식 단계 및 닫기 단계의 세 단계가 있습니다.

  • 로딩 단계는 프로세스의 전체 페이지를 렌더링하기위한 요청으로,이 단계에 영향을 미치는 주요 요인은 네트워크와 JavaScript스크립트입니다.

  • 대화 형 단계, 특히 페이지에서 사용자 상호 작용을로드하는 통합 프로세스의 완료,이 단계에 영향을 미치는 주요 요소는 JavaScript스크립트입니다.

  • 닫기 단계에서는 주로 사용자가 닫기 명령을 내린 후 페이지에서 수행하는 정리 작업입니다.

여기에서 우리는에 집중해야 加载阶段하고 交互阶段우리의 경험에 영향을 미치는 요인이 두 단계에 주로 때문에,의 하나에 의해 상세 한 분석 할 수 있습니다.

로딩 단계

먼저 로딩 단계에서 페이지를 체계적으로 최적화하는 방법을 분석하고 다음 그림과 같이 일반적인 렌더링 파이프 라인을 살펴 보겠습니다.

우리가 알고있는 브라우저 렌더링 프로세스를 분석함으로써 리소스 파일 JavaScript의 첫 번째 요청 인 파일이 처음으로 차단됩니다. 왜냐하면 빌드 프로세스가 필요 하고 문서화하는 동안 렌더 트리를 구성하는 동안 파일 을 사용해야하기 때문 입니다.HTMLCSSDOMHTMLJavaScriptCSS

웹 페이지의 첫 번째 렌더링을 차단할 수있는 이러한 리소스를라고 关键资源합니다. 주요 리소스를 기반으로 페이지의 첫 번째 렌더링에 영향을 미치는 세 가지 핵심 요소를 계속 개선 할 수 있습니다.

  • 关键资源个数. 키 리소스가 많을수록 첫 페이지로드 시간이 길어집니다.

  • 关键资源大小. 정상적인 상황에서는 모든 주요 리소스의 콘텐츠가 작을수록 전체 리소스의 다운로드 시간이 짧아지고 렌더링을 차단하는 시간이 짧아집니다.

  • 请求关键资源需要多少个RTT(Round Trip Time). RTT네트워크에서 중요한 성능 지표로, 데이터를 보내는 쪽에서 수신 쪽에서 확인을받는 쪽까지의 총 지연 시간을 나타냅니다.

로딩 프로세스에 영향을 미치는 몇 가지 핵심 요소를 이해하면 최적화 계획을 체계적으로 고려할 수 있습니다. 전체 최적화의 원리는 减少关键资源个数, 降低关键资源大小, 降低关键资源的 RTT 次数:

  • 핵심 자원의 수를 줄이는 방법은 무엇입니까? 한 가지 방법은이다 JavaScriptCSS같은지도 인라인으로 형태 JavaScriptCSS인라인 모드가 변경되는 경우, 다음 1-3의 중요한 자원의 감소 번호입니다. 또 다른 방법은 JavaScript코드가 DOM또는 CSSOM작업 이 아닌 경우 변경 sync되거나 defer속성이

  • 중요한 리소스의 크기를 줄이는 방법은 무엇입니까? 압축 할 수 있습니다 CSSJavaScript자원, 제거 HTML, CSS, JavaScript의견의 일부 파일 내용을

  • 주요 자원을 줄이는 방법은 RTT무엇입니까? 이는 키 리소스의 수를 줄이고 키 리소스의 크기를 줄임으로써 달성 할 수 있습니다. 또한 CDN시간을 줄이는데 도 사용할 수 있습니다 RTT.

상호 작용 단계

다음으로 페이지가로드 된 후의 상호 작용 단계와 최적화 방법에 대해 설명하겠습니다.

먼저 대화 형 단계의 렌더링 파이프 라인 살펴 보겠습니다. 실제로 최적화 할 수있는 지점은 대략 다음과 같습니다.

  • 避免DOM的回流. 즉, 피하려고 重排하고 重绘운영하고 있습니다.

  • 减少 JavaScript 脚本执行时间. 때로는 JavaScript함수의 실행 시간이 수백 밀리 초일 수 있으며, 이는 다른 렌더링 작업을 수행하는 데 주 스레드의 시간을 심각하게 차지합니다. 이러한 상황을 고려하여 다음 두 가지 전략을 채택 할 수 있습니다.

    • 하나는 한 번 실행 된 함수를 여러 작업으로 분해하여 각 실행 시간이 너무 길지 않도록하는 것입니다.

    • 다른 하나는 Web Workers.

  • DOM操作相关的优化. 브라우저 渲染引擎JS引擎사용 그래서 JS동작 DOM, 인터페이스 "커뮤니케이션", 따라서 모든 동작을 통해 서로에 대해 두 개의 엔진 DOM(유일한 액세스를 포함한 DOM특성), 엔진 사이에 해결되어야 오버 종종 감소 될 것으로 알려져 DOM 조작. 요약하면 다음과 같습니다.

    • 같은 일부 계산 된 속성을 캐시합니다 let left = el.offsetLeft.

    • 에 의해 스타일을 변경 중앙 집중화하기보다는 술집을 수정할 수 있습니다.DOMclassstyle

    • 별도의 읽기 및 쓰기 작업. 최신 브라우저에는 렌더링 대기열 메커니즘이 있습니다.

    • 다른 사람들이 채택한 프레임 워크를 DOM기반 vue/react으로 하는 전통적인 운영 포기 하는 시대virtual dom

  • 合理利用 CSS 合成动画. 합성 애니메이션은 합성 스레드에서 직접 수행되며,이 레이아웃과 작업은 메인 스레드에서 실행되는 드로잉과 다르지만, 메인 스레드 JavaScript또는 일부 레이아웃 작업이 점유하면 CSS애니메이션을 계속 진행할 수있었습니다. 그러니 CSS합성 애니메이션 을 잘 활용 하도록 CSS하세요. 애니메이션 을 만들면 최대한 CSS작동하도록하세요.

  • CSS选择器优化. 우리는 CSS引擎검색이 오른쪽에서 왼쪽으로 일치 한다는 것을 알고 있습니다. 따라서이를 기반으로 다음과 같은 최적화 솔루션이 있습니다.

    • 와일드 카드를 사용하지 마십시오.

    • 태그 선택기를 드물게 사용

    • 가능한 한 속성 상속을 사용하십시오.

  • CSS属性优化. 브라우저 이미지를 렌더링 할 때, CSS비용이 비싼 속성에 속하는 일부 속성은 브라우저를 계산 많이 필요, 특성을 계산한다 ( box-shadows, border-radius, transforms, filters, opcity, :nth-child, 등), 이것들은 종종 이렇게 대답 일상 개발에 사용되는 속성 이러한 속성을 사용하지 마십시오. 그러나 개발 중에 간단하고 실행 가능한 다른 솔루션이있는 경우 값 비싼 속성이없는 솔루션을 선호 할 수 있습니다.

  • 避免频繁的垃圾回收. JavaScript자동 가비지 수집 사용하면 일부 기능에서 임시 객체를 자주 생성하면 가비지 수집기가 자주 가비지 수집 정책으로 이동합니다. 이런 식으로 가비지 컬렉션 작업이 발생하면 메인 스레드를 차지하여 다른 작업의 실행에 영향을 미치며 심각한 경우 프레임이 떨어지고 매끄럽지 않은 느낌을 받게됩니다.

은닉처

캐싱은 성능 최적화에서 간단하고 효율적인 최적화 방법이라고 할 수 있습니다. 우수한 캐싱 전략은 웹 페이지 요청 리소스의 거리를 단축하고 대기 시간을 줄일 수 있으며 캐시 된 파일을 재사용 할 수 있기 때문에 대역폭을 줄이고 네트워크 부하를 줄일 수도 있습니다. 아래 그림은 브라우저 캐시 의 검색 순서도입니다. 브라우저 캐시와 관련된 많은 지식 포인트가 있습니다. 여기에 그림을 편집했습니다. 브라우저 캐시에 대한 자세한 소개는 이전 기사를 참조 하십시오. 자세한 내용은 다루지 않겠습니다.

DNS 관련 최적화

DNS성명 Domain Name System. 도메인 이름과 실제 ip주소 간의 매핑 을 기록하는 인터넷의 "주소록"입니다 . 웹 사이트를 방문 할 때마다 모든 수준의 DNS서버 통해 웹 사이트 서버를 쿼리 해야 서버에 ip액세스 할 수 있습니다.

DNS관련 최적화에는 일반적으로 브라우저 DNS캐싱과 DNS사전 구문 분석 이라는 두 가지 요소가 포함됩니다 .

DNS은닉처

사진은 천 단어의 가치가 있습니다.

  • 브라우저는 먼저 브라우저 캐시를 확인합니다 (브라우저 캐시에는 크기와 시간 제한이 있음). 시간이 너무 길면 IP주소가 변경되어 올바른 IP주소를 확인 하지 못할 수 있습니다 . 너무 짧으면 브라우저가 일반적으로 몇 분 이내에 도메인 이름을 반복적으로 확인합니다.

  • 브라우저 캐시에 해당 도메인 이름이 없으면 운영 체제 캐시에서 찾습니다.

  • 찾을 수없는 경우 도메인 이름은 해당 지역의 도메인 이름 서버 (일반적으로 China Telecom, China Unicom과 같은 인터넷 제공 업체에서 제공)로 전송되며 일반적으로 해당 지역의 도메인 이름 서버에서 찾을 수 있습니다.

  • 물론 로컬 도메인 이름 서버도 찾을 수 없으며 로컬 도메인 이름 서버는 재귀 검색을 시작합니다.

일반적으로 브라우저가 DNS필요 구문 분석 20-120ms, 그래서이 DNS분석에 대한 몇 가지 최적화입니다. 그러나 웹 사이트에 다른 도메인 이름으로 사진이 많이있는 시나리오가 있습니다. 로그인 페이지에서 사용할 수있는 도메인 이름을 미리 확인하면 해상도 결과가 캐시되어 DNS해결 시간 이 단축 되고 전체 웹 사이트 액세스가 향상됩니다. 속도 향상, 그게 다 DNS预解析입니다.

DNS사전 분석

MDN DNS预解析의 정의 를 살펴보십시오 .

X-DNS-Prefetch-Control헤드는 브라우저의 DNS사전 읽기 기능을 제어합니다 . DNS미리 읽기는 브라우저가 도메인 이름 확인 기능을 수행하도록하는 이니셔티브이며 해당 범위에는 사진 CSS이든 JavaScript다른 사용자가를 클릭 할 수 있는지에 관계없이 연결된 모든 문서가 포함됩니다 URL.

사전 읽기는 백그라운드에서 수행 DNS되기 때문에 해당 링크가 완료되기 전에 해결되었을 수 있습니다. 이렇게하면 사용자가 링크를 클릭 할 때 지연을 줄일 수 있습니다.

여기서 수행하는 방법을 간단히 살펴 보겠습니다 DNS预解析.

  • 브라우저가 전체 페이지를 미리 구문 분석 할 수 있도록 페이지 헤더를 추가합니다.

<meta http-equiv="x-dns-prefetch-control" content="on">
  • 링크 태그를 통해 확인할 도메인 이름을 수동으로 추가합니다. 예를 들면 다음과 같습니다.

<link rel="dns-prefetch" href="//img10.360buyimg.com"/>

참고

Li Bing "브라우저 작동 원리 및 실행"

"보기 및 전달"은 가장 큰 지원입니다

추천

출처blog.csdn.net/liuyan19891230/article/details/108211818