HTML5 성능 분석_html5 튜토리얼 기술에 대해 개발자가 알아야 할 사항

성능 관점에서 HTML5는 먼저 HTML 문서를 줄여서 더 쉽게 만듭니다.
첫째, 사용자 가독성 측면에서 보면 원래 초보자가 처음 봤을 때 이해하기 어려운 부분이 많았는데, 확실히 HTML5 선언 방식이 더 사용자 친화적입니다.
둘째, HTML5를 사용하여 문서 인코딩 선언이 매우 간단합니다. 많은 사람들이 HTML5가 무엇인지 묻습니다. 현재 많은 페이지에서 여전히 전통적인 방법을 사용하고 있기 때문에 HTML5를 먼저 사용하는 방법은 DOCTYPE을 먼저 변경하는 것이라고 합니다. HTML5 방법 자체는 고급 브라우저를 포함하여 IE6부터 IE10까지 IE 브라우저와 호환됩니다. 따라서 HTML5를 수용하는 가장 쉬운 방법은 DOCTYPE을 변경하는 것입니다.

1. 태그를 더욱 간결하게
다음은 별로 흔하지 않을 수도 있지만 추천드리는 내용이고 사용이 더 간편해진 내용입니다. . 라벨링 방법. 이름에서 알 수 있듯이 HTML5는 HTML4에서 상속되었습니다. HTML4에는 엄격 모드와 전환 모드가 있습니다. HTML5는 이 전환 모드를 지원합니다. 즉, 일부 태그를 닫을 수 없습니다. 하지만 모든 태그를 권장하지는 않습니다. 예를 들어 BODY 태그가 닫히지 않은 경우에는 이를 권장하지 않습니다. 그러나 가장 일반적으로 사용되는 P 태그는 목록 태그 LI입니다. 왜 이렇게 말하는 걸까요? 우선 시각적인 관점에서 보면 이 방법이 더 간단합니다. 그러면 핵심은 문서 전송 과정에서 내용이 적어진다는 것입니다.
HTML5 태그 속성 선언은 단일 대괄호, 이중 대괄호, 대괄호 없음의 세 가지 방법을 지원합니다. 문서 크기를 줄이기 위해 큰따옴표가 없는 방법이나 작은따옴표가 있는 방법을 선택합니다. 그러나 속성은 여러 클래스를 포함할 수 있고 여러 클래스가 있는 경우 괄호로 묶어야 하기 때문에 가정은 클래스 속성의 선언이라는 점에 유의하세요. 이와 관련하여 Google의 사례를 보여 드리겠습니다. 구글 자체적으로 위 내용을 완벽하게 구현한 페이지가 있는데, 문서 크기를 20% 줄이고 HTML 문서의 전송량을 20% 줄인다. 이 모든 것을 실천에 옮기면 5%~20% 정도의 절감 효과를 얻을 수 있습니다. 이것이 HTML 문서의 크기를 줄이는 첫 번째 단계입니다.
　2. 이미지 최적화
다음은 이미지 최적화입니다. 사진이 많으면 전체 페이지의 로딩 속도가 심각하게 느려지기 때문입니다. 이미지 최적화 방법에 대해서는 "고성능 웹 사이트"라는 책에 많은 소개가 있습니다. 요약하면 스프라이트 사용, 이미지 크기 최적화, DATA URI 사용의 세 가지 주요 사항이 있습니다. 여기서는 자세히 설명하지 않겠습니다. .
이미지 최적화에 대한 또 다른 아이디어는 이미지 없음입니다. 이미지를 버리고 CSS3를 수용하세요. 원래는 둥근 모서리 효과가 있는 그림을 설정해야 했고, 이제 CSS3에서는 테두리 반경을 사용합니다. 원래는 그림자 효과가 있는 그림을 설정해야 했지만 이제는 CSS3에서는 상자 그림자를 사용합니다. 그라디언트를 설정하는 데 필요한 배경 그림이며 이제 CSS3 그라디언트에서 사용됩니다.
　3. 프리페칭(Prefetching)
다음으로 최적화의 또 다른 아이디어인 프리페칭(Prefetching)에 대해 이야기하겠습니다. 현재 우리의 최적화 아이디어는 몇 가지에 지나지 않습니다. 그 중 다수는 문서 크기 축소, 사진 크기 축소 등 축소 관점에서 나온 것입니다. 전송되는 요청 수를 줄이기 위해 많은 사진이 스프라이트 이미지로 변환됩니다. 프리페치는 또 다른 사고 방식으로, 사용자가 리소스를 클릭하면 리소스가 미리 로드되므로 확실히 더 빠릅니다.
프리페치는 두 부분으로 구성됩니다. 하나는 리소스 프리페칭이고 다른 하나는 DNS 사전 확인입니다.
리소스 사전 로드에 관해 주의할 점이 몇 가지 있습니다.
사전 로드는 브라우저가 유휴 상태일 때만 수행되지만 완료된다는 보장은 없습니다. 브라우저 자체에는 내부 인터페이스인 전역 리스너가 있기 때문에 브라우저가 유휴 상태일 때 브라우저가 수행해야 하는 작업을 수행하지만 이 유휴 콜백이 트리거되지 않을 수 있으므로 이를 보장할 수 없습니다. 사전 로드가 수행됩니다.
Chrome은 HTTPS 리소스 사전 로드를 지원하지 않습니다. 예를 들어 Alipay가 HTTPS 페이지인 경우 Chrome은 이를 사전 로드하지 않습니다.
프리패치된 페이지는 존재 후에는 표시되지 않지만 실제로는 정상적으로 파싱되고 있습니다. 로그인 페이지를 프리페치한다고 가정해 보겠습니다. 로그인 페이지에는 사진, CSS 파일, JS 파일과 같은 많은 리소스가 있습니다. 위에서 아래로 정상적으로 파싱이 진행됩니다. 파싱 과정에서 이 페이지는 나타나지 않지만 실제로는 존재합니다. HTML5에서는 document.visibilityState를 통해 현재 페이지 상태를 얻을 수 있습니다. 일반적으로 페이지에는 표시되는 상태와 표시되지 않는 상태의 두 가지 상태가 있지만 이제는 사전 렌더링된 상태라는 새로운 상태가 있습니다. document.visibilityState가 prerender와 같은지 여부를 통해 페이지가 사전 렌더링된 상태인지 직접 확인할 수 있습니다.
　4.DNS 분석
다음은 DNS 분석이다. 때로는 로그인 페이지에서 사용자가 클릭할 수 있는 위치를 감지하는 것이 상대적으로 어렵습니다. 물론 때로는 사용자의 다음 작업 대부분이 내부로 들어가는 것임을 알아내기 위해 약간의 조사를 수행할 수도 있습니다. 하지만 어떤 경우에는 사용자가 다음에 어떤 페이지로 이동할지는 모르지만, 어떤 도메인으로 이동할지는 알 수 있습니다. 이때 DNS를 미리 확인할 수 있습니다. 실제로 전체 페이지 요청 프로세스에는 긴 DNS 확인 프로세스가 있기 때문에 미리 이렇게 하면 사용자가 이 페이지를 볼 수 있도록 허용할 수 있습니다.
다음은 Q 배경화면 예시입니다. Q 배경화면은 Q의 특정 시스템입니다. 우선, Q의 전체 아키텍처는 WEB 클라이언트를 기반으로 합니다. 지금 우리가 보는 것은 WEB 페이지입니다. 겉으로는 클라이언트 셸이지만 그 핵심은 WEB입니다. 처음 전체 과정을 완료했을 때 사진이 너무 많아서 모든 정적 리소스가 12개가 넘는 정적 서버에 할당되었습니다. 즉, 풀링하려면 DNS 10개를 해결해야 하는데, 이 시간은 가장 느린 시간에는 육안으로 느낄 수 있는 몇 초 정도 지연될 수 있습니다. DNS 사전 해결을 수행하면 어떤 리소스인지 알 수 없고 모든 사진이 무작위이므로 속도를 향상시키기 위해 DNS 사전 해결에 열심히 노력해야 한다고 말할 수 있습니다. 이 경우에는 2초가 걸릴 수도 있지만 1초가 소요됩니다.
다음으로 Q의 애플리케이션에 대해 이야기해 보겠습니다. QQ와 Q에는 많은 텍스트 링크가 있습니다. 즉, 창 왼쪽 하단에 앱 정보의 텍스트 푸시가 있습니다. 여기서 백엔드는 WEB을 통해 수시로 풀링되며, 백엔드는 풀오버되어 전경에 표시됩니다. 하지만 일정 기간이 지나면 모든 앱에서 푸시하는 작동 정보가 고정됩니다. 특정 APP에 따른 각 텍스트 링크에 ​​해당하는 배열을 분석해 보면 매우 많은 양의 데이터입니다. 여기의 각 파일은 약 300~400바이트이기 때문에 최적화 관점에서 볼 때 우리는 이러한 파일을 매번 로컬에 저장합니다. 그런 다음 localStorage에 로컬로 저장합니다. 동일한 도메인에 있으며 APP 간의 모든 정보에 서로 액세스할 수 있습니다. 그러면 추출된 모든 ID는 다시 추출되지 않습니다.
여기서도 주의가 필요한 점이 있습니다. 현재 많은 제조업체에서 localStorage를 구현하는 방식은 동기식입니다. localStorage 인터페이스를 많이 호출하면 실제로 렌더링 프로세스가 차단됩니다. 이때 사용자가 페이지를 아래로 드래그하면 이때 데이터가 저장되고 있는데 데이터가 상대적으로 크면 사용자는 페이지가 매우 멈춘다는 느낌을 받게 됩니다. 그들은 이전에 이 문제를 논의한 적이 있습니다. IE의 인터페이스 디자인은 비동기식이지만 디자인은 동기식입니다. 이는 디스크에 직렬화하는 직렬화 프로세스가 있기 때문에 이 인터페이스를 조정할 때 많은 프로그램이 있다고 가정하게 됩니다. 이 경우 전체 프로세스가 더 느리게 나타납니다. 또한 localStorage 자체는 이 데이터를 여러 창 간에 공유할 수 있으며 이 데이터를 잠급니다. 많은 양의 데이터가 이 로컬 인터페이스를 호출하는 경우 중단된 것처럼 보입니다. 따라서 당장은 특별히 좋은 해결책은 없지만 명심해야 할 사항이 있습니다. 현재 최대 용량이 5MB를 초과하더라도 5MB를 초과하여 사용하면 사용자가 불편해집니다. 왜냐면 이런 핑계를 대고 사용자가 마우스를 드래그하면 굉장히 막히는 느낌이 들기 때문입니다.
　5. 오프라인 스토리지
다음으로 오프라인 스토리지가 성능 측면에서 사용자에게 제공하는 이점에 대해 이야기하겠습니다. 첫 번째는 오프라인 저장을 위한 정의 파일입니다. Q의 모든 시스템 모듈에는 오프라인 지원이 정의되어 있습니다. 이는 네트워크 연결이 끊어져도 모든 애플리케이션을 계속 사용할 수 있음을 의미합니다. MANIFEST 파일을 문서에 추가하세요. MANIFEST는 현재 페이지의 어떤 부분을 로컬에 저장해야 하는지 선언하는 정의 파일인가요? 요청이 실패하면 어떤 부분을 새 그림으로 바꿔야 하나요? ? 이렇게 세 부분으로 나누어집니다.
먼저 로컬에 저장해야 하는 CACHE입니다.
둘째, NETWORK는 로컬에 저장되지 않습니다. 매번 다시 요청하게 됩니다. 하지만 여기서 짚고 넘어가야 할 점은 로컬 저장소와 브라우저 저장소가 실제로는 서로 다른 장소라는 것입니다. . NETWORK가 매번 가져와야 한다고 APP에 알려야 하는 경우에도 Chrome과 마찬가지로 저장소 캐시가 매우 혐오스럽고 삭제하기 어렵기 때문에 완전히 효과적이려면 수동으로 지워야 합니다. 따라서 로컬에 저장하지 않도록 설정하더라도 브라우저는 서로 다른 두 위치에 저장하기 때문에 브라우저가 자체적으로 저장할 수 있습니다.
세 번째, FALLBACK. 사진에 요청이 실패했다고 표시되면 404입니다. 대신 어떤 사진을 사용해야 할까요? 이게 더 재미있을 것 같아요.
MAEIFEST를 설정하는 방법은 다음과 같습니다.
MANIFEST 동일 출처 제한
MIME 유형은 text/cache-manifest여야 합니다. 형식으로는 작동하지 않습니다.
CHROME, 이것이 효과적인지 확인하려면 의사 프로토콜 CHROME, chrome://appcache-internals를 통해 브라우저에 입력하면 됩니다.
애플리케이션 캐시 업데이트 방법에 대해. 오프라인 저장소가 로컬인 이유 브라우저는 오프라인 저장소가 있음을 알게 되면 먼저 오프라인 저장소 디렉터리로 이동하여 리소스가 캐시되었는지 확인합니다. 캐시된 경우 여기에서 직접 리소스를 가져오고 다른 요청을 보내지 않습니다. 브라우저의 요청이 이렇기 때문에 오프라인 저장소가 있는 경우에는 요청조차 전송되지 않으므로 속도가 더 빨라집니다. 가끔 업데이트가 필요한 경우 업데이트할 때 어떻게 해야 하나요?
사용자는 브라우저의 캐시를 수동으로 지울 수 있으며 이때 로컬 저장소는 자동으로 지워집니다.
MANIFEST의 내용을 수정하세요. 이는 권장되는 방법이며, 우리가 온라인에서 사용하는 방법이기도 합니다. 즉, 내부의 특정 항목을 수정할 수 있지만 게시할 때마다 자동 게시 메커니즘이 있으므로 여기에서 주석을 수정하는 것이 가장 좋습니다. 이 경우 콘텐츠가 게시될 때마다 실시간으로 로컬 클라이언트에 동기화됩니다.
프로그램을 통해 실행되며 프로그램은 window.applicationCache.update()입니다. 즉, 오프라인 스토리지를 운영하고자 하는 것입니다. 사실 그 의미가 애플리케이션 스토리지이기 때문에 애플리케이션 스토리지라고도 부릅니다. 애플리케이션 스토어를 수동으로 업데이트해 보겠습니다.
　6.Web Worker
　 다음은 Web Worker 입니다. Web Worker는 다중 스레드 JS 프로세스입니다. 사실 온라인에는 적용 시나리오가 없으므로 이에 대해서는 다루지 않겠습니다. 하지만 제가 본 구체적인 적용 시나리오에 대해서는 이야기할 수 있습니다.
먼저 WEBWORK가 무엇인지 소개하겠습니다. OS 레벨 스레드입니다. 멀티스레딩을 흉내내기 전에 실제로 창을 하나 더 열었습니다. 그러나 이제는 브라우저 자체에서 이를 제공하므로 작업이 더욱 편리해지고 전체 문서가 무거워지므로 그다지 권장되는 방법은 아닙니다.
그러면 WebWorker의 액세스 기능이 제한되어 많은 전역 개체에 액세스할 수 없습니다. 예를 들어, documnet 개체에 액세스할 수 없습니다. WebWorker에 가장 적합한 시나리오는 CPU 집약적인 컴퓨팅 작업입니다. 이전에 게임을 만들 때는 BOX2D를 사용했습니다. 많은 사람들이 많은 계산이 필요하다는 말을 들었을 것입니다. 즉, 전체 페이지에서 아래의 모든 개체가 충돌 관계를 계산해야 한다는 것입니다. 이 계산량이 매우 큽니다. 하지만 현재 JS 프로세스에서 실행하면 계산량이 엄청나므로 일단 계산하면 전체 페이지가 매우 정체됩니다. 하지만 이를 위해 WebWorker를 사용하면 비동기 프로세스이며 실시간으로 전송되며 계산 프로세스 중에 다른 작업을 수행할 수 있습니다. 이것이 바로 멀티스레딩입니다.
　7. Device API
Device API에 대해 이야기해보겠습니다. 성능적인 측면에서 디바이스 API가 가장 중요하다고 생각하며, 현재 구현된 가장 초기의 API이기도 합니다. 하나는 네트워크 대역폭인 CONNECTION입니다. 중국의 이 시나리오에서는 많은 사용자의 인터넷 속도가 여전히 매우 낮다는 점을 기억해야 합니다. 우리는 네트워크 속도가 낮을 ​​때 사용자가 자동으로 더 낮은 요금제로 다운그레이드할 수 있기를 바랍니다. 기존 기술로는 할 수 없습니다. 하지만 우리는 장치 API를 사용할 수 있습니다. 왜냐하면 우리는 이 정보가 장치에서 얻어질 수 있다는 것을 알고 있기 때문입니다. 대역폭은 무엇이며, 그 대역폭으로 무엇을 할 수 있습니까? 예를 들어 광대역이 좋을 때는 고화질 사진을 사용합니다. 대역폭이 상대적으로 낮으면 해상도가 낮은 사진이 사용됩니다.
　8. 배터리
　다음은 배터리에 관한 것입니다. 성능 측면에서 볼 때 주로 힘에 관한 것이라고 생각합니다. 사용자의 배터리 전력이 상대적으로 낮다면 가능한 한 적은 작업을 수행해야 한다고 생각합니다. 휴대폰 배터리 기술에는 획기적인 발전이 없었습니다. 앱을 더욱 고성능으로 보이게 만드는 것도 프로모션의 하이라이트라고 생각합니다.
　9.CANVAS
　다음은 CANVAS입니다. CANVAS의 몇 가지 성능 최적화 포인트에 대해 이야기해 보겠습니다. 이를 사용하면 성능이 10배 향상됩니다.
먼저 각 CANVAS는 그래픽을 렌더링하려는 경우 레이어를 지정할 수 있는 캔버스입니다. PS와 마찬가지로 1레이어, 2레이어, 3레이어가 있습니다. 많은 사용자가 게임을 만들 때 모든 것을 하나의 레이어에 직접 넣고 업데이트되면 모든 것이 업데이트됩니다. 그런데 레이어를 하면 배경 레이어에 배경을 넣고, 캐릭터 레이어에 캐릭터를 넣게 됩니다. 이 경우 캐릭터를 업데이트하고 싶을 때 캐릭터만 업데이트되며 배경레이어는 변경할 필요가 없습니다. CPU의 작업을 줄이면 성능이 자연스럽게 향상됩니다.
둘째, context.drawImage입니다. 이미지의 크기를 조정하지 마십시오. 처음에 실수를 저질렀습니다. 우리 아티스트가 만든 이미지는 항상 우리의 이미지와 일치하지 않습니다. 기기 자체의 이미지 크기가 이렇기 때문에 비례적으로 이미지의 크기를 조정해야 합니다. 사진을 확대해본 결과, 아이패드나 아이폰 등 저사양 기기에서는 많이 멈춤 현상이 발생하는 것으로 나타났는데, 이 방법을 사용하면 시간이 많이 소요되기 때문에 코드 분석을 진행했습니다.
세 번째, requestAnimationFrame입니다. 이는 렌더링에 특별히 최적화된 방법입니다. 그 원칙은 브라우저가 프레임을 전달할 때마다 이 메서드가 트리거된다는 것입니다. 이 메서드를 트리거하면 Canvas는 브라우저가 다음 프레임을 수행할 준비가 되었음을 얻습니다. 전통적인 방법을 사용하면 시간이 얼마나 지났는지만 알 수 있고 실행해 줄 것입니다. 이전에 사용자가 차단되었고 이 메서드가 10초마다 실행되면 10초 이내에 해당 사용자의 이전 작업이 실제로 완료되지 않은 것이므로 이 작업이 지연됩니다. 각 프레임에서 뭔가를 할 수 있다는 것을 알려주기 때문에 애니메이션을 더 부드럽게 보이도록 최적화되었습니다. (텍스트: infoq)