[html] 개념학습 <optimization>

codeStates front-end/Html 2023. 3. 29. 20:26

📌 optimization

📍 최적화(optimization)

사전적의미 : 주어진 상황에서 원하는 가장 알맞은 결과를 얻을 수 있도록 처리하는 과정

주어진 조건으로 최대 효율을 낼 수 있도록 하는것을 의미한다.

🔗 최적화의 필요성 및 효과

이탈률 감소 : 웹 개발 최적화 👉🏻👉🏻 빠른 속도로 렌더링 하는 것 🙏🏻 렌더링이 빠르지 않으면 페이지 이탈할 확률 ⬆️🙏🏻
전환율 증가 : 💁🏼‍♂️ 전환율이란? 방문자의 비율 👉🏻👉🏻 이탈율 ⬇️ 👉🏻 전환율 ⬆️
수익 증대 : 회원 수가 증가하면 수익이 증대함을 의미
사용자 경험(UX) 향상 : 페이지 로딩이 빠를수록 UX는 향상된다.

🔗 HTML,CSS 코드 최적화하기

html,css의 DOM트리가 크고 복잡할 수록 리렌더링 소모 시간 증대 👉🏻👉🏻 최적화로 렌더링 성능 향상

HTML 최적화 방법

1. DOM트리 가볍게 만들기

트리가 깊을수록, 복잡도는 커진다. HTML의 요소와 관계를 살펴보고 불필요한 요소들을 삭제한다.

// 수정 전
<div>
	<ol>
		<li> 첫 번째 </li>
		<li> 두 번째 </li>
		<li> 세 번째 </li>
	</ol>
</div>

// 수정 후 : 불필요한 div 요소 제거
<ol>
	<li> 첫 번째 </li>
	<li> 두 번째 </li>
	<li> 세 번째 </li>
</ol>

1. 인라인 스타일 사용하지 않기

인라인 스타일은 웹 표준에 맞지 않으므로 지양해야 한다.

//수정 전
<div style="margin: 10px;"> 마진 10px </div>
<div style="margin: 10px;"> 이것도 마진 10px </div>

//수정 후 : class와 CSS로 대체
<div class="margin10"> 마진 10px </div>
<div class="margin10"> 이것도 마진 10px </div>

.margin10 {
	margin: 10px;
}

CSS 최적화 방법

1. 사용하지 않은 CSS 제거하기

2. 간결한 셀렉터 사용

🔗 리소스 로딩 최적화하기

HTML 파일에서 JS 파일을 불러올 때 <script>요소를, CSS 파일을 볼러올 땐 <link>요소를 사용한다.

이때 파일을 불러오는 위치가 어디인가에 따라서 렌더링 완료 시점이 달라질 수 있다.

1. CSS 파일 불러오기

CSSDOM트리를 빠르게 구성할 수록 HTML문서 최상단에 배치하는 것이 좋다.

// CSS 파일은 HTML 파일 상단의 head 요소 안에서 불러오는 것이 좋습니다.
<head>
	<link href="style.css" rel="stylesheet" />
</head>

2. JS파일 불러오기

JS 파일 다우로드 속도가 제일 느리기 때문에 빠른 CSS와 HTML이 처리될 수 있도록 최하단에 배치한다.

<body>
	<div>...</div>
	...

	// JavsScript 파일은 body 요소가 닫히기 직전에 작성하는 것이 가장 좋습니다. 
	<script src="script.js" type="text/javascript"></script>
</body>

🔗 브라우저 이미지 최적화하기

페이지의 대부분의 용량은 미디어 파일이 차지한다. 용량을 줄이거나 수를 줄이는 것을 우선시 고려

1. 이미지 스프라이트

많은 이미지 파일을 개별로 관리하지 않고 특정 스프라이트 이미지 파일만을 관리하여 로딩 시간을 줄인다.

2. 아이콘 폰트 사용하기

CDN으로 사용
Font Awesome 모듈 설치
webp 또는 AVIF 이미지 포맷 사용하기

📍 캐시 관리

캐시(Cache)는 다운로드 받은 데이터나 값을 미리 복사해 놓는 임시 장소를 뜻한다.

💁🏼‍♂️ 완전히 똑같은 파일을 또 다시 받아오는 일이 발생한다면? 리소스 낭비를 위해 캐시를 사용한다.

