프런트엔드 성능 최적화를 잘 수행하는 방법

프런트엔드 필수 도구(무료 이미지 베드, API, ChatAI 및 기타 실용적인 도구)에 대한 권장 웹사이트:

http://luckycola.com.cn/

머리말:

프론트엔드 성능 최적화는 항상 프론트엔드 개발자들이 주목해야 할 고전적인 주제였습니다. 지속적인 기술 발전으로 인해 웹 페이지 컨테이너(브라우저, 웹뷰)의 성능은 점점 더 강력해지고 있지만 기능은 점점 더 강력해지고 있습니다. 웹 사이트 애플리케이션도 지속적으로 풍부해지고 크기도 크지 않습니다. 증가를 방지하기 위해 네트워크 환경 및 기타 요인이 좋지 않은 경우 흰색 화면 시간이 길어지는 등 사용자 경험에 심각한 영향을 미치는 문제가 여전히 있을 수 있습니다. , 프론트 엔드의 성능 최적화를 이해하는 것이 필수적이며 프론트 엔드 취업 면접에서도 중요한 부분입니다.자주 묻는 질문.오늘 우리는 이 문제에 대해 심도있게 논의합니다.

1. 페이지 렌더링 원리

우리는 인터뷰에서 다음과 같은 질문을 하는 면접관을 자주 접합니다. 브라우저가 페이지를 렌더링하기 위해 무엇을 하는지 아십니까?

실제로 이것은 프런트엔드 검사에 있어서 매우 고전적인 질문이며, 오늘 " 프론트엔드 성능을 최적화하는 방법 "에 대한 논의의 핵심 배경 질문이기도 합니다. 성능은 문제의 근원부터 시작해야 합니다.. 따라서 프론트엔드의 성능을 최적화하기 위해서는 문제의 원인을 이해해야 하며, 그 다음에는 페이지 렌더링의 원리를 간단히 이해하면 됩니다.

브라우저가 페이지를 렌더링하는 전체 과정을 두 가지로 나누어 보면, 첫 번째 단계는 주로 브라우저가 페이지를 렌더링하는 데 필요한 리소스를 요청하는 부분이고, 두 번째 단계는 브라우저가 리소스를 획득하여 렌더링 부분을 최적화하는 단계입니다.

첫 번째 부분은 주로 네트워크와 같은 환경적 요인에 따라 달라지며, 두 번째 부분은 "Critical Rendering Path " 의 최적화 요소에 따라 달라집니다 . 또한 최적화 계획에서 우리가 집중해야 할 부분이기도 합니다.

주요 렌더링 경로 다이어그램

(1)、돔 트리

DOM은 JS를 통해서만 액세스할 수 있는 것이 아닙니다.DOM 확장 가능한 벡터 그래픽 SVG, 수학적 마크업 언어 MathML 및 동기식 멀티미디어 통합 언어 SMIL 에는 언어 고유의 메소드와 인터페이스가 추가되었습니다 . HTML이 구문 분석되면 DOM 트리가 구축됩니다 . 아래 코드에는 header, main및 의 세 가지 영역이 있습니다 footer. 그리고 외부 파일style.css 로 .

위의 코드를 HTML브라우저에서 DOM树구조 로 해석하면 각 노드의 관계는 다음과 같습니다.

(2)、CSSOM 트리

CSSOM또한 객체 기반 트리입니다. DOM 트리와 관련된 스타일을 처리하는 역할을 담당 합니다 .

위 CSS 선언의 경우 CSSOM树다음과 같이 나타납니다.

의 일부 속성은 상속css 될 수 있으므로 상위 노드에 정의된 속성이 조건을 충족하면 하위 노드도 해당 속성 정보를 갖게 되며 최종적으로 해당 스타일 정보가 페이지에 렌더링됩니다. '

(2)、렌더 트리:

브라우저가 DOM 트리를 구성하는 동안 또 다른 트리인 렌더 트리도 구성합니다. 주요 기능은 CSS 관련 지식을 사용하여 특정 레이아웃과 스타일에 따라 HTML을 표시하는 것입니다. MVC의 관점에서 보면 렌더 트리는 V, dom 트리는 M, C는 HTMLDocumentParser와 같은 특정 스케줄러로 간주할 수 있습니다.

