입문

HTMLコーダー&ウェブ担当者のためのWebページ高速化超入門本를 읽어서 요약했습니다.상세한 상황은 저쪽을 참조하여 이해하기 쉽습니다.

목표

데이터 전송을 최적화하여 웹 페이지의 초기 표시를 가속화하다

참고 자료

HTML 인코더 & 웹 담당자의 웹 고속화 초입문
[전자책] 크롬 개발상 도구를 능숙하게 사용하는 웹편
https://www.seohacks.net/basic/terms/mfi/
https://ferret-plus.com/8056

사이트 측정 도구

모바일 페이지 읽기 속도 분석 사이트

https://www.thinkwithgoogle.com/intl/ja-jp/feature/testmysite

페이지만 이동

홈페이지 속도 확정

https://developers.google.com/speed/pagespeed/insights/?hl=ja

PC 및 모바일 진단 모두 OK

상술한 두 개의 진단 내용은 약간 다른 것 같다
차이점↓
https://ferret-plus.com/8056

최근 네트워크 사용 환경

스마트폰 사용자85%

구글의 2017년 조사에서 모바일 사이트 페이지 읽기3秒以上かかる場合、53％のユーザが離脱

MFI는'Mobile First Index(이동 첫 번째 색인)'의 약칭으로 색인 대상을 PC 페이지에서 이동 페이지로 변경합니다.별도採点要素にWEbサイトが表示されるスピード 추가

대충 병목 이 있는 곳

통신 환경

서버 쪽(웹 서버 등)

어플리케이션(컨텐츠)

이미지 재생

무거운 비디오

동적 생성 등

클라이언트(PC)

무엇이 프론트 데스크의 고속화입니까

전단은 사이트를 가장 가속화하기 쉬운 구역이다

간단한 Chrome DevTools 사용

네트워크 탭에서 확인disable cache

페이지 정보를 캐시하지 않음

맨 아래 상태 표시줄

상태 표시줄의 각 항목

Finish:

페이지를 표시하는 데 걸리는 시간

DOMContentLoaded:

HTML 읽기 및 해석 완료 시간(CSS, 이미지 없음)

Load:

페이지를 완전히 읽는 시간

requests:

서버에서 다운로드한 파일 수

transferred:

서버에서 다운로드한 파일의 총 용량입니다.数十MB～数百MB이면 시간이 걸린다.

waterfall

ChromDevTool URL이 포함된 행 Waterfall 열

Queued at:

네트워크 패널의 측정 시작 시간

Started at:

대기열 종료 시간

Queuing:

워터폴의 흰색 라인.Queued at + Queueing = Started at

ResourceScheduling:

리소스 가져오기 대기열 표시

Connection Start:

서버와의 접속 상태 표시

종료: 요청 발송 대기 시간

초기 연결: TCP 악수 및 SSL을 포함하는 초기 연결 구축 시간

SSL:

SSL의 수동 진동에 소요되는 시간

Request/Response

실제 양육 시

Request sent:

요청을 보내는 데 걸리는 시간

Waiting(TTFB):

첫 바이트를 받는 데 걸리는 시간.推奨時間:200ミリ秒 .이 값을 초과하면 サーバーが遅いか回線 이 느린지 여부에 착안합니다.

ContentDownlad:

응답 데이터 수신에 소요되는 시간

프로젝트 세부 정보

웹 이미지 최적화

가장 간단한 삭제 효과 기대

이미지 특징에 맞는 형식을 선택하여 적당한 크기로 줄이고 압축

이미지 용량 감소 목적

적절한 이미지 선택

jpeg

사진 등 소재 색상이 많은 이미지에 적합

PNG

일러스트와 로고 등 색상이 적은 이미지에 적합

GIF

시각차 애니메이션

SVG

새로운 형식.플래그 및 단순 그래픽

이미지 축소 및 압축

이미지 편집 소프트웨어를 통해 가로 세로 폭 축소

