성능 최적화
1. 프런트 엔드 직원 용
2. 주류, Chrome의 경우
3. 기타, 요약
최적화 : md
브라우저의 기능 및 구성
네트워크 : 브라우저는 html 텍스트, 자바 스크립트 코드, 스타일 시트, 그림, 오디오 및 비디오 파일 등과 같은 네트워크 모듈을 통해 다양한 리소스를 다운로드합니다. 네트워크 부분은 시간이 오래 걸리고 인터넷 리소스에 대한 보안 액세스가 필요하기 때문에 특히 중요합니다.
리소스 관리 : 네트워크에서 다운로드하거나 로컬에서 얻은 리소스는 관리를위한 효율적인 메커니즘이 있어야합니다. 예를 들어 반복 다운로드를 방지하는 방법, 리소스를 캐시하는 방법 등이 있습니다.
웹 브라우징 : 가장 중요한 기능인 브라우저의 핵심이자 가장 기본적인 기능입니다. 리소스를 시각적 결과로 전환하는 방법.
다중 페이지 관리 :
플러그인 및 관리 :
계정 동기화
보안 메커니즘
개발자 도구
…
브라우저의 커널 (렌더링 엔진)
브라우저에는 가장 중요한 모듈 중 하나가 있으며, 주요 기능은 요청 된 모든 리소스를 시각적 이미지로 바꾸는 것입니다.
이 모듈은 브라우저 커널이며 일반적으로 렌더링 엔진이라고도합니다.
브라우저 커널 요약 :
IE ----------> 트라이던트
Safari ------> WebKit
WebKit 자체는 주로 두 개의 작은 엔진으로 구성됩니다.
하나는 렌더링 엔진 "WebCore"이고
다른 하나는 자바 스크립트 해석 엔진 "JSCore"입니다.
둘 다 KDE의 렌더링 엔진 KHTML에서 파생됩니다. 그리고 자바 스크립트 해석 엔진 KJS가 파생됩니다.
Chrome ------> WebKit 분기 엔진 ----->
Chrome 28.0.1469.0의 13 년 출시 버전에서 깜박 이고 Chrome은 Chromium 엔진 혁명을 포기
하고 최신 Blink 엔진을 사용합니다 (Apple의 WebKit2 기반). 2010 년에 출시 된 WebKit 엔진).
이전 세대 엔진 과 비교하여 Blink는 코드를 간소화하고 DOM 프레임 워크를 개선하며 보안도 향상시킵니다.
Opera의
이전 버전의 Opera 4 ~ 6 버전 : Elektra 조판 엔진
Opera7.0 : Presto 렌더링 엔진
Opera는 2013 년 2 월에 Presto를 포기하겠다고 발표했습니다
. Chromium 엔진을 사용
하고 Blink 엔진으로 변환했습니다.
Firefox ------> Gecko
프로세스 및 스레드
프로세스 : 프로그램이 실행되면 고유 한 메모리 공간을 차지하며 운영 체제 실행의 기본 단위입니다.
프로세스에 실행중인 스레드가 하나 이상 있습니다. 프로세스가 시작된 후 자동으로 생성되는 메인 스레드입니다.
프로세스는 여러 스레드를 실행할 수도 있습니다. 프로그램이 여러 스레드에서 실행되고 있다고 말합니다.
한 프로세스의 데이터는 여러 스레드에서 공유 할 수 있으며 여러 프로세스 간의 데이터는 공유 할 수 없습니다.
스레드 : 프로세스 내에서 독립적 인 실행 단위이며 CPU 스케줄링의 가장 작은 단위입니다. 프로그램 작동의 기본 단위입니다.
스레드 풀 : 스레드 개체의 반복 사용을 실현하기 위해 여러 스레드 개체를 보유하는 컨테이너입니다.
JS 엔진은 단일 스레드에서 실행됩니다!
최신 브라우저 : 다중 프로세스, 다중 스레드 모델
1. 견딜 수없는 과거 :
브라우저를 통해 여러 페이지를 열 때 페이지 중 하나가 응답하지 않거나 충돌하면
더 불행한 일이 뒤 따르고 열려있는 모든 페이지가 표시됩니다. 응답이 없으면
가장 견딜 수없는 것은 일부 페이지에는 저장되지 않았거나 전송되지 않은 정보가 포함될 수 있습니다.
2. 브라우저 제조업체는이를 어떻게 해결합니까?
다중 프로세스 모델을 사용하여 모델은 이점을 얻을 수 있습니다
. ①. 단일 페이지의 응답이 없거나 충돌하여 전체 브라우저의 안정성을 피합니다
. ② 타사 플러그인이 충돌해도 안정성에 영향을주지 않습니다. 전체 브라우저
③. 안전
3. 브라우저에있는
프로세스 ①
브라우저 프로세스 : 브라우저 인터페이스의 표시 및 각 페이지의 관리를 담당하는 브라우저의 주요 프로세스, 브라우저에서
다른 모든 유형의 프로세스의 조상, 담당 다른 프로세스의 생성과 파괴
그것은 오직 하나있다!
②.
렌더링 과정을 : 페이지의 렌더링에 대한 책임을 웹 페이지 렌더링 과정, 여러있을 수 있습니다,의
과정, 렌더링 프로세스의 수는 필요하지 않다
③ 여는 웹 페이지 수만큼 ③ 다양한 플러그인 프로세스
④ GPU 프로세스
모바일 기기의 브라우저가 다를 수 있습니다.
안드로이드는 플러그인을 지원하지 않기 때문에 플러그인 프로세스가 없습니다.
GPU는 다음과 같이 진화했습니다. 브라우저 프로세스의 스레드
Renderer 프로세스는 여전히 독립적 인 운영 체제의 서비스 프로세스로 발전했습니다.
4. 각 프로세스 내부에는 많은 스레드가 있습니다
. 멀티 스레딩의 목적은 사용자 인터페이스의 반응성
을 높이기위한 것 입니다. 예를 들어 브라우저 프로세스의 UI 스레드가 다른 시간 소모적 인 작업 (대용량로드)의 영향을받지 않도록 방지하기 위해 파일, 로컬 파일 읽기 및 쓰기) 차단
후 이러한 작업을 처리 할 하위 스레드에 넣습니다.
렌더러 프로세스에서는 다른 작업이 렌더링 스레드의 고속 실행을 차단하지 않도록 일반적으로 렌더링 프로세스를 [파이프 라인]
하여 컴퓨터의 멀티 코어 이점을 사용하여 다양한 렌더링 단계를 실행할 수 있도록합니다. 다른 스레드 (렌더링 스레드는 느려질 수 없음)
브라우저의 렌더링 엔진
메인 모듈
-
렌더링 엔진은 주로 HTML 파서, CSS 파서, 자바 스크립트 엔진, 레이아웃 모듈, 그리기 모듈을 포함합니다.
- HTML 파서 : HTML 문서를 해석하는 파서입니다. 주요 기능은 HTML 텍스트를 DOM 트리로 해석하는 것입니다.
- CSS 파서 : 그 역할은 DOM의 각 요소 객체에 대한 스타일 정보를 계산하고 레이아웃을위한 인프라를 제공하는 것입니다.
- 자바 스크립트 엔진 : 자바 스크립트 코드를 사용하여 웹 페이지의 콘텐츠를 수정하고 CSS 정보도 수정합니다. 자바 스크립트 엔진은 자바 스크립트 코드를 해석하고 DOM 인터페이스와 CSS 트리 인터페이스를 통해 웹 페이지의 콘텐츠 및 스타일 정보를 수정할 수 있습니다. 렌더링 결과.
- 레이아웃 (레이아웃) : DOM이 생성 된 후 Webkit은 요소 객체의 동일한 유형 정보를 결합하고 크기와 위치 및 기타 레이아웃 정보를 계산하여이 모든 정보를 표현할 수있는 내부 표현 모델을 형성해야합니다.
- 그리기 모듈 (페인트) : 그래픽 라이브러리를 사용하여 레이아웃 계산 후 각 웹 페이지의 노드를 이미지 결과로 그립니다.
비고 : DOM (문서 개체 모델)
거친 렌더링 프로세스
- 페이지를 렌더링하는 브라우저의 전체 프로세스 : 브라우저는 문서를 위에서 아래로 구문 분석합니다.
- HTML 태그를 발견 하면 HTML 파서 글꼴을 호출하여 해당 토큰 (토큰은 레이블 텍스트의 직렬화)을 구문 분석하고 DOM 트리 (즉, 토큰을 저장하고 토큰 간의 관계를 설정하는 메모리 조각 )를 만듭니다. .
- 스타일 / 링크 태그가 발견되면 해당 파서가 호출되어 CSS 태그를 처리하고 CSS 스타일 트리를 구축합니다 .
- 스크립트 태그를 발견하면 javascript 엔진을 호출 하여 스크립트 태그 처리, 이벤트 바인딩, DOM 트리 / CSS 트리 수정 등을 수행합니다.
- DOM 트리와 CSS 트리를 렌더 트리 로 결합합니다 .
- 렌더 트리에 따라 렌더링하여 각 노드의 기하학적 정보를 계산합니다 (이 프로세스는 GPU에 의존해야 함).
- 마지막으로 각 노드가 화면에 그려집니다.
위의 모듈은 네트워크 스토리지 2D / 3D 이미지 오디오 비디오 디코더 및 사진 디코더를 포함하여 다른 많은 기본 모듈에 의존합니다.
따라서 렌더링 엔진에는 이러한 종속 모듈을 사용하는 방법도 포함됩니다.
둘째, 렌더링 차단
1. CSS 차단 정보 :
면책 조항 : 링크에 의해 도입 된 외부 CSS 만 차단을 일으킬 수 있습니다.
1. 스타일 태그의 스타일 :
(1) html 파서에 의해 파싱 됨
(2) 브라우저 렌더링을 차단하지 않음 ( "플래시 화면 현상"이 발생할 수 있음)
(3) DOM 파싱을 차단하지 않음;
2. 링크로 도입 된 외부 CSS 스타일 (권장 방법) :
(1) CSS 파서에 의해 파싱됩니다. 동기 분석
(2) 브라우저 렌더링 차단 (이 차단은 "플래시 화면 현상"을 방지하는 데 사용할 수 있음).
(3) 다음 js 문 실행 차단 (JS 및 CSS 스타일 지정 가능)
(4) DOM 구문 분석 (대부분의 브라우저 작동 방식)을 차단하지 마십시오.
3. 핵심 개념 최적화 : 외부 CSS의 로딩 속도를 최대한 빠르게 개선합니다
. (1) CDN 노드를 사용하여 외부 리소스를 가속화합니다.
(2) css를 압축합니다 (webpack, gulp 등과 같은 패키징 도구 사용).
(3) http 요청 수를 줄이고 여러 css 파일을 병합합니다.
(4) 스타일 시트의 코드 최적화
2. js 차단 정보 :
1. 후속 DOM 구문 분석 차단 :
이유 : 브라우저가 후속 스크립트의 내용을 알지 못합니다. 다음 DOM이 먼저 구문 분석되고 후속 js가 후속 DOM을 모두 삭제
하면 브라우저가 쓸모없는 작업을 수행하고 브라우저는 스크립트에서 수행되는 특정 작업을 예측할 수 없습니다. 예를 들어 document.write와 같은 작업은
단순히 중지됩니다. 스크립트가 실행 된 후 브라우저는 계속해서 DOM을 아래쪽으로 구문 분석합니다.
2. 블록 페이지 렌더링 :
이유 : JS는 DOM에 대한 스타일을 설정할 수도 있고, 브라우저는 스크립트가 실행될 때까지 기다렸다가 최종 결과를 렌더링하여 쓸모없는 작업을 피합니다.
3. 후속 js의 구현 차단 :
이유 : 종속성을 유지하기 위해, 예를 들면 : jQuery의 도입은 부트 스트랩을 다시 도입해야합니다.
3. 비고
[참고 1] : CSS 파싱과 js 실행은 상호 배타적 (상호 배타적), js는 css가 파싱되면 실행을 중지하고, css는 js가 실행되면 파싱을 중지합니다.
[참고 2] : 차단 css, js 또는 차단 여부에 관계없이 외부 자산 (이미지, 비디오, 스타일, 스크립트 등)을로드하기 위해 브라우저가 막히지 않습니다.
이유 : 항상 브라우저에서 : "요청이 이루어집니다" 작업 모드
는 그림, 스타일, 스크립트 등 네트워크 요청의 내용을 포함하는 한 먼저 리소스를 얻기 위해 요청을 보냅니다. 리소스가 로컬로 사용될 때
브라우저 자체가 조정합니다. 이 접근 방식은 매우 효율적입니다.
[참고 3] : WebKit과 Firefox 모두 [사전 분석] 최적화를 수행했습니다. js 스크립트를 실행할 때 브라우저의 다른 스레드는 문서의 나머지 부분을 미리 구문 분석하고 네트워크를 통해로드해야하는 다른 리소스를 찾아로드합니다. 이러한 방식으로 리소스를 병렬 연결에로드
하여 전체 속도를 높일 수 있습니다. 사전 구문 분석기는 DOM 트리를 수정하지 않습니다.
위의 프로세스에서 "DOMContentLoaded"및 "onload"이벤트는
각각 DOM 트리가 생성 (파싱) 된 후, 그리고 DOM 트리가 생성되고 리소스가 생성 된 후에 웹 페이지를로드 및 렌더링하는 동안 트리거됩니다. 웹 페이지가로드됩니다.
- 위는 완전한 렌더링 프로세스이지만 많은 최신 웹 페이지는 동적입니다. 즉, 렌더링이 완료된 후 웹 페이지의 애니메이션 또는 사용자 상호 작용으로 인해
브라우저가 렌더링 프로세스를 반복적으로 실행했습니다. (다시 그리기 및 재정렬) 위의 숫자는 기본 순서를 나타내며 엄격하게 일치하지 않습니다.
이 과정은 반복되거나 교차 될 수 있습니다.
브라우저마다 CSS 파서가 다릅니다.
브라우저는 무언가에 대한 서버를 찾습니다.
응답 수신 : 수신 된 데이터의 "응답 헤더", 상태 코드
데이터 수신 : 실제 데이터가 전송되고 있습니다.
스타일 렌더링
비동기 분석 : 비 차단. (더 효율적)-콜백
동기 분석 : 차단.
1. Style 태그의 스타일은 HTML 파서에 의해 구문 분석됩니다.
2. 페이지 스타일 태그에 작성된 내부 스타일이 비동기 적으로 구문 분석됩니다 (플래시 화면 현상이 발생하기 쉽습니다).
3. 브라우저가 리소스를로드합니다 [비동기]
외부 CSS 렌더링 연결
리소스에 대한 브라우저 액세스는 비동기식입니다.
1. 링크가 들어오는 스타일은 구문 분석 스타일 시트 (CSS)에 의해 구문 분석되고 동 기적으로 구문 분석됩니다.
2. CSS 파서가 페이지 렌더링을 차단합니다. (링크가 들어오는 외부 스타일은 페이지 렌더링을 차단하고 스플래시 화면을 피합니다)
3. 링크 사용을 권장합니다.
CSS 레이어
레이아웃 : 레이아웃 ---- 정렬 --------- 재정렬 (재정렬 / 리플 로우)
페인트 : 그리기 ---- 그리기 -------- 다시 그리기 (다시 그리기)
브라우저가 페이지를 렌더링 할 때 페이지를 크고 작은 레이어가있는 여러 레이어로 나누고 각 레이어에는 하나 이상의 노드가 있습니다.
레이어 생성 조건
Chrome 브라우저는 다음 조건 중 하나가 충족되면 레이어를 생성합니다.
-
3D 변형 (translateZ)이있는 CSS 속성 보유
-
비디오 태그와 함께 가속 비디오 디코딩 노드 ------ 사용
-
노드가 있습니다
-
CSS3 애니메이션 노드
-
CSS 가속 속성이있는 요소 (변경 예정)
DOM을 렌더링 할 때 브라우저가 실제로하는 일은 다음과 같습니다.
1. 获取DOM后分割为多个图层
2. 对每个图层的节点计算样式结果 （Recalculate style--样式重计算）
3. <font color=red>为每个节点生成图形和位置 </font> （Layout--布局，重排,回流）
4. <font color=red>将每个节点绘制填充到图层位图中 </font> （Paint--重绘）
5. <font color=red>图层作为纹理上传至GPU</font>
6. 组合多个图层到页面上生成最终屏幕图像 （Composite Layers--图层重组）
다시 칠하기
다시 그리기는 윤곽선 및 배경색과 같은 속성 변경과 같이 요소의 모양이 변경 될 때 트리거되는 브라우저 동작입니다. 브라우저는
요소 의 새 속성에 따라 다시 그려 요소에 새로운 모양을 부여합니다. 다시 그리기는 다시 레이아웃을 가져 오지 않으므로 반드시 다시 배열을 수반하지는 않습니다.
다시 그리기와 재정렬은 모두 레이어를 기준으로하며 레이어의 요소를 다시 그려야하는 경우 전체 레이어를 다시 그려야합니다.
따라서 성능을 향상 시키려면 이러한 "변화하는 것"에 자체 레이어가 있어야
하지만 다행스럽게도 대부분의 브라우저는 CSS3 애니메이션 노드를위한 레이어를 자동으로 생성합니다.
재배치 (리플 로우라고도 함 : 리플 로우)
렌더 객체가 생성되어 렌더 트리에 추가 될 때 위치 및 크기 정보가 포함되지 않습니다. 이러한 값을 계산하는 과정을 레이아웃 또는 재 배열이라고합니다.
예를 들어, 웹 페이지 요소의 색상을 변경하면 레이아웃이 변경되지 않았기 때문에 "재정렬"이 아닌 "재정렬"만 트리거됩니다.
"리플 로우"는 대부분의 경우 "다시 그리기"로 이어집니다. 예를 들어 웹 페이지 요소의 위치를 변경하면 레이아웃이 변경되기 때문에 "리플 로우"와 "다시 그리기"가 모두 트리거됩니다.
다시 그리기를 트리거하는 속성
- 색상 * 배경 * 윤곽선 색상
rder 스타일 * 배경 이미지 * 윤곽선- border-radius * background-position * outline-style
sibility * background-repeat * outline-width- 텍스트 장식 * 배경 크기 * 상자 그림자
- border-radius * background-position * outline-style
재 배열 (리플 로우)을 트리거하는 속성
- width * top * text-align
ight * bottom * overflow-y- padding * left * font-weight
rgin * right * overflow- 디스플레이 * 위치 * 글꼴 패밀리
rder-width * float * line-height- border * clear * vertival-align
n-height * 공백
- border * clear * vertival-align
- 디스플레이 * 위치 * 글꼴 패밀리
- padding * left * font-weight
(Key) 일반적인 재배치 작업
Reflow (재정렬) 비용은 Repaint (재 페인트) 비용보다 훨씬 높습니다.
노드의 리플 로우는 하위 노드의 리플 로우로 이어 지거나 상위 노드와 동일한 레벨의 노드로 이어질 수 있습니다.
일부 고성능 컴퓨터에서는 그다지 많지 않을 수 있지만 Reflow가 휴대폰에서 발생하면 프로세스가 매우 고통스럽고 전력 소모가 많습니다.
(H5로 개발 된 게임은 모바일 단말기에 열이 발생하여 전력 소모가 심합니다.)
따라서 다음 작업은 상대적으로 비용이 많이 듭니다.
1. DOM 노드를 추가, 삭제 또는 수정하면 Reflow 및 Repaint가 발생합니다.
2. DOM의 위치를 이동할 때
3. CSS 스타일을 수정할 때.
4. 창 크기를 조정할 때 (창 확대 및 축소) (모바일 단말기의 확대 / 축소가 레이아웃 뷰포트에 영향을주지 않기 때문에이 문제가 없습니다.)
5. 웹의 기본 글꼴을 수정하는 경우 페이지.
[속성 (너비, 높이 ...)을 얻을 때! ! ! ! ! 】
참고 : display : none (비 점유 숨김)은 리플 로우를 트리거하고, visible : hidden (점유 숨김)은 위치 변경이 없기 때문에 다시 그리기 만 트리거합니다.
다시 그리기 및 재정렬을위한 최적화 된 구성표
페이지를 렌더링 할 때 브라우저가 다음과 같은 "상세한"단계를 거쳤 음을 알고 있습니다.
1. 计算需要被加载到节点上的样式结果（Recalculate style--样式重计算）*
2. 为每个节点生成图形和位置（Layout--重排或回流）
3. 将每个节点填充到图层中（Paint--重绘）
4. 组合图层到页面上（Composite Layers--图层重组）
如果我们需要提升性能，需要做的就是减少浏览器在运行时所需要做的工作，即：尽量减少1234步。
[구체적인 최적화 방식은 다음과 같습니다.] :
1. CSS3 변형을 사용하여 요소 위치를 변환 할 때 왼쪽 상단 및 기타 작업을 대체하십시오. 변형
및 불투명도 변경 은 레이어 조합에만 영향을 미칩니다.
2. 가시성 대신 사용 불투명도] (1) 가시성을 사용하면 재배치가 트리거되지 않지만 여전히 다시 그려집니다. (2) 다시 그리기를 트리거하는 불투명도를 직접 사용하고 재배치를 트리거합니다 (GPU는 지상에서 설계되었습니다!). (. 3). 불투명도 레이어 사용, 즉 트리거를 트리거하지 않고 재 배열을 다시 그리지 않습니다 . (의지가 변경되는 불투명도) 이유 : 투명도를 변경할 때 원하는 효과를 얻기 위해 그림이 이미 좋은 텍스처 알파 값이었을 때 GPU를 줄이기 전에 전체를 다시 그릴 필요가 없습니다. 하지만이 전제는이 불투명도 자체가 수정 된 레이어 여야한다는 것입니다. 3. [테이블 레이아웃 사용 안함] table-cell 4. [스타일 속성을 변경하는 여러 작업을 하나로 결합] 작업 DOM의 스타일을 하나씩 수정하지 말고 미리 클래스를 정의한 다음 DOM의 className 수정 5. [Modify the DOM after offline ()] display attribute가 none 인 요소가 렌더 트리에 없으므로 숨겨진 요소에 대한 작업으로 인해 다른 요소가 재정렬되지 않습니다. 요소에 대해 복잡한 작업을 수행하려면 먼저 숨긴 다음 작업이 완료된 후 표시 할 수 있습니다. 이것은 숨겨지고 표시 될 때만 2 개의 재 배열을 트리거합니다. 6. [Using document Fragment] (documentFragment) ------ Vue는 성능 향상을 위해이 메서드를 사용합니다.
7. [루프 변수로 특정 DOM 노드의 속성 값을 루프에 넣지 마십시오.]
브라우저에서 일부 스타일 정보를 요청하면 브라우저가 다음과 같은 큐를 플러시합니다.
1.offsetTop, offsetLeft, offsetWidth, offsetHeight
2.scrollTop / Left / Width / Height
3.clientTop / Left / Width / Height
4.width, height
위의 속성 중 일부를 요청할 때 가장 정확한 값을 제공하기 위해 브라우저는 내부 대기열을 새로 고쳐야
합니다. 이러한 값에 영향을 미치는 작업이 대기열에있을 수 있기 때문입니다. 최근에 발생했거나 변경된 레이아웃 정보와 관련이없는 요소의 레이아웃 및 스타일 정보를 가져 오더라도 브라우저는 렌더링 대기열을 강제로 새로 고칩니다.
8. 애니메이션 구현 과정에서 GPU 하드웨어 가속을 활성화합니다. transform : tranlateZ (0)
9. 애니메이션 요소에 대한 새 레이어를 만들어 애니메이션 요소의 Z- 색인을
늘립니다. 10. 애니메이션을 작성할 때 다음 APIrequestAnimationFrame을 사용해보십시오. ---- 애니메이션 프레임 요청
requestAnimationFrame ---- 애니메이션 프레임 요청
1.window.requestAnimationFrame ()
설명 :이 메서드는 다음 다시 그리기 및 재배치 전에 지정한 함수를 호출하도록 브라우저에 지시
합니다 .. 1. 매개 변수 :이 메서드는 콜백 함수를 매개 변수로 사용 하며이 콜백 함수는 브라우저 다음에 다시 그리기 전에 호출됩니다.
콜백 함수는 requestAnimationFrame ()이 콜백 함수를 트리거하기 시작할 때 현재 시간을 식별하는 매개 변수 DOMHighResTimeStamp에 자동으로 전달됩니다.
2. 반환 값 :
콜백 목록에서 유일한 식별자 인 긴 정수, 요청 ID입니다. 0이 아닌 값이며 다른 의미가 없습니다. 이 값을 window.cancelAnimationFrame ()에 전달하여 콜백 함수를 취소 할 수 있습니다. 참고 : 다음 브라우저를 다시 그리기 전에 다음 프레임 애니메이션을 계속 업데이트하려면 콜백 함수 자체를 다시 호출해야합니다. window.requestAnimationFrame ()
2. window.cancelAnimationFrame (requestID)
는 window.requestAnimationFrame () 메서드를 호출하여 이전에 계획에 추가 된 애니메이션 프레임 요청을 취소합니다.
requestID는 window.requestAnimationFrame () 메서드가 이전에 호출되었을 때 반환되는 값으로 시간 식별자이며 사용법은 타이머의 ID와 유사합니다.
CDN
빠른 CDN
[외부 링크 이미지 전송 실패. 원본 사이트에 안티 리치 링크 메커니즘이있을 수 있습니다. 이미지를 저장하고 직접 업로드하는 것이 좋습니다. (img-Guch56JJ-1604846375736) (F : \ WEB \ WEB \ 009-git, svn , 모듈화, 최적화 \ 009 -git, svn, modularization, 최적화 \ 성능 최적화 _stu \ icon \ 01_web 프런트 엔드 및 백 엔드 전체 icon.png)]
CDN이란 무엇입니까? 어떻게 작동합니까?
웹 사이트는 일반적으로 모든 서버를 동일한 위치에 배치합니다. 사용자 기반이 증가하면 회사는 지리적으로 다른 여러 서버에 콘텐츠를 배포해야합니다.
http 요청 시간을 단축하려면 많은 수의 정적 리소스를 배치해야합니다. 사용자에게 더 가깝습니다.
Content Delivery Networks CDN (Content Delivery Networks)
CDN은 다양한 지리적 위치에 분산 된 웹 서버 그룹으로, 사용자에게 콘텐츠를보다 효과적으로 배포하는 데 사용됩니다.
기본 아이디어 :
데이터 전송 속도와 안정성에 영향을 미칠 수있는 인터넷상의 병목 현상과 링크를 피하여 콘텐츠 전송이 더 빠르고 안정적 일 수 있도록하십시오.
기존 인터넷을 기반으로 한 지능형 가상 네트워크 계층으로 구성된 네트워크의 다양한 위치에 노드 서버를 배치함으로써
CDN 시스템은 네트워크 트래픽과 각 노드의 연결, 부하 상태, 사용자와의 거리 및 실시간 응답 시간 이러한 포괄적 인 정보
는 사용자의 요청을 사용자와 가장 가까운 서비스 노드로 리디렉션합니다.
인프라 : 가장 간단한 CDN 네트워크는 DNS 서버와 여러 캐시 서버로 구성됩니다
1. 사용자가 입력 한 URL은 DNS 확인을 통해 해당 IP 주소로 "변환"되어 CDN 전용 서버를 찾습니다.
2. CDN은 사용자의 IP 주소를 "가져온"다음 지역 부하 분산 장치와 협력하여 사용자가 속한 영역에서 지역 부하 분산 장치를 선택하고 사용자에게이 장치에 대한 요청을 시작하도록 알립니다.
3. 위의 단계에서 "선택"기준
(1) 선택 기준은 사용자의 IP 주소에 따라 사용자와 가장 가까운 서버 판단,
(2) URL에 포함 된 콘텐츠 이름으로 판단하는 것입니다. 서버는 사용자가 요구되는 콘텐츠가 사용자에 의해 요청]
. (3) 각 서버의 조회 전류 부하 상황 여전히 서비스 용량을 갖는 서버를 결정한다.