2. 프론트엔드 성능 최적화 실습

(1) 렌더링 임계 경로 최적화

(1) HTML 파일의 크기는 가능한 작아야 합니다.

목적은 클라이언트가 가능한 한 빨리 완전한 HTML을 수신할 수 있도록 하는 것입니다. 일반적으로 HTML에는 중복되는 문자가 많이 있습니다.

예: JS 주석, CSS 주석, HTML 주석, 형식 및 줄 바꿈. 더 안타까운 점은 낡은 코드가 많이 포함된 프로덕션 환경에서 HTML을 많이 봤다는 점인데, 이는 시간이 지날수록 프로젝트가 점점 커지고 여러 가지 이유로 이력에 문제가 남아 있기 때문일 수도 있지만, 어쨌든 이건 다 나쁘다. 프로덕션 환경의 HTML의 경우 HTML 파일을 최대한 간소화하려면 불필요한 코드를 제거해야 합니다.

(2) CSSOM 및 렌더링 차단 CSS 최적화

CSS는 렌더 트리를 구축하기 위한 필수 요소로, 웹페이지를 처음 구축할 때 CSS에 의해 JavaScript가 차단되는 경우가 많습니다. 필요하지 않은 CSS가 중요하지 않은 리소스(예: 인쇄 및 기타 미디어 쿼리)로 표시되었는지 확인하고( 그림 3.1 ) 중요한 CSS의 양을 최대한 줄이고 배달 시간을 보장해야 합니다. 가능한 한 짧게.

위에서 언급한 최적화 전략 외에도 CSS에는 성능에 영향을 미칠 수 있는 또 다른 요소가 있습니다. CSS는 중요한 렌더링 경로를 차단합니다. CSS는 중요한 리소스이며 중요한 렌더링 경로를 차단하는 것은 놀라운 일이 아니지만 일반적으로 모든 CSS 리소스가 그렇게 "중요"하지는 않습니다.

예를 들어 일부 반응형 CSS는 화면 너비가 조건을 충족할 때만 적용되고, 일부 CSS는 페이지가 인쇄될 때만 적용됩니다. 이러한 CSS는 조건을 충족하지 않으면 적용되지 않습니다. 그런데 왜 브라우저가 필요하지 않은 CSS 리소스를 기다리게 합니까?

그림 3.1에서 볼 수 있듯이

(3) CSS에서 @import를 사용하지 마세요.

CSS를 로드하기 위해 @import를 사용하지 않도록 모두가 알아야 할 사항입니다. 실제 작업에서는 CSS를 이렇게 로드하지 않을 텐데 왜 그럴까요?

이는 @import를 사용하여 CSS를 로드하면 중요한 경로 길이가 추가되기 때문입니다. 예를 들어:

그림 4.1과 같이 index.html 파일에 style.css를 연결한 후 style.css에 있는 main.css 파일을 가져오면 두 개의 종속 파일이 순차적으로 로드 됩니다 . 로드된 스타일 파일은 다음과 같습니다. 두 파일에 소요된 시간(그림 4.2)

그림 4.1:

그림 4.2:

그림 4.3 과 같이 style.css와 main.css를 index.html의 링크를 통해 직접 import하면 병렬로 로딩되기 때문에 파일 로딩 시간이 더 오래 걸린다 (그림 4.4).

(4) js 파일을 로드하는 방법을 최적화합니다.

브라우저는 HTML 파싱 과정에서 Scripe를 만나면 HTML 페이지 렌더링을 차단하고, 페이지 요청을 보내고, JS 스크립트 코드를 전달한 후 JS 엔진에 넘겨서 코드를 실행하게 되는데, 실행이 완료되면, 브라우저는 계속해서 HTML을 구문 분석합니다. 개략도는 다음과 같습니다.

js 파일을 로드한 후 html을 차단하지는 않지만 여전히 지속 시간을 줄일 수는 없습니다.

async 키워드를 사용하여 js 파일을 비동기적으로 로드하지만 js 실행으로 인해 여전히 html 로드가 차단됩니다.

