웹 로딩 개선 과정, QR-ORDER 관리자 프로젝트

 

개선 결과
리소스	마침	DOMContentLoaded	로드
-378kB (-41%)	-4.21s (-30%)	-2.32s (-24%)	-2.31s (-24%)

 

---

 

측정 환경 설명

- 시크릿 탭: 확장자 프로그램 영향 최소화
- 3G: 네트워크 설정 가능한 최저 속도
- 빈 캐시 및 하드 새로고침: 캐시 유무에 따른 초기 리로드 영향 최소화

3번의 로드 결과를 바탕으로 평균값을 도출했다.

번들 분석은 "vite-bundle-visualizer"를 사용했다.

* 빌드 출력 표는 빌드 파일이 많은 관계로 필요한 index 파일만 표시했다.

 

1. 첫 빌드 #61f8f32

빌드 출력
File	Original size	Gzip
dist/index.html	0.47 kB	0.30 kB
dist/assets/index-DmbkiVgs.css	31.40 kB	7.68 kB
dist/assets/index-CeNwlhjF.js	851.83 kB	262.97 kB
dist/assets/browser-7HF8to9h.js	0.34 kB	0.27 kB

네트워크 측정
리소스	마침	DOMContentLoaded	로드
924kB	13.96s	9.54s	9.54s

번들 파일

페이지 이동이 없어서
모든 파일이 index.js 안에 포함되어 있었다.

번들 파일을 보고 테두리 친 라이브러리를 절감할 수 있을 것 같았다.

[ 테두리 친 라이브러리 ] 
- uuid(연초록): Supabase 대시보드 데이터베이스에서 uuid 자동 생성 설정으로 제거 가능
- swiper(노랑): css overflow: auto 속성으로 좌우 스크롤 자체 구현
- redux(파랑): 추가 라이브러리와 사전 준비 코드가 적은 Zustand로 마이그레이션 

이외에도 번들 크기 절감을 목표로 개선 방안을 떠올렸다.

[ 이외 개선 방안 ]
1. 지연 로드 적용
2. 이미지 확장자 변환
3. fetch 요청 최소화
4. 코드 개선

 

2. 두 번째 빌드 #26e35d9

빌드 출력
File	Original size	Gzip
dist/index.html	0.49 kB	0.32 kB
dist/assets/index-RJnSRQBt.css	11.86 kB	2.66 kB
dist/assets/index-D2t-1BhZ.js	435.53 kB	134.53 kB
other files...	314.38 kB	101.01 kB

네트워크 측정(증감)
리소스	마침	DOMContentLoaded	로드
484kB (-440)	11.18s (-2.78)	6.83s (-2.71)	6.83s (-2.71)

번들 파일

빨간 부분이 index, 그외 부분이 지연 적용된 번들이다.

첫 번째 빌드보다 빨간 부분이 줄어들었다. 

다만 마침 시간이 10초를 넘었고
로드되었을 때 아이콘 이미지가 툭 등장하는 점이 신경 쓰였다.

마침 시간을 10초 이하로,
아이콘 이미지 등장을 DOM 생성 시점과 동기화하고 싶었다.

아이콘 이미지 문제의 원인은 네트워크 탭에서 찾을 수 있었다.

네트워크 탭

노란 부분은 index, 초록 부분은 지연 파일, 보라 부분은 이외 리소스로 구성되어 있었다.

노란, 초록 부분을 줄여도
보라 부분이 있어 마침 시간이 지연됐다.

index 파일 용량을 절감하는 것보다
보라 부분을 생략하는 것이 효율적이었다.

OrderCategoryAlert 컴포넌트는 lazy 적용 해제 하면 되지만
아이콘 이미지 생성을 DOM 파싱 시점과 동기화 하는 방법이 떠오르지 않았다.

문득 아이콘을 DOM으로 변환하면 되지 않을까 라는 생각이 떠올랐다.
글자로 변경하거나 유니코드를 적용하는 방법이 있었다.

다양한 아이콘을 컴포넌트로 사용할 수 있는 라이브러리가 있었다.
Google Material icons, Font Awesome을 알게 됐다.

Google Material icons,
사용 폰트만 가져와 용량을 최소화할 수 있지만 최대 3가지였고
무엇보다도 <Link />로 받아오는 폰트 리소스 때문에 패칭 단계가 추가되는 상황이 발생했다.

이러한 문제로 Font Awesome 라이브러리를 도입했고
index 파일 용량 증가를 주의하여 최소한의 라이브러리 기능만 사용했다.

 

3. 세 번째 빌드 #569589f

빌드 출력
File	Original size	Gzip
dist/index.html	0.47 kB	0.31 kB
dist/assets/index-BeXfFDO3.css	10.29 kB	2.37 kB
dist/assets/index-l7L9R_py.js	493.70 kB	153.65 kB
other files...	322.77 kB	103.54 kB

네트워크 측정(증감)
리소스	마침	DOMContentLoaded	로드
546kB (+62)	9.75s (-1.43)	7.22s (+0.39)	7.23s (+0.4)

네트워크 탭

예상대로 index 파일 용량이 증가했지만,
마지막 리소스 단계가 생략되어 마침 시간이 줄어들었다.

페이지 마침 시간은 한 자릿수를 달성했고
아이콘 등장 딜레이도 없어졌다.

Vercel 배포 후 측정한 결과,
Vercel 리소스가 추가되어 1초가 추가되었다.
두 자리 수로 넘어가서 아쉽다.

 

로딩 개선 이전/이후 비교

첫 빌드
리소스	마침	DOMContentLoaded	로드
924kB	13.96s	9.54s	9.54s

마지막 빌드
리소스	마침	DOMContentLoaded	로드
546kB	9.75s	7.22s	7.23s

개선 결과
리소스	마침	DOMContentLoaded	로드
-378kB (-41%)	-4.21s (-30%)	-2.32s (-24%)	-2.31s (-24%)

 

알게 된 것

- index 파일 용량이 증가해도 리소스 패칭 단계가 짧으면 로드 시간을 줄일 수 있다.
- 프로젝트에 알맞은 라이브러리가 있다.
- 한 가지 기능을 위해 라이브러리를 사용하는 것보다 직접 구현하는 게 낫다.
- 생각보다 번들 압축 성능이 뛰어나다.
- 초기 로드 시간이 길어도 로딩 UI가 있다면 기다릴 만하다.