첫번째 요청 시, 서버에서 응답을 보내줄 때 이미지 파일과 함께 헤더에 Cache-Control을 작성해서 보내줌
값은 60으로, 해당 이미지 파일이 60초 동안 유효하다는 것을 의미
두번째 요청 시, 캐시를 우선 조회 60초가 지나지 않는다면 캐시에서 해당 데이터를 가져와서 사용
세번째 요청 시, 60초가 지났다면? 서버에서 다시 이미지를 받아온다.

브라우저 캐시 활용 효과

캐시가 유효한 시간 동안 네트워크 리소스를 아낄 수 있음
파일을 다시 받아올 필요가 없기 때문에 브라우저 로딩이 빨라짐
로딩이 빨라진 만큼 빠른 사용자 경험 제공 가능

🔗 캐시 검증 헤더와 조건부 요청

💁🏼‍♂️ 캐시 유효시간은 지났지만, 다시 받아와야하는 파일이 캐시에 저장되어 있는 파일과 완전히 동일하다면?

이런 상황에서 사용할 수 있는 HTTP 헤더들이 존재한다.

캐시 검증 헤더

캐시에 저장된 데이터와 서버의 데이터가 동일한지 확인하기 위한 정보를 담은 응답 헤더

Last-Modified : 데이터가 마지막으로 수정된 시점을 의미하는 응답 헤더로, 조건부 요청 헤더인 If-Modified-Since 와 묶어서 사용한다.
Etag : 데이터의 버전을 의미하는 응답 헤더로, 조건부 요청 헤더인 If-None-Match 와 묶어서 사용한다.

조건부 요청 헤더

캐시의 데이터와 서버의 데이터가 동일하다면 재사용하게 해달라는 의미의 요청 헤더

If-Modified-Since : 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인하고, 수정되지 않았다면 캐시된 리소스를 사용한다.
If-None-Match : 캐시된 리소스의 ETag 값과 현재 서버 리소스의 ETag 값이 같은지 확인하고, 같으면 캐시된 리소스를 사용한다.

🔗 Last-Modified 와 If-Modified-Since

캐시 유효 시간인 60초가 지났을 시, 서버의 파일이 마지막으로 수정된 시간을 의미하는 Last-Modified 헤더에 담긴 내용도 캐시에 함께 저장
캐시 유효 시간인 60초가 지났고 두번째 요청을 했을 시, “이 날짜 이후로 데이터 수정이 있었니? 없었다면 캐시에 저장해놓은 데이터를 재사용해도 괜찮을까?”라는 뜻의 요청 헤더 If-Modified-Since 를 작성하고 캐시에 함께 저장해놓았던 Last-Modified 값을 담아 요청(최종 수정일 = 캐시에 저장된 데이터 수정일)
서버와 캐시의 데이터가 동일한 데이터임이 검증되었다면 서버는 “데이터가 수정되지 않았음”을 의미하는 304 Not Modified 라는 응답을 보내주고, 캐시 데이터의 유효 시간이 갱신되면서 해당 데이터를 재사용할 수 있게 된다.

🔗 Etag 와 If-None-Match

첫 번째 요청을 보내고 응답을 받으면서 캐시 유효 시간이 60초인 이미지 파일을 같이 받아온다. 이 때, 서버의 파일 버전을 의미하는 Etag 헤더에 담긴 내용도 캐시에 함께 저장
캐시 유효 시간인 60초가 지났고 두번째 요청을 했을 시, “내가 캐시에 저장해놓은 데이터 버전이랑 서버 데이터 버전이랑 일치하니? 일치한다면 캐시에 저장해놓은 데이터를 재사용해도 괜찮을까?”라는 뜻의 요청 헤더 If-None-Match 를 작성하고 캐시에 함께 저장해놓았던 Etag 값을 담아 요청을 보낸다. 이 값을 이용해 서버 데이터의 Etag 와 캐시에 저장된 데이터의 Etag 를 비교, 두 데이터가 동일한 데이터라면 두 Etag 값이 같아야 한다.
서버와 캐시의 데이터가 동일한 데이터임이 검증되었다면 서버는 “데이터가 수정되지 않았음”을 의미하는 304 Not Modified 라는 응답을 보내주고, 캐시 데이터의 유효 시간이 갱신되면서 해당 데이터를 재사용할 수 있게 된다.

📍 트리 쉐이킹(Tree Shaking)

