목차

1. 서문
2. 책임감 있는 디자인
3. 지속성 있는 감지 방법
4. 성능 고려하기
5. 책임감 있게 전달하기

4. 성능 고려하기

무엇인가 만들거나 상호작용에 대한 프로토타입을 제작할 때마다 항상 자신에게 물어보기 바란다. 내 기준에서 생각하는지, 아니면 사용자 입장에서 생각하는지.
- 폴 포드, <열 개의 시간 단위>-

4.1 무엇인가 잘못하고 있을 때

현재 모바일 네트워크 환경에서 기준으로 삼는 페이지 로딩 시간은 대략 10초다. 성능이 낮은 네트워크를 사용하는 나라에서는 로딩에 걸리는 시간의 일부에 불과하다. 왜 느릴까? 상당수의 원인은 개발자에게 있다.

(한 사이트당 평균 용량이 데스크탑 대략 2MB, 모바일 1.8MB 정도이다.)

문제는 반응형 웹사이트들은 하나의 코드베이스만으로 모든 브라우저와 디바이스를 지원하기 때문에 파일 크기가 일반 사이트보다 크다.

4.1.1 겁먹지 말자

반응형 웹사이트를 빠르게 전달하려면 전달 방식에 매우 신경 써야 한다. 왜냐하면 asset을 구성하고 전달하는 방식에 따라 실제 사용자가 느끼는 페이지 로딩 속도가 엄청나게 달라지기 때문이다.
실제로 코드 자체보다 전달하는 방식이 훨씬 중요하다.

4.2 크리티컬 패스 따라가기

페이지 로딩하는 과정을 이해하면 로딩 시간을 단축하는데 많은 도움이 된다.

• 크리티컬 패스 : 페이지를 요청하는 시점부터 페이지를 사용할 수 있게 되는 시점까지 발생하는 이벤트들을 기록한 정보

개발자로서 해야할 일은 이 경로를 최대한 단축하는 것이다.

4.2.1 간략히 살펴본 요청 과정

• 웹 연결 : 클라이언트 <-> DNS(Domain Name Service) <-> 호스트
• 모바일 디바이스 : 클라이언트 <-> Tower(기지국) <-> DNS(Domain Name Service) <-> 호스트

4.3 요청하고, 요청하고, 또 요청하라

브라우저에서 HTML 파일을 요청하는 과정

1) 브라우저가 특정한 HTML 파일 요청
2) 서버는 응답으로 HTML파일을 여러 덩어리로 나눠서 보냄
3) 브라우저는 덩어리가 올 때마다 적절한 절차(?)에 따라 파싱
4) 브라우저는 추가로 요청해야 할 외부 링크를 찾고 '문서 객체 모델(DOM, Document Object Model)'으로 변환한다.
5) DOM을 구성한 뒤에는 자바스크립트를 통해 문서의 요소를 탐색하거나 조작할 수 있다.
6) CSS를 통해 요소의 스타일을 원하는 형태로 지정할 수 있다.

HTML 파싱 및 랜더링과 관련해 확실히 이해해야 될 부분은 그 과정에서 실행되는 연산의 순서다.

• CSS는 초기 페이지 레이아웃에 관련된 스타일을 모두 불러와서(로딩해서) 파싱한 뒤 HTML 문서가 화면에 랜더링되기 직전
• JS는 페이지를 모두 불러와 렌더링한 뒤에 적용하는 것이 좋다.

참고POST : https://velog.io/@namezin/React#browser-and-dom

4.3.1 렌더링과 블로킹

블로킹

HTML 문서에서 link script 요소가 있으면 이런 asset이 완전히 로딩되고 파싱될 때까지 페이지를 렌더링하지 않고 기다리는 행위(반면 이미지는 블로킹하지 않는다)

CSS 로딩 시간이 오래 걸리지 않는다면 CSS가 준비될 때까지 페이지 렌더링을 블로킹하는 것이 훨씬 바람직하다.
그렇지 않으면 스타일 적용 전이 보여지고 CSS 로딩되고 스타일 적용 후가 나타나는 '화면 깜박임(flash of unstyled content: FOUC'이 나타나게 된다.

4.4 사용하는 개발 도구 익히기

