개발자가 HTML5 성능 분석에 대해 알아야 할 사항

의견 : 다음 기사는 Zhang Liming이라는 IT 기술자가 작성했으며 InfoQ 웹 페이지에 게시되었습니다. 이번에는 전체 텍스트의 9 가지 다른 측면에서 HTML5의 성능을 분석했으며, 이는 여전히 해당 개발자가 읽을 가치가 있습니다.

첫째, 사용자 가독성의 관점에서, 처음으로 초보자가 처음으로 이해하지 못했던 많은 것들이 있었으며, HTML5 선언 방법은 사용자에게 더 친숙합니다.

둘째, 문서 인코딩 선언은 HTML5에있는 경우 매우 간단합니다. 많은 사람들이 HTML5가 무엇인지 묻습니다. 우리는 HTML5를 먼저 사용할 수있는 방법은 많은 페이지가 여전히 전통적인 방식이기 때문에 DocType를 먼저 변경하는 것입니다. HTML5 방법은 IE 브라우저와 호환되며 IE6에서 IE10으로 사용할 수 있으며 고급 브라우저에서 지원할 수 있습니다. 따라서 HTML5를 수용하는 가장 쉬운 방법은 DocType을 변경하는 것입니다.

다음은 그다지 흔하지 않을 수 있지만 더 간단한 레이블 방법을 사용하여 선호하는 것입니다. 이 이름에서 알 수 있듯이 HTML5는 HTML4에서 상속됩니다. HTML4는 엄격한 모드 및 전환 모드를 갖습니다. HTML5는이 전환 모드를 지원하므로 일부 태그를 닫을 수 없습니다. 그러나 모든 태그를 권장하지는 않습니다. 예를 들어, 바디 태그가 닫히지 않았으므로 권장하지 않습니다. 그러나 가장 일반적으로 사용되는 P- 라벨은 목록 태그 Li입니다. 왜 이것을 말합니까? 우선, 시각적 인 관점 에서이 방법은 약간 간단합니다. 핵심은 문서 전송 과정에서 내용이 적다는 것입니다.

HTML5 태그 속성 선언은 단일 괄호, 이중 괄호 및 브랜치 브래킷의 세 가지 방법을 지원합니다. 문서의 크기를 줄이기 위해 이중 인용문이나 단일 따옴표없이 메소드를 선택했습니다. 그러나 속성에는 여러 클래스가 포함될 수 있고 여러 클래스가 괄호 안에 둘러싸여 있어야하기 때문에 클래스 속성 선언이라고 가정해야합니다. 이와 관련하여 Google의 연습을 보여 드리겠습니다. Google 자체에는 위의 내용을 완전히 연습하여 문서 크기를 20%줄이고 HTML 문서의 전송을 20%줄입니다. 모든 것이 실행되면 5%에서 20% 사이의 감소를 달성 할 수 있습니다. 이것은 HTML 문서의 크기를 줄이는 첫 번째 단계입니다.

다음은 그림의 최적화에 관한 것입니다. 그림은 항상 사랑과 증오하는 요소입니다. 그림이 너무 많으면 전체 페이지의 로딩 속도가 심각하게 드래그됩니다. 사진의 최적화 방법과 관련하여, "고성능 웹 사이트"책에는 많은 소개가 있습니다. 요약하면, 엘프 사용, 그림 크기 최적화 및 데이터 URI 사용의 세 가지 주요 요점이 있습니다. 나는 여기서 세부 사항으로 들어 가지 않을 것입니다.

이미지 최적화에 대한 또 다른 아이디어는 : No-Image입니다. 그림을 버리고 CSS3를 포용하십시오. 원래, 나는 둥근 코너 효과가있는 그림을 설정해야했지만 이제는 CSS3에서 Border-Radius를 사용했습니다. 그림자 효과와 함께 그림을 사용했지만 이제는 CSS3에서 Box-Shadow를 사용합니다. 그라디언트 배경 이미지를 설정했지만 이제는 CSS3에서 그라디언트를 사용합니다.

3. 사전 가져 오기

