시작에 앞서,

만들고 있는 웹사이트에 큰 문제가 생겼다. 모바일 성능이 랜딩되는데 무려 19초가 걸린다는 것이다. PC버전은 성능이 92로 거의 2초 내에 로딩이 되는 반면, 모바일 버전은 총 로딩이 끝나는시간이 19초로 유저가 무조건 떠나는 시간이였다.

웹사이트 최적화에서 가장 중요한것은?

일단 웹사이트 최적화를 위해 나는 PageSpeed Insights라는 사이트를 이용했다.

밑에 사진에서 보여주듯, 위에서 부터 웹사이트의 성능을 개선하기 위해 가장 필요한 순위를 보여준다. 순서대로 보자
1. 차세대 형식을 사용해 이미지 제공하기
2. 렌더링 차단 리소스 제거하기
3. 사용하지 않는 자바스크립트 줄이기
4. 사용하지 않는 CSS 줄이기

이번 포스팅을 차세대 형식을 사용해 이미지를 제공하면 웹사이트 성능에 얼마만큼의 변화가 있을까에 대한 포스팅이고, 2,3,4번을 추후 포스팅에서 다루면서 웹사이트 성능을 개선해보고자 한다.

차세대 형식의 이미지 제공이란?

차세대 이미지 형식의 대표로는 두가지가 있는데, webp와 avif다. webP는 구글에서 2010년에 발표한 형식으로, JPEG보다 더 나은 압축과 더 많은 기능을 제공하는 형식이다. AVIF는 AOMedia에서 2019년에 발표한 형식으로, webP와 유사하게 높은 압축률을 자랑한다. 이중 호환성이 webP가 더 좋음으로, webP의 특성과 도입시 주의해야 할 것에 대해 알아보자.

WebP란?

WebP 는 이미지 품질을 유지하면서 파일 크기를 더 작게 할 수있는 이미지 형식이다. 블로거, 웹 디자이너 및 사이트 개발자는 JPEG에서 WebP를 사용하여 그래픽 및 반투명 이미지를 사용하여 웹 사이트 속도를 크게 높일 수 있다. 이미지의 사이즈가 적을수록 사용자가 페이지를 클릭 할 때 로딩 속도가 빨라지고 사이트에 있어서 이탈률이 줄어들기 때문에 이미지 사이즈는 웹사이트 성능개선에 있어서 매우 중요하다고 볼 수 있다.

webP의 특징

엄청난 압축률

아래 사진을 보면 2.3MB 사진이 372KB로, 603KB사진이 104KB로 이미지 크기가 줄어든걸 볼 수 있다. 80%가 넘는 압축률이지만, 이미지 규격 1067 x1080은 그대로일 정도로 엄청난 압축률을 보여준다.

호환성

그렇다면 모든 상황에서 webP를 쓰면 되지않나? 장점만 있다면 모든 이미지를 webp로 교체해서 쓰면 되겠지만, 아무래도 2010년에 나온만큼, 모든 웹 브라우저와 호환이 되는것은 아니다. 비교적 최근에 나온 브라우저들은 모두 호환이 가능하지만 예전 버전을 쓰는 사람들은 호환이 되지 않는다.

webP 적용해보기

앞서 언급했듯, 엄청난 압축률을 자랑하기 때문에, 웹사이트의 성능을 빠르게 하기 위해선 webP를 적용하는게 좋아보인다. 하지만 그럴 경우, 호환이 되지 않는 유저는 포기를 해야할텐데, 두마리 토끼를 다 잡을 수 있는 방법은 없을까?

이를 해결하기 위해 picture태그를 사용했다. picture tag에 대해 한번 알아보자.

picture tag란?
picture tag는 img 요소의 다중 이미지 소스를 위한 컨테이너를 정의할때 사용된다.

picture tag요소는 0개 이상의 source요소와 하나 이상의 img소스로 구성되며, 브라우저는 소스 요소중 해당 뷰포트와 가장 잘 어울리는 소스 요소를 다음과 같은 방법을 사용하여 선택한다.

브라우저는 source요소의 속성값을 각각 확인해 나가며 조건을 만족하는 첫번째 source요소를 사용하고 나머지 요소들으 무시합니다. 이때 img요소는 자식요소중 마지막에 위치해야 한다.

이러한 img요소는 picture 요소를 지원하지 않는 브라우저를 위한 하위 호환성을 위해 사용되거나 명시된 source요소가 모두 조건을 만족하지 못 할 경우 사용된다.

기존 코드
	<UpperBox>
		<img src="img/home/review2/mobile/png/background.png"></img>
	</UpperBox>

바뀐코드
	  <UpperBox className="object">
        <picture>
          <source
            srcSet="img/home/review2/mobile/webp/background.webp"
            type="image/webp"
          ></source>
          <source
            srcSet="img/home/review2/mobile/png/background.png"
            type="image/png"
          ></source>
          <img
            src="img/home/review2/mobile/png/background.png"
            alt="워킹마스터"
          ></img>
        </picture>
      </UpperBox>

성능 개선이 얼마나 되었을까?

이제 성능을 테스트해볼 시간이다. 과연 얼마만큼의 성능이 개선되었을까?

더이상 차세대 이미지 제공에 대한 문구는 보이지 않고, 처음에 보였던 Largest Contentful paint가 19초에서 5초로 무려 14초나 개선된걸 볼 수 있다.

마무리,

여전히 느리지만 36점에서 55점은 엄청난 개선이라고 생각한다. 웹사이트 라는게 거의다 끝났다 싶으면 항상 새로운 개선점이 나오는것 같다. 렌더링 차단 리소스중 가장 큰 비율은 google web api font인데, 아무래도 사이트가 직접 폰트를 다운받아서 쓰는게 아니라 web api로 통신을해서 바꾸는 과정이 들어가다보니 2.37초의 지연이 나오는거라 생각한다. 다음 포스팅에선 font를 직접 다운받아서 적용해보고 어느정도의 웹사이트 성능 개선이 있었나에 대한 포스팅을 해야겠다.