(책에서는 크롬의 개발자 도구를 기준으로 설명한다.)
페이지 로딩 성능과 관련된 작업을 할 때 특히 유용한 것은 네트워크와 퍼포먼스(구 버전에서는 타임라인) 기능이다.

• 네트워크 패널 : 페이지를 렌더링하기 위해 브라우저가 요청하는 모든 asset의 상세 정보를 가지고 있다.
• 퍼포먼스 패널 : 여러 가지 asset이 로딩되고 렌더링되는 순서를 자세히 알 수 있다.

페이지를 로딩하고 파싱하는 방식은 브라우저마다 조금씩 다르다. 따라서 한 가지 이상의 개발자 도구를 익히길 권한다.
크롬 개발자 도구 : https://developers.google.com/web/tools/chrome-devtools?hl=ko

4.4.1 가장 중요한 척도는 체감 성능

체감 페이지 로딩 시간 같은 질적인 척도도 함께 고려해야 한다.

일반적으로 '충분히 빠르게' 페이지를 로딩한다고 판단하는 사실상의 표준 시간은 1초다.

체감 성능 면에서 사이트를 분석하고 싶다면 웹페이지테스트를 강력히 추천한다.
(https://webpagetest.org/)
지표 중에서도 체감 성능과 관련해 가장 주의 깊에 살펴볼 항목은 스피드 인덱스(속도 지수)다.
(이 수치는 낮을수록 좋다.)

4.5 성능 예산에 대해

아직 정의가 확시하진 않지만, 기본 개념은 명확하다.
코드베이스에 특정한 코드를 추가할 여력이 있는지 또는 기존 웹사이트의 성능을 좀더 향상시킬 필요가 있는지를 가늠하는 기준으로 삼는 수치이다.

성능은 UX의 핵심 요소이다.

4.6 요청 과정의 블로킹은 최소한으로

문서에서 보낸 요청에 대한 응답을 기다리는 부분을 최소화

4.7 웹으로 전달할 파일 준비하기

브라우저로 전달할 프론트엔드 파일을 준비할 때 네트워크로 전송할 총 파일 수를 최소화할 뿐만 아니라 각각의 파일 크기도 최대한 작게 만들어야 한다.

4.7.1 이미지 파일 최적화하기

이미지 압축
(이미지옵팀, https://imageoptim.com/api)

4.7.2 텍스트 파일 연결하기

CSS와 자바스크립트에서는 '연결(Concatenation' 기법으로 파일을 자동으로 합치는 방법을 주로 사용한다.

결국 블로킹 요청이 적을수록 더 좋다.

4.7.3 텍스트 파일 축약하기

파일의 수를 줄였으면 파일을 최대한 작게 만든다.

• 축약(minification) : 브라우저가 파싱할 때 필요 없는 부분을 자동으로 제거하는 기법(자바스크립트에서는 변수 이름의 글자 수를 줄이도록 변경하는 기법도 있음)

4.7.4 텍스트 파일 압축하기

파일을 축약했다면 전송하기 전에 압축해야 한다.
흔히 Gzip은 서버와 브라우저 간의 전송을 위해 텍스트 파일을 더 작게 만든다.(디플레이트(Deflat) 알고리즘 사용)

4.7.5 모든 것은 캐시에 달렸다

웹사이트 속도를 향상시키는 데 많은 도움이 된다.

• 일반적인 캐싱 과정 최적화하기
  기본 캐시 : 요청한 파일을 자동으로 저장 후 다음에 동일한 파일이 필요할 대 네트워크를 통해 요청하지 않고 로컬에 저장된 복사본을 참조
• HTML5의 오프라인 캐시 활용하기
  일시적으로 네트워크에 연결할 수 없을 때 유요한데 인프라가 잘 갖춰진 곳에서도 종종 발생한다.(지하철 타고 가거나 등등)
  사용되는 기능 중 대표적인 예가 HTML5의 애플리케이션 캐시다.
  이 기능은 가급적 최대한 활용하는 것이 좋다

4.7.6 모든 것을 자동화한다

이러한 기법을 직접 구현할 수도 있지만 이런 작업을 자동화하는 도구들이 크게 향상되었다.
(코드키트, 그런트가 설명되어 있지만 이것또한 구 기술이 되어버림...)