다음으로 Prefetching에 대해 이야기 해 봅시다. 이것은 또 다른 최적화 방법입니다. 우리의 현재 최적화 아이디어는 거의 없습니다. 그들 중 다수는 예를 들어, 문서 크기가 이전에 줄어들고 이미지 크기가 줄어드는 것과 같이 적은 수의 관점에서 나온 것입니다. 많은 사진이 엘프가되어 보내는 요청 수를 줄입니다. 프리 페치의 경우 또 다른 사고 방식입니다. 자원을 조기 로딩합니다. 사용자가 요점으로 가면 실제로로드되었으므로 확실히 더 빠릅니다.

프리 페치에는 두 가지 부분이 있습니다. 하나는 리소스의 프리 페치이고 다른 하나는 DNS의 사전 분리입니다.

리소스가 사전로드 시점에 주목해야 할 몇 가지 사항이 있습니다.

사전 로딩은 브라우저가 유휴 상태 일 때만 당기지 만 당기는 것은 보장되지 않습니다. 이것은 매우 중요한 지점입니다. 브라우저 자체에는 내부 인터페이스 인 글로벌 리스너가 있기 때문입니다. 브라우징 공기가 유휴 상태 인 경우 유휴 상태에서 브라우저가 실행되지만이 유휴 콜백은 트리거되지 않을 수 있으므로 사전로드가 수행 될 것이라고 보장하지 않습니다.

Chrome은 HTTPS 리소스의 사전로드를 지원하지 않습니다. 예를 들어, Alipay는 HTTPS 페이지이며 Chrome은 사전 풀이되지 않습니다.

사전 파괴 된 페이지가 존재 한 후에는 보이지 않지만 실제로는 정상적으로 구문 분석됩니다. 로그인 페이지를 미리 정리하면 로그인 페이지에는 그림, CSS 파일 및 JS 파일과 같은 많은 리소스가 있습니다. 정상적으로 위에서 아래로 구문 분석됩니다. 구문 분석 과정 에서이 페이지는 나타나지 않지만 실제로 존재합니다. HTML5에서는 Document.VisibilityState를 통해 현재 페이지 상태를 얻을 수 있습니다. 일반적으로 페이지에는 눈에 보이지 않고 보이지 않는 두 개의 상태가 있지만 이제는 사전 렌더링 상태라는 새로운 상태가 있습니다. 문서 .VisibilityState가 Prerender와 같은지 여부에 따라 페이지가 프레젠더 상태에 있는지 직접 결정할 수 있습니다.

4.DNS 해상도

다음은 DNS의 해상도입니다. 때로는 페이지에 로그인하면 사용자가 클릭 할 수있는 위치를 감지하기가 상대적으로 어렵습니다. 물론, 때때로, 우리는 사용자의 다음 동작이 대부분 진행되고 있음을 알기 위해 몇 가지 매장 지점을 수행 할 것입니다. 그러나 경우에 따라, 우리는 사용자가 다음으로 갈 페이지를 알지 못하지만 그가 어떤 도메인으로 갈 것인지 알고 있습니다. 현재 DNS를 미리 배려 할 수 있습니다. 실제로 전체 페이지 요청 프로세스에는 긴 DNS 해상도 프로세스가 있기 때문입니다. 이 작업을 미리 수행하면 사용자 가이 페이지를 볼 수 있습니다.

다음은 Q+ 벽지의 경우입니다. Q+ 벽지는 특정 시스템입니다. 우선 Q+의 전체 아키텍처는 Web+ Client를 기반으로합니다. 우리가 지금보고있는 것은 웹 페이지입니다. 외부의 클라이언트 쉘이지만 심장은 웹입니다. 우리가 처음으로 전체 프로세스를 완료했을 때, 많은 그림이 있기 때문에 모든 정적 리소스는 12 개 이상의 정적 서버에 할당됩니다. 다시 말해, 당기고 싶다면 10dns를 구문 분석해야합니다. 이번에는 시간이 많이 걸리며 가장 느린 시간은 몇 초 만에 지연 될 수 있습니다. 이는 육안으로 느낄 수있는 것입니다. DNS 사전 해상도를 수행하는 경우, 어떤 리소스인지 알지 못하기 때문에 모든 사진은 무작위이므로 DNS 사전 해상도에서 열심히 노력하여 속도를 향상 시킨다고 말할 수 있습니다. 이런 식으로 2 초가 걸릴 수 있으며 1 초가됩니다.

