브라우저를 최적화시키기 위해선?

스터디2024.08.02

브라우저 렌더링

📖 Reference 📎https://boxfoxs.tistory.com/408 📎https://velog.io/@bumsu0211/브라우저-렌더링-과정과-최적화

💡브라우저 최적화

🤔 브라우저 최적화를 진행하는 이유는 뭘까?

브라우저 최적화를 진행하는 이유는 사용자 경험 이다.
웹 어플리케이션에도 첫인상이라는 것이 존재한다.
웹의 첫인상은 사이트의 디자인, 적재적소의 UI 애니메이션, 헤드 카피 등의 시각적인 요소일 수 있다.

시각적인 측면도 웹의 첫인상일 수 있지만, 응답성 측면의 첫인상도 있다.

만약, 페이지 로딩이 길어서 사용자가 3초 이상 아무것도 없는 화면을 보게된다면?.. → ~~바로 페이지 나가기.~~

🔨 브라우저 최적화 점수 측정법

구글에서 제공하는 페이지 속도 측정 사이트에서 원하는 페이지의 최적화 점수 를 알아낼 수 있다.

이때, 크롬 확장 프로그램인 Light House 에서도 최적화 점수 측정이 가능하다. → Google Speed Insight가 Light House 를 내부적으로 사용한다. 📎PageSpeed Insights 📎Lighthouse | Tools for Web Developers | Google Developers

💯 브라우저 최적화 항목

1. FCP (First Contentful Paint)

페이지가 로드되기 시작한 시점으로부터 페이지의 콘텐츠 일부가 렌더링될 때까지 걸린 시간을 의미한다.
전체 콘텐츠가 로딩되지 않아도 사용자는 소비할 수 있는 컨텐츠를 보게 되며, 로딩이 진행되고 있음을 인지하도록 한다.
1.8sec 이내에 FCP가 수행되어야 GOOD 으로 좋은 점수를 받는다.
3sec 이상 FCP가 수행되면 개선이 필요한 페이지임을 알 수 있다.

→ 사용자가 3초동안 아무런 화면도 볼 수 없는 상태를 뜻한다.

🎨 1-1. 웹 폰트와 FCP

보통 페이지가 로드되어 렌더링되는 첫 요소는 텍스트 일 가능성이 크다.
이미지나, 비디오는 다운로드 시간이 별도로 존재하기에 텍스트가 먼저 보이게 되는데, 폰트 설정을 어떻게 하냐에 따라 FCP시간에 영향이 갈 수 있다.

위 사진과 같이 각각의 폰트 또한 하나의 모듈(Module) 이기에 다운로드 시간을 가진다.

만약 다운로드되는 폰트의 파일 용량이 크다면 다운로드 시간은 길어질 것이며 최종적으로 사용자는 폰트가 적용된 텍스트를 보기까지의 시간이 더 소요된다.

이를 해결하기 위해 FOUT(Flash of Unstyled Text) 방식을 사용하거나 웹 폰트 포맷인 woff2 , woff , eot , ttf 등을 사용한다.

🤔 폰트 용량 줄이기!

개발하는 중 웹 폰트 를 적용해본 경험이 있다면 @font-face 를 사용해본 경험이 있을 것이다.
웹 폰트 는 대표적으로 woff2 , woff , eot , ttf 등의 형식이 존재하며, 각각의 포맷은 압축 방식이 달라 파일 용량이 다르다.

@font-face {
      font-family: NanumSquareRound;
      src: local("NanumSquareRound"),
      local("NanumSquareRound"),
      url(NanumSquareRound.woff2),
      url(NanumSquareRound.woff),
      url(NanumSquareRound.eot),
      url(NanumSquareRound.ttf);
      font-weight: bold;
    }

대부분의 브라우저는 압축율과 효율이 가장 좋은 woff2 형식을 지원한다.
IE 에서는 그 다음으로 압축율이 좋은 woff 형식을 지원한다.

→ 즉, 대부분의 브라우저는 woff 와 woff2 형식의 폰트 파일만으로도 충분히 커버할 수 있다.

만약, 여러개의 폰트 파일을 사용한다면 브라우저는 해당 브라우저가 지원하는 폰트 파일을 사용한다.
예시) IE 에서 woff2 , woff 폰트 파일이 2가지 존재한다면 woff2 를 다운로드 후 폴백(fallback)한 뒤 woff 파일을 사용한다.

🤔 `FOUT(Falsh Of Unstyled Text)` 가 뭐지?

위 사진을 보면 폰트가 제대로 불러와지지 않아 잘못된 정보를 사용자에게 전달하고 있음을 알 수 있다.

웹 폰트의 문제는 폰트가 다운로드되기 전 텍스트를 표시하지 않으면 사용자에게 잘못된 정보를 전달할 수 있다는 것이다.

브라우저가 렌더링되는 중 CSSOM 트리 를 만드는 과정에서 CSS 파일에 포함된 웹 폰트 모듈을 다운로드 받기 시작한다.
그 뒤 Paint 단계에서 웹 폰트 모듈이 다운로드되지 않은 경우 화면에 그리는 것을 차단한다.

→ 따라서, 웹 폰트가 적용된 텍스트가 사용자에게 보이지 않는 순간이 존재하게 된다.

FOIT(Flash Of Invisible Text) : 폰트파일이 다운로드되기 전에 텍스트가 보이지 않고, 다운로드 후에 번쩍이듯이 텍스트가 등장

FOUT(Flash Of Unstyled Text) : 폰트파일이 다운로드 되기 전에는 기본 폰트 로 텍스트가 표시되다가 다운로드가 완료되면 해당 폰트로 변경

크롬(Chrome) 은 기본적으로 FOIT 방식을 사용한다. ← 사용자 경험(UX) 관점에서는 좋지 않음.