나무를 흔들어 잔가지를 털어내듯 불필요한 코드를 제거하는 것을 의미

트리쉐이킹을 해야하는 이유

JavaScript 파일의 늘어난 크기
JavaScript 파일의 늘어난 실행 시간

🔗 JS 트리쉐이킹

ES6 모듈에서 기본적인 트리쉐이킹을 제공 웹팩을 사용하는 환경에서 효과적으로 트리쉐이킹이 가능하다.

필요한 모듈만 import 하기
Babelrc 파일 설정하기
sideEffects 설정하기
ES6 문법을 사용하는 모듈 사용하기 - 사용하는 import 구문만 쓰기

Babelrc 파일 설정하기

{
  “presets”: [ 
    [
      “@babel/preset-env”,
      {
	    "modules": false
      }
    ]
 ]
}

sideEffects 설정하기

사이드 이팩트가 발생하지 않을 것이라고 알려준다.

{
  "name": "tree-shaking",
  "version": "1.0.0",
  "sideEffects": false
}

📍 Lighthouse

사이트를 검사하여 성능 측정을 할 수 있는 도구, 성능 검사와 개선책 또한 제공

Lighthouse는 크롬 개발자도구 또는 node CLI에서 실행 가능하다.

Lighthouse 분석 결과 항목

Performance : 웹 성능을 측정, 화면에 콘텐츠가 표시되는데 시간이 얼마나 걸리는지, 표시된 후 사용자와 상호작용하기 까진 얼마나 걸리는지, 화면에 불안정한 요소는 없는지 등을 확인
Accessibliity : 웹 접근성을 잘 갖추고 있는지 확인, 대체 텍스트를 잘 작성했는지, 배경색과 콘텐츠 색상의 대비가 충분한지, 적절한 WAI-ARIA 속성을 사용했는지 등을 확인
Best Pracices : 웹 표준 모범 사례를 잘 따르고 있는지 확인, HTTPS 프로토콜을 사용하는지, 사용자가 확인할 확률은 높지 않지만 콘솔 창에 오류가 표시 되지는 않는지 등을 확인
SEO : 웹 페이지 검색 엔진 최적화가 잘 되어있는지 확인, 플리케이션의 robots.txt가 유효한지, 요소는 잘 작성되어 있는지, 텍스트 크기가 읽기에 무리가 없는지 등을 확인
PWA(Progressive Web App) : 웹 사이트 모바일 애플리케이션으로서도 잘 작동하는지 확인, 앱 아이콘을 제공하는지, 스플래시 화면이 있는지, 화면 크기에 맞게 콘텐츠를 적절하게 배치했는지 등을 점수가 아닌 체크리스트로 확인

Lighthouse의 Performance 측정 메트릭

First Contentful Paint : 사용자가 페이지에 접속했을 때 브라우저가 DOM 컨텐츠의 첫 번째 부분을 렌더링하는 데 걸리는 시간을 측정합니다. 즉 사용자가 감지하는 페이지의 로딩속도를 측정할 수 있습니다. 우수한 사용자 경험을 제공하려면 FCP가 1.8초 이하여야 한다.
Largest Contentful Paint : 뷰포트를 차지하는 가장 큰 콘텐츠(이미지 또는 텍스트 블록)의 렌더 시간을 측정한다. 이를 이용해 주요 콘텐츠가 유저에게 보이는 시간까지를 가늠할 수 있다.
Speed Index : 페이지를 로드하는 동안 얼마나 빨리 컨텐츠가 시각적으로 표시되는 지를 측정한다.
Time to interactive : 페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간을 측정한다.
Total Blocking Time : 페이지가 유저와 상호작용하기까지의 막혀있는 시간을 측정한다. Lighthouse에서는 FCP와 TTI 사이에 긴 시간이 걸리는 작업들을 모두 기록하여 TBT를 측정한다.
Cumulative Layout Shift : 사용자에게 컨텐츠가 화면에서 얼마나 많이 움직이는지(불안정한 지)를 수치화한 지표이다. 이 지표를 통해 화면에서 이리저리 움직이는 요소(불안정한 요소)가 있는 지를 측정할 수 있다.

🔗APPLE 사이트 Lighthouse 해보기

🕵🏼‍♂️ 분석해보기