다음으로 Q+의 응용 프로그램에 대해 이야기 해 봅시다. QQ와 마찬가지로 QQ와 Q+에 많은 텍스트 체인이 있습니다. 이는 창의 왼쪽 하단에 텍스트 앱 정보 푸시가 있음을 의미합니다. 이것은 백엔드가 웹을 통해 때때로 당겨지고 백엔드는 전경에서 가져 와서 표시됩니다. 그러나 특정 기간에 모든 앱이 푸시하는 총 운영 정보는 실제로 고정되어 있습니다. 특정 앱에 따라 각 텍스트 체인의 해당 배열을 분석하면 현재 매우 빅 데이터입니다. 여기에는 약 3 ~ 400 바이트가 있기 때문에 최적화의 관점 에서이 영역을 현지에서 끌어 당길 것입니다. 그런 다음 로컬 스토리지를 저장하십시오. 우리는 동일한 도메인에 있으며 앱 간의 모든 정보는 서로 액세스 할 수 있습니다. 그런 다음 다시 당기는 모든 ID를 당기지 않습니다.

여기에주의를 기울여야 할 사항도 있습니다. 현재 많은 지역 스토리지 제조업체가 동기화되어 있습니다. LocalStorage를 대량으로 호출하면 실제로 렌더링 프로세스를 차단합니다. 이 시점에서 사용자가 페이지를 드래그하면 현재 데이터를 저장하고 데이터가 비교적 큽니다. 현재 사용자는 귀하의 페이지가 매우 붙어 있다고 생각합니다. 그들은 전에이 문제에 대해 논의했습니다. 이 인터페이스의 설계는 비동기 적으로 설계되었으며 동기식으로 설계되었습니다. 이렇게하면 직렬화 프로세스, 디스크 시퀀스가 ​​있기 때문에 더 많은 앱을 만들 때이 변명을 할 수 있습니다. 이런 식으로 전체 프로세스가 느리게 나타납니다. 또한 LocalStorage는 다른 Windows 간에이 데이터를 공유 할 수 있으며이 데이터를 잠그게합니다. 많은 양의 데이터 가이 로컬 인터페이스를 호출하는 경우 상대적으로 고정 된 것으로 보입니다. 따라서 현재 특별한 솔루션은 없지만 이것은 기억해야 할 것입니다. 현재 가장 큰 것이 5시가 넘는 경우에도 5시 이상을 사용하면 사용자를 매우 슬프게 할 것입니다. 이 변명이라고 부르고 사용자가 마우스를 끌고 사용하는 경우 매우 고정 된 느낌이 들기 때문입니다.

다음으로 성능 측면에서 사용자에게 오프라인 스토리지의 이점에 대해 이야기 해 봅시다. 우선, 정의 파일에는 오프라인 스토리지가 입력됩니다. Q+의 모든 시스템 모듈에는 정의 오프라인 지원이 있습니다. 즉, 모든 응용 프로그램이 연결이 끊어지면 여전히 사용할 수 있습니다. 문서에 매니페스트 파일을 추가하십시오. Manifest는 로컬로 저장 해야하는 페이지를 선언하는 정의 파일입니까? 어떤 것이 저장 될 필요가 없습니까? 요청이 실패하면 어떤 것을 교체해야합니까? 이것은 세 부분으로 나뉩니다.

먼저, 로컬로 저장 해야하는 캐시.

둘째, 네트워크는 로컬로 저장되지 않습니다. 다시 돌아가서 매번 요청합니다. 그러나 로컬 스토리지와 브라우저 스토리지는 실제로 두 가지 다른 것임을 지적해야합니다. 그들은 두 가지 다른 부분을 저장합니다. 네트워크가 앱에 매번 한 번 가져와야한다고 앱에 알릴 필요가 있더라도 Chrome과 마찬가지로 스토리지 캐시가 매우 증오적이고 지우기가 어렵 기 때문입니다. 적용되도록 수동으로 지워야합니다. 따라서 로컬로 저장하지 않도록 설정하더라도 브라우저는 두 곳의 다른 장소를 저장하기 때문에 자체를 저장할 수 있습니다.