→ FOUT(Flash Of Unstyled Text) 방식 권장

💡CSS에서 `FOUT` 방식 설정

@font-face{
...
	***font-display: swap;***
	font-weight: bold;
}

font-display: swap 속성을 사용하여 텍스트들을 FOUT 방식으로 렌더링 할 수 있다. 즉, 기본 텍스트를 빠르게 출력시켜 FCP 시간을 단축하기 위해 적용할 수 있음.

2. TTI(Time to Interactive)

TTI(Time to Interactive) 이란 ?

→ 페이지가 완전히 상호작용할 준비를 마치기까지 걸린 시간

Idle Window 시간 이내에 존재하는 Last Long-Task 가 끝나는 시간을 측정한다.
💡 Idle Window = CPU Idle & Network Idle
CPU Idle = 메인 스레드에 작업이 존재하지 않는 짧은 시간
Network Idle = 2개 이하의 네트워크 요청(Request)이 존재하는 시간
웹에서의 상호작용은 JavaScript 를 통해 이뤄지므로, Last Long-Task 가 끝나면 상호작용 준비가 되었다고 간주한다.

만약, 페이지 TTI이 3.8초 이내로 측정되었다면, 사용자가 JS와 상호작용(이벤트를 발생시키는 등)을 하여도 정상 동작하기에 UX를 해치지 않는다.
만약, 페이지 TTI이 7.3초 이상으로 측정되었다면, 사용자가 JS와 상호작용을 하여도 아무런 반응이 없다는 의미이며, 이는 UX를 해침과 동시에 개선이 필요한 상태이다.

그 외에..

TBT(Total Blocking Time) : 메인 스레드가 차단된 시간의 총합
FCP와 TTI 사이에 메인 스레드가 얼마나 차단되었는지 측정
SI(Speed Index) : 페이지 콘텐츠가 채워지는 속도
시각적 변화가 안정되는 시점까지 걸린 시간을 측정
LCP(Largest Contentful Paint) : 페이지 로드 시점부터 첫 화면 영역 내의 가장 큰 이미지나 텍스트 블록이 렌더링될 때까지의 시간
페이지 로딩 스냅샷마다 화면 영역에서 가장 큰 블록을 찾아 LCP의 시점을 조정
CLS(Cumulative Layout Shift) : 페이지 수명 동안 발생하는 모든 예기치 않은 레이아웃 변화에 점수를 매겨 특정
페이지 스냅샷마다 레이아웃이 얼마나 변경되는지 측정

위와 같이 다양한 브라우저 최적화 측정 기준이 존재한다. 자세한 내용은 아래를 참고하자.

📎 https://velog.io/@bumsu0211/브라우저-렌더링-과정과-최적화

😁 브라우저 최적화 방법의 종류

화면을 띄우기까지 걸리는 시간 = 필요한 파일 다운로드 시간 + 브라우저에 화면을 그리는 시간

만약, 파일 다운로드 에 초점을 맞춰 브라우저 최적화를 진행하고자 하면 다음과 같이 진행한다.

파일의 용량을 줄인다.
한 도메인에서 다운로드 받는 파일의 개수를 많이 늘리지 않는다.
초기 화면에 필요한 파일만 다운로드 받거나 지연시킨다.
여러 페이지에 걸쳐 사용되는 파일을 캐싱한다.
이미지 다운로드를 뒤로 미뤄 CSS, JS 파일을 더 빨리 다운로드 시킨다.

1. Webpack 사용

파일 용량을 압축시킬 수 있다.
모듈 번들링 을 통한 파일 개수를 감소한다.

자세한 사항은 아래에서 확인한다. WebPack, Babel

2. Image Lazy Loading

화면에 실제로 이미지가 보여져야 할 때 이미지를 다운로드하여 CSS와 JS보다 더 빨리 다운로드한다.

<img loading="lazy" src="..."/>

3. WebP

WebP는 구글에서 개발한 이미지 포맷
WebP 는 인터넷에서 흔히 쓰이는 GIF , JPG , PNG 포맷을 대체하기 위해 개발
WebP 의 가장 큰 강점은 이미지 품질이 같을 때 WebP 파일의 크기가 다른 포맷의 파일에 비해 훨씬 작다는 것이다.
특히, GIF 와 같은 애니메이션 이미지의 경우 GIF 파일을 WebP 파일로 바꾸면 이미지 품질은 유지하며 파일 크기는 절반 이하로 줄일 수 있다.

크롬(Chrome), 엣지(Edge) , 사파리(Safari) 등 대부분의 웹 브라우저에서 WebP 포맷으로 구성된 이미지를 볼 수 있다.
즉, 브라우저를 최적화하기 위해 압축율이 좋은 이미지 포맷을 사용하여 파일 용량을 압축한다.

<img src="some-image.webp" onerror="this.src='some-image.png'"/>

4. Lazy Component

첫 화면에 보이지 않는 컴포넌트는 나중에 다운로드 하여 파일의 개수를 감소한다.
당장 필요하지 않은 컴포넌트의 코드는 따로 분리시켜 파일의 용량을 감소시킨다.

const Home = () => import('/Home.vue');
const About = () => import('/About.vue');
const Contact = () => import('/Contact.vue');

const routes = [
	{ path : '/', name: 'home', component: Home },
	{ path : '/about', name: 'about', component: About },
	{ path : '/contact', name: 'contact', component: Contact },
]

5. Browser Caching

브라우저에 파일을 캐싱하여 다운로드할 파일의 개수를 감소시킨다.
다운로드 하는 시간 자체가 없어지므로 상당한 최적화 효과를 가질 수 있다.

브라우저 캐싱(Browser Caching) 에 대한 자세한 설명은 여기