낮은 Performance로 보아, 현재 웹 성능은 좋치 않으며 로딩 시간이 오래걸리고 불안정 요소가 많다고 보인다.
높은 Best Practices로 보아, 웹 표준 모범 사례를 잘 따른 것으로 보인다.
높은 Accessibliity로 보아, 대기업에 걸맞는 사이트 답게 높은 접근성을 보인다.
높은 First Contentful Paint로 보아, 렌더링 시간이 평균(1.8초)보다 길다는 것을 알 수 있다.
높은 Largest Contentful Paint로 보아, 뷰포트를 차지하는 가장 큰 콘텐츠의 렌더 시간이 길다.(over 4s)
낮은 total Blocking Time으로 보아, 유저가 상호작용하는 막혀있는 시간은 적다(345s 이하)

📕 해결방안

Performance

현재 다른 다양한 웹 사이트 또한 50점을 넢는 사이트는 흔치 않다.

그렇기에 낮은 점수의 사이트라고 말하기는 어려우나 메트릭을 보아도 CPU의 렌데링 시간은 긴 것은 사실이다.

아마 대기업의 사이트이므로 담고 있는 양이 많은 것으로 추측된다.

렌더링의 시간을 줄이기 위해서는 data fetching(웹 사이트의 성능 = 시간 + 리소스) 방식을 변경하거나,

불필요한 API 콜을 없애는 것이다.

Largest Contentful Paint

현재 사이트에서 뷰포트를 제일 많이 차지하는 콘텐츠의 렌더링 시간이 평균보다 가장 높게 나온 것을 알 수 있다.

브라우저가 서버에서 콘텐츠를 받는데 걸리는 시간이 오래 걸리기 때문에 모든 페이지 로딩이 향상된 것으로 보인다.

아무래도 디스플레이를 중시하는 사이트이다 보니 최성능을 보여줌을 위함이 원인으로 보인다.

이를 해결하기 위해선, 비싼 쿼리를 쓰고 있지는 않은지, 프로세스를 지연하는 복잡한 동작을 하고 있진 않은지 확인하여

서버를 최적화하고, 사용자와 가까운 CDN(콘텐츠 전송 네트워크 - 다양한 위치에 분산된 서버들의 네트워크)을 사용하여

먼 곳에서의 네트워크 요청을 기다리지 않도록한다.

또한 자원을 캐시하여, 불필요한 HTML 생성을 방지한다.

'codeStates front-end > Html' 카테고리의 다른 글

[html] 개념 학습 <Flexbox> (0)	2023.01.04
[html] 개념 학습 <레이아웃> (0)	2023.01.04
[html] 실습 - 로그인 구현2 (0)	2023.01.04
[html] 개념 학습 <id , class> (0)	2023.01.04
[html] 개념 학습 <웹 앱의 구조 잡기> (0)	2023.01.04

ABOUT ME

HwanTech HwanTech

목차

📌 optimization

📍 최적화(optimization)

🔗 최적화의 필요성 및 효과

🔗 HTML,CSS 코드 최적화하기

🔗 리소스 로딩 최적화하기

🔗 브라우저 이미지 최적화하기

📍 캐시 관리

🔗 캐시 검증 헤더와 조건부 요청

🔗 Last-Modified 와 If-Modified-Since

🔗 Etag 와 If-None-Match

📍 트리 쉐이킹(Tree Shaking)

🔗 JS 트리쉐이킹

📍 Lighthouse

🔗APPLE 사이트 Lighthouse 해보기

🕵🏼‍♂️ 분석해보기

📕 해결방안

'codeStates front-end > Html' 카테고리의 다른 글

티스토리툴바

ABOUT ME

목차

📌 optimization

📍 최적화(optimization)

🔗 최적화의 필요성 및 효과

🔗 HTML,CSS 코드 최적화하기

🔗 리소스 로딩 최적화하기

🔗 브라우저 이미지 최적화하기

📍 캐시 관리

🔗 캐시 검증 헤더와 조건부 요청

🔗 Last-Modified 와 If-Modified-Since

🔗 Etag 와 If-None-Match

📍 트리 쉐이킹(Tree Shaking)

🔗 JS 트리쉐이킹

📍 Lighthouse

🔗APPLE 사이트 Lighthouse 해보기

🕵🏼‍♂️ 분석해보기

📕 해결방안

'codeStates front-end > Html' 카테고리의 다른 글

관련글 관련글 더보기

티스토리툴바

📍 Lighthouse