[Front-end] 프론트엔드 성능 최적화 - 1

프론트엔드 영역은 근 몇 년간 급격한 변화와 발전이 있었습니다.

웹에서 그림을 그리고 게임도 하며 프로젝트 일감, 일정을 관리합니다.

과거 script로 정적, 단순 동적 웹 사이트를 구축하던 시절과는 달리 요새는 복잡한 기능들이 구현되고 있습니다

 

과거 웹사이트

요즘 웹 어플리케이션

 

그렇다 보니 필연적으로 성능 이슈가 발생하게 됩니다. (ex..스크롤이 뚝뚝 끊겨요, IE11에서 로딩이 느립니다, 간혹 가다 멈춰요..)

 

프론트엔드 성능을 개선하게 될 경우 어떤 효과가 있을까요?

빠른 로딩 속도 -> 사업 지표 향상 -> 사용성 개선으로 직결됩니다

전 세계적으로 많이 사용되는 소셜 네트워크 서비스 핀터레스트의 성능 개선 후 사업 지표입니다.

 

성능 개선 전 핀터레스트 모바일 웹의 로딩 시간은 무려 23초였다고 합니다. 이는 사용자가 불만을 느낄 수 있는 로딩 시간입니다.

이를 인지하고 핀터레스트는 약 3개월 로딩 성능 최적화 작업을 진행하였고 결과적으로 위와 같이 사업 지표 개선을 이뤄낼 수 있었습니다.

 

결국 성능 개선은 돈과도 직결되는 중요한 이슈라고 볼 수 있겠습니다.

 

 

본론으로 들어가서 프론트엔드 성능 최적화에 대해 구체적으로 알아보겠습니다.

프론트엔드 성능 최적화는 크게 로딩 최적화와 렌더링 성능 최적화가 있습니다.

 

로딩 최적화

브라우저 로딩 최적화는 Processing, Load 타임을 줄이는데 목표가 있습니다.

Processing: html, css, javscript를 파싱하고 브라우저에 리소스, 레이아웃을 그릴 준비를 처리

Load: html, 이미지 리소스 로드 진행

 

간혹 인터넷이 느린 환경에서 웹 사이트에 접속했을 때, 페이지가 뜨지 않고 흰 화면이 지속되는 사이트가 있습니다.

흰 화면이 지속되는 예시 사이트에서 개발자 도구(Performance 탭)로 분석해보면 

 

 processing 단계에서 상당히 많은 시간을 허비하고 있었습니다.

 

파싱 처리 순서는 HTML -> CSS -> JS 순서로 진행됩니다.

HTML 처리 부분을 확대해서 보겠습니다.

HTML 파싱이 CSS, JS로 인해서 중단된 것을 확인할 수 있습니다.

여기서 HTML 파싱을 멈추는 css, js를 블록 리소스라고 표현합니다.

이 블록 리소스 때문에 흰 화면이 발생하고 있습니다.

 

블록 리소스에 의해서 흰 화면이 발생하는 것을 이해하려면 브라우저 렌더링 과정의 이해가 필요합니다.

브라우저는 최초로 HTML을 파싱을 해서 DOM 트리를 생성합니다.

그다음 스타일 정보를 파싱 해서 CSSOM 트리를 생성합니다.

위 트리를 조합하여 Render 트리를 만듭니다.

 

이 Render 트리를 가지고 본격적으로 화면에 그리기 전 '레이아웃' 이라는 과정을 거치게 됩니다.

레이아웃이란 브라우저에 뿌려질 Render 트리의 각 요소(태그)의 위치와 크기를 계산합니다. 비용이 매우 큰 작업입니다.

(ex. 박스의 좌표와 크기, 폰트 크기.. 이미지의 크기 계산)

'레이아웃' 이라는 과정을 거친 후 '페인팅' 작업에 들어가고 웹 화면에 뿌려지게 됩니다.

 

즉, 브라우저가 렌더링을 하려면 HTML 파싱과 CSS 파싱을 필요로 합니다.

HTML을 파싱하다가 CSS를 만나면 CSS도 렌더링에 필요한 필수 파싱 요소이기 때문에 CSS를 파싱하게 됩니다.

 

그런데 JS 같은 경우는 브라우저가 렌더링 하는데 필요가 없어 보입니다. 그런데 왜 블록 리소스일까요?

왜냐 JS에서도 HTML과 CSS에 접근하여 레이아웃 변경 작업을 할 수 있기 때문입니다.

 

결론으로 흰 화면이 유지됐던 이유는 HTML을 파싱하는 도중에 블록 리소스인 CSS, JS 파싱 처리가 필요했기 때문이었습니다.

 

어떻게 하면 성능을 최적화해서 processing 시간을 줄일 수 있을까요?

다음 게시글에 이어서 알아보도록 하겠습니다.