최초 적정 크기 확인은 Chrome Devtool에서 확인もとの大きさ과実際に表示されている大きさ.이것에 차이가 있다면 축소하는 것이 좋다

Photoshop이나 윈도우즈를 그려서 줄일 수 있음

느끼기 어려운 색상 정보 생략

Antelope

ImageOptim 등

이미지의 Lazyload

사이트에서 표시할 때 표시되지 않는 이미지를 읽지 않고 스크롤 범위 내에서 다운로드하여 표시

세로가 긴 페이지에서 이미지를 대량으로 사용하는 사이트에 유효

JavaScript 플러그인에 해당하는 경우가 많습니다

텍스트 파일 압축

압축 등

JavaScript와 CSS는 웹 응용 프로그램에서 자동으로 이루어지기 때문에 사랑을 끊는다

서버 측

그러나 서버 측 HTTP2와 같은 통신 방식의 진화로 여러 파일을 한데 모으는 기교가 과거에

HTTP1

위의 ChromeDevTool 이미지의 Requests와 같이 첫 페이지에만 여러 개의 TCP 연결이 실행 → 서버의 부하, 소모 시간

을 표시합니다.

HTTP2

하나의 TCP 연결로 여러 요청/응답 교환 가능

3번 악수는 단 한 번 → 서버의 부하, 시간의 경감

https를 통해서만 통신가능

상세한 HTTP2의 장점↓
https://qiita.com/uutarou10/items/7698ee3336c70a482843

체감 표시 속도 향상(첫 번째 뷰 ＆ Above the fold)

처음 본 구역을 아래 구역보다 먼저 표시하는 기술

PC의 첫 번째 뷰 대상

1920×1080

스마트폰의 첫 번째 보기 기준

375×667

첫 번째 뷰와 관련된 JavaScript 최적화

브라우저가 페이지를 렌더링하기 시작한 것은 모든 JavaScript 파일을 다운로드하여 확인한 후입니다.따라서 JavaScript의 분석이 끝날 때까지 기다리지 않고 HTML을 렌더링할 수 있도록 defer属性やasyncを利用する빠른 보기와 관련된 JavaScript 다운로드를 기다리지 않아도 빠른 보기가 표시됩니다.
async는 기본 defer를 사용하여 자바스크립트를 순서대로 읽기 때문에 다른 자바스크립트 파일에 의존하지 않습니다ファーストビュー付近に関連するJavaScriptであればasyncを使う

CSS 최적화

CSS 파일 다운로드 후 확인, 브라우저 렌더링 시작

CSS 비동기식

렌더링을 막지 않고 CSS를 읽을 수 있음

모든 CSS의 읽기를 동기화하지 않으면 페이지가 표시될 때 CSS가 흐트러지게 적용됩니다.

따라서 우선 첫 번째 보기의 CSS만 헤드 탭에 직접 기록합니다.이렇게 하면 첫 번째 보기를 잘 표시할 수 있다.ファストビューより下の領域のCSSを非同期に読み込む

추출 방법https://jonassebastianohlsson.com/criticalpathcssgenerator/

자동 추출

다른 CSS의 경우 preload 및 as=style 비동기식 사용

측정 방법

Chrome DevToolsAudits를 사용하면 알 수 있습니다体感的な表示速度.

캐시를 효과적으로 활용하여 불필요한 컨텐츠 제거

서버 측(.htaccess 등)에서 이미지나 css 등 브라우저 캐시를 설정할 수 있음

사이트를 재검토하고 첫 번째 보기에서 무거운 처리가 있는지, 이미지를 마음대로 사용하는지 등 필요하지 않은 것을 제거하는지 조사

총결산

Chrome DevTools의 Waiting(TTFB) 프로젝트(첫 번째 바이트를 받는 데 걸리는 시간)200ミリ秒を超えるよう는 서버 검사, 200ミリ秒以内는 프런트 검사로 볼 수 있습니다.