momo
3 min readMay 15, 2022

--

웹 퍼포먼스 최적화 방법론 — [이미지 프리로딩]

웹 3.0시대에 맞춰 무궁무진한 컨텐츠들이 웹상에 쏟아지고, 여기엔 불가피하게 고화질의 gif, png, mp4 등의 소스들도 빈번히 사용되고 있습니다.

이러한 소스들은 무거울수록 사용자 경험측면에서 비효율적이기 때문에, 이를 보다 편리하고 유용하게 관리하는 흐름에 대해 소개하는 글을 작성해보고자 합니다.

흔히 우리는 다양한 소스들을 html 태그에 작성해 이를 화면상에 뿌려주고 있습니다. iframe, video, img 등이 대표적이죠.

브라우저가 화면을 렌더링하는 과정은 다음과 같습니다.

browser rendering process

Parsing

  • HTML 파일과 CSS 파일을 파싱해서 각각 Tree를 만듭니다. (parsing)

Style

  • 두 Tree 결합하여 Rendering Tree를 만듭니다. (style)

Layout

  • Rendering Tree에서 각 노드의 위치와 크기를 계산합니다. (layout)

Painter

  • 계산된 값을 이용해 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만듭니다. (paint)

Composite

  • 레이어를 합성하여 실제 화면에 나타냅니다. (composite)

하지만 웹은 기본적으로 동기화(Synchronous) 속성을 가지고 있기 때문에 HTML을 렌더링하는 과정에서 스크립트 <script>나 스타일 시트<link>를 만나게 되면 즉시 파싱을 멈추고, 해당 요소를 실행합니다. 이로 인해 이들의 처리 순서가 렌더링에 영향을 줄 수 있는 것이죠.

보통 소스를 사용하는 HTML tag ( video, img, iframe … ) 등의 src attribute에 해당 소스가 사용되면, 그 때 브라우저는 해당 소스를 가져옵니다. (네트워킹 탭 확인)

그렇다면 이를 js상에서 미리 호출하고, 캐싱된 이미지 소스들을 사용한다면 사용자 경험 측면에서 훨씬 더 효과적일 것입니다.

그렇다면 코드와 실제 속도를 비교해보면서 체감해보시죠!

data fetch 시점에서 images 소스들을 배열 안 담고 이를 preload 파라미터로 넘겨 js상에서 소스들을 불러옵니다.

또한 이미지가 로딩되고 나서 추가적인 작업 사항이 있다면,
이미지 자체에 onload, onerror를 추가적으로 걸어줄 수도 있습니다.

하지만 사용자 경험을 고려하지않고, 무분별하게 모든 이미지들에 preload를 걸어버리면.. 동기적으로 작업이 수행되는 동안 parsing 하지 못하게 됨에 따라 로딩이 매우 길어지는 불편함을 겪을 수 있습니다. 때문에 부분적으로 유저 친화적으로 설계하고 적용하는 쪽을 추천합니다.

구현하고 있는 프로젝트가 gif,png,jpg 등의 무거운 소스들이 많아 웹 퍼포먼스 측면에서 걱정이 되신다면, HTML parsing전 src들을 js 상에 호출하여 개발자도구 > 네트워크 > 이미지 필터를 적용한 결과를 비교해보시길 바랍니다.

before & after preload

ref.

이미지 외에도 최적화 memoization, serviceWorker 등을 다루는 포스팅도 기회가 된다면 작성해보도록 하겠습니다! 다들 몸 건강히 행코하세요 =3=3

--

--