defer 키워드를 사용하여 js 파일을 비동기적으로 로드하지만 js 실행이 지연되고 html 로드가 차단되지 않습니다.

또한 preload 및 prefetch와 같은 일반적인 솔루션이 있습니다.

(2) 디자인 패턴 최적화의 적절한 활용

(1) 반복되는 인스턴스화를 방지하기 위해 싱글톤 모드를 사용합니다.

많은 경우 페이지에서 고정된 기능을 가진 하나의 클래스만 인스턴스화할 수 있습니다. 이는 코드의 가독성과 유지 관리를 용이하게 할 뿐만 아니라 성능 오버헤드를 크게 보장하고 메모리 로드 압력을 줄입니다. 따라서 이를 보장하는 방법은 하나의 클래스를 인스턴스화할 수 있습니까? 클래스는 어떻습니까? 예는 다음과 같습니다.

(2) 빅 데이터 노드 렌더링(페이징 및 기타 시나리오)에 플라이웨이트 모드 사용

실제 개발 시나리오에서는 페이징과 같은 빅데이터 프런트엔드 렌더링 노드가 필요한 경우가 종종 있지만, 프런트엔드 js를 직접 조작하는 것이 성능을 가장 많이 소모하는 동작이라는 것을 알고 있습니다. DOM 노드에 대한 직접적인 작업을 줄이기 위해 최선을 다하십시오.이 출발점을 기반으로 디자인 패턴의 플라이웨이트 패턴은 우리에게 좋은 솔루션을 제공합니다.

다음으로 플라이웨이트 모드를 사용하지 않고 페이징 논리를 살펴보겠습니다.

Flyweight 모드를 사용한 후의 코드는 다음과 같습니다.

주목할 가치가 있습니다.

Flyweight 모드에서는 데이터 양이 아무리 많아도 코드는 해당 5개의 DOM 노드만 직접 작동합니다.페이징 동작은 DOM 노드를 반복적으로 추가하지 않고 동일한 5개의 노드의 내용만 수정합니다.5개의 노드는 항상 공유됩니다.플라이웨이트 모드를 사용하지 않으면 동일한 수의 DOM 노드가 생성되고 데이터 양에 따라 표시 속성이 전환됩니다.두 솔루션의 성능 소모는 분명합니다.

( 3 ) 스로틀링 과 디바운스 의 적절한 사용

손떨림 방지 및 조절은 일반적으로 사용자가 작업 실행을 트리거하기 위해 짧은 시간 내에 여러 작업을 빠르고 자주 수행하는 것을 방지하기 위해 프로젝트 최적화 수단으로 사용됩니다. 예를 들어, 사용자가 제출 버튼을 여러 번 클릭하여 양식의 여러 제출을 트리거하는 것을 방지하고, 사용자가 스크롤 막대를 당기는 것을 방지하고, 여러 로드를 트리거하는 등을 방지합니다.

디바운스의 특징은 이벤트가 빠르게 연속적으로 트리거될 때 해당 작업이 한 번만 실행된다는 것입니다.

손떨림 방지와 스로틀링의 본질은 다릅니다. 흔들림 방지는 여러 번 실행되지만 한 번만 실행됩니다. 조절은 여러 번 실행되지만 주기에 한 번만 실행됩니다.

조절(Throttling) 조절 전략은 이벤트가 몇 번이나 트리거되었는지에 관계없이 각 기간에 하나의 작업만 실행하는 것입니다. 이전 기간이 종료된 후 다른 이벤트가 트리거되어 새 기간이 시작되며 새 기간은 하나의 작업만 실행합니다.

그 밖에도 디자인 패턴의 종류는 매우 다양합니다. 관심이 있으시면 "javaScript Design Patterns"라는 책을 읽어보시기 바랍니다. 다음은 몇 가지 고전적인 예입니다.

(3) 기타 일반적인 최적화 방식

(1), 지연 로딩

리소스의 지연 로딩

로딩의 핵심은 "지연 로딩"입니다. 모든 미디어 리소스, CSS, JavaScript, 이미지 또는 HTML지연 로드가 가능합니다. 제한된 페이지 콘텐츠를 한 번에 로드하면 중요한 렌더링 경로가 향상될 수 있습니다.