셋째, 폴백. 그림이 실패하면 404입니다. 대신 어떤 사진을 사용해야합니까? 나는 이것이 더 재미 있다고 생각한다.

Maeifest를 설정하는 방법? 매니페스트에 대해 주목해야 할 세 가지가 있습니다.

상 동성 제한을 나타냅니다.

MIME 유형은 텍스트/캐시 관리 여야하며, 이는 표준이며 다른 형식 인 경우에는 적용되지 않습니다.

Chrome,이 문제가 적용되는지 확인하려면 의사 프로토콜 크롬 인 Chrome : // AppCache-Internals를 통해 브라우저에 입력 할 수 있습니다.

앱의 캐시를 업데이트하는 방법에 대해 오프라인 스토리지가 필요한 이유는 무엇입니까? 오프라인으로 현지에서 보관하십시오. 브라우저가 오프라인 스토리지가 있다는 것을 알고 있으면 먼저 오프라인 스토리지 디렉토리로 이동 하여이 리소스가 캐시되었는지 확인합니다. 캐시가 발생하면 여기에서 직접 리소스를 얻고 다른 요청을 보내지 않을 것입니다. 브라우저의 요청은 이와 같기 때문에 오프라인 스토리지가있을 때 요청조차 보내지 않으므로 더 빠릅니다. 때로는 업데이트가 필요한 경우 업데이트 할 때 어떻게해야합니까?

사용자는 브라우저의 캐시를 수동으로 지울 수 있으며 현재 로컬 스토리지가 자동으로 지워집니다.

Manifest의 컨텐츠를 수정하는 것이 더 권장되는 방법이며 온라인으로 사용하는 방식이기도합니다. 즉, 우리는 내부의 특정 프로젝트를 수정할 수 있지만 여기에서 의견을 수정하는 것이 가장 좋습니다. 게시 할 때마다 메커니즘을 자동으로 게시하고 게시 할 때 댓글을 달고 수정하기 때문입니다. 이런 식으로 컨텐츠가 게시 될 때마다 클라이언트의 위치 영역과 실시간으로 동기화됩니다.

프로그램을 통해 실행하면 프로그램은 Window.applicationCache.UpDate ()입니다. 오프라인 스토리지를 작동하고 싶다는 것을 의미합니다. 실제로, 나는 시맨틱이 애플리케이션 스토리지이기 때문에 때때로 응용 프로그램 저장소라고 부릅니다. 우리는 애플리케이션 스토리지를 수동으로 업데이트합니다.

6. 와브 작업자

다음 웹 워커. 웹 워커는 다중 스레드 JS 프로세스입니다. 사실, 온라인에서 응용 프로그램 시나리오가 없다면 그것에 대해 이야기하지 않을 것입니다. 그러나 우리는 내가 본 특정 응용 프로그램 시나리오에 대해 이야기 할 수 있습니다.

먼저 웹 워크가 무엇인지 소개하겠습니다. OS 레벨 스레드입니다. 전에, 우리는 멀티 스레딩을 모방했지만 실제로 우리는 창을 하나 더 열었습니다. 그러나 이제 브라우저 자체는이를 제공하여 작업에 더 편리하게 제공되며 전체 문서를 더 무겁고 권장하지 않는 방법입니다.

그런 다음 웹 워커는 액세스 기능이 제한되어 있으며 많은 글로벌 객체에 액세스 할 수 없습니다. 예를 들어, documnet 객체에 액세스 할 수 없습니다. 웹 워크 사람에게 가장 적합한 시나리오는 CPU 집약적 인 컴퓨팅 작업입니다. 우리가 전에 게임을 할 때, 우리는 box2d를 사용했습니다. 많은 사람들이 그것을 들었습니다. 여기에는 많은 계산이 포함됩니다. 즉, 전체 페이지의 아래의 모든 객체는 충돌 관계를 계산해야합니다. 그러나 현재 JS 프로세스에서 실행되면 계산이 크고 계산이 계산되면 전체 페이지가 매우 말더듬됩니다. 그러나 웹 워커를 사용하여 수행하면 실시간으로 전송되고 계산 프로세스 중에 다른 일을 할 수있는 비동기 프로세스입니다.

장치 API에 대해 이야기합시다. 장치 API에서 가장 중요한 것은 성능이며 현재 구현 된 최초의 API입니다. 하나는 네트워크 대역폭 인 연결입니다. 이것의 기능은 무엇입니까? 중국 의이 시나리오에서는 많은 사용자의 인터넷 속도가 여전히 매우 낮다는 것을 기억해야합니다. 사용자의 인터넷 속도가 낮을 ​​때 비교적 낮은 솔루션으로 자동으로 다운 그레이드 할 수 있기를 바랍니다. 기존 기술을 사용하면 그렇게 할 수 없습니다. 그러나 장치 API를 사용할 수 있습니다. 이 정보는 장치에서 얻을 수 있다는 것을 알고 있기 때문입니다. 광대역이란 무엇입니까? 광대역은 무엇입니까? 우리가 할 수있는 일. 예를 들어, 광대역이 좋으면 고화질 사진을 사용합니다. 광대역이 비교적 낮은 경우 명확성이 낮은 사진을 사용하십시오.

8. 배터리

다음은 배터리에 관한 것입니다. 나는 성능의 관점에서 주로 힘에 관한 것이라고 생각합니다. 사용자의 배터리 전원이 상대적으로 낮 으면 더 적은 일을하려고 노력해야한다고 생각합니다. 휴대폰 자체의 배터리 기술은 아직 획기적인 발전을 일으키지 않았습니다. 앱을보다 고성능으로 보이게 만드는 것도 홍보의 하이라이트라고 생각합니다.

9. 칸바

다음은 캔버스입니다. 캔버스의 몇 가지 성능 최적화 지점에 대해 이야기 해 봅시다. 이러한 것들을 사용하면 성능이 10 번 향상됩니다.

첫째, 각 캔버스는 캔버스입니다. 그래프를 렌더링하려면 그래프를 계층화 할 수 있습니다. PS 내부와 마찬가지로 1, 2 및 3 개의 층입니다. 많은 사용자가 게임을 만들 때 한 계층의 모든 것을 직접 모방하며 업데이트되면 모든 것을 업데이트해야합니다. 그러나 당신이 그것을 겹치면, 배경을 배경 레이어와 역할의 캐릭터에 넣습니다. 이런 식으로 역할을 업데이트하고 싶을 때 역할 만 업데이트하면 배경 레이어를 변경할 필요가 없습니다. CPU가 적 으면 성능이 자연스럽게 향상됩니다.

둘째, context.DrawImage. 사진을 확장하지 마십시오. 우리는 처음에 실수를했습니다. 우리 예술가들이 만든 사진은 항상 우리와 일치하지 않으며, 우리는 그림을 확장하고 싶습니다. 장치 자체의 이미지 크기는 이와 같으므로 이미지를 비율로 스케일링해야합니다. 그림을 확대 한 후 저가형 장치에서 iPad 또는 iPhone이 매우 고정 될 것임을 알았습니다. 왜? 코드 분석 만 수행하십시오. 이 방법을 사용할 때는 비용이 많이 듭니다.

셋째, requestAnimationFrame. 이것은 렌더링을 위해 특별히 최적화 된 방법입니다. 고유 한 원칙은 다음과 같습니다. 브라우저가 프레임을 통과하면이 방법이 트리거됩니다. 트리거되면 캔버스가 브라우저를 가져옵니다. 다음 프레임을 수행 할 준비가되었습니다. 전통적인 방법을 사용하는 경우 더 많은 것을 고려하지 않습니다. 그것은 내가 얼마나 많은 시간을 통과했는지 알게 될 것이며 그것을 실행할 것입니다. 사용자가 이전에 차단되고 10 초 마다이 메소드를 실행하면 이전 작업이 완료되지 않은 상태에서 작업이 연기됩니다. 애니메이션이 더 매끄럽게 보이도록 최적화되어 있습니다. 모든 프레임은 무언가를 할 수 있음을 알려줍니다. (텍스트 : InfoQ)