이 전체 페이지의 CSS, JavaScript및 을 로드하지 마십시오 HTML.
button대신, 사용자가 버튼을 클릭할 때만 스크립트를 로드하는 이벤트 리스너를 추가할 수 있습니다 .
Webpack지연 로딩 기능을 완료하는 데 사용됩니다 .

다음은 순수 JavaScript를 사용하여 지연 로딩을 구현하는 몇 가지 기술입니다.

예를 들어, 이제 또 다른 이러한 경우 및 태그 와 함께 제공되는 기본 속성을<img/>/<iframe/> 활용할 수 있습니다 . 브라우저가 이 태그를 보면 로딩을 연기 하고 .<img><iframe>loadingiframeimage

(2) 웹워더의 합리적인 사용

우리 모두 알고 있듯이 JavaScript는 단일 스레드에서 실행됩니다. 모든 작업은 하나의 스레드에서 실행됩니다. 다음 작업은 현재 작업이 실행된 후에만 처리될 수 있습니다. 그렇지 않으면 다음 작업은 대기만 할 수 있으므로 전체 사용이 제한됩니다. 멀티 코어 컴퓨터의 컴퓨팅 성능. 동시에 브라우저에서 JavaScript 실행은 일반적으로 메인 스레드에 위치하며 스타일 계산, 페이지 레이아웃 및 그리기와 함께 발생하며 JavaScript가 너무 오랫동안 실행되면 필연적으로 다른 작업이 차단됩니다. 프레임 손실이 발생합니다.

이를 위해 일부 순수 컴퓨팅 작업을 JavaScript 실행을 위한 멀티 스레드 환경을 제공하는 Web Worker로 마이그레이션할 수 있으며, 메인 스레드는 Worker 하위 스레드를 생성하여 자체 작업 실행 압력의 일부를 공유할 수 있습니다. Worker 하위 스레드에서 실행되는 작업은 메인 스레드를 방해하지 않으며 작업이 완료된 후 결과가 메인 스레드로 반환됩니다. 이는 메인 스레드가 UI 상호 작용 처리에 더 집중할 수 있다는 장점이 있습니다. 페이지 이용 과정을 경험해 보세요.

(3) 스켈레톤 화면은 흰색 화면의 지속 시간을 최적화합니다.

스켈레톤 스크린을 사용하면 화이트 스크린 시간을 단축하고 사용자 경험을 향상시킬 수 있습니다. 대부분의 중국 주류 웹사이트는 스켈레톤 화면을 사용하며, 특히 휴대폰의 SPA 단일 페이지 애플리케이션 Vue 또는 React에 관계없이 초기 HTML은 비어 있고 JS를 로드하여 컨텐츠를 루트 노드에 마운트해야 합니다. 이로 인해 부작용이 설정됩니다. 메커니즘: 장기간 흰색 화면이 발생합니다. 일반적인 뼈대 화면 플러그인은 이 원칙을 기반으로 합니다. 프로젝트를 패키징할 때 뼈대 화면의 내용은 html 파일의 루트 노드에 직접 배치됩니다. 스켈레톤 화면 플러그인, 패키지된 html 파일(루트 노드 내부는 스켈레톤 화면입니다):

동일한 프로젝트에 대해 스켈레톤 화면을 사용하기 전과 후의 FP 흰색 화면 시간을 비교하세요.

뼈대가 없는 화면: 흰색 화면이 오래 지속됩니다.

해골 스크린으로: 백색 스크린

스켈레톤 스크린 플러그인 권장 사항: vue-skeleton-webpack-plugin

결론

프론트엔드 성능 최적화는 항상 프론트엔드 개발 분야의 고전적인 주제였습니다. 기술이 발전함에 따라 점점 더 많은 솔루션이 등장했습니다. 기사의 길이가 제한되어 있기 때문에 여기서는 일부 고전적인 최적화 솔루션만 논의합니다. . 관심이 있으시면 더 많은 다양한 자료와 공유할 도서를 확인하실 수 있습니다.