프론트엔드 성능 최적화를 공부하면서 가장 크게 바뀐 생각

처음엔 성능 최적화라고 하면 단순히

Lighthouse 점수 올리기
이미지 압축하기
React memo 쓰기

정도로 생각했다.
실제로 EC2 프리티어에 직접 배포해보면서 생각이 완전히 바뀌었다.

이거 커지면 커질수록 다 돈이잖아?

번들 크기

처음엔 JS 번들 크기를 너무 가볍게 봤다.

"요즘 인터넷 빠른데 몇 MB쯤이야"

라고 생각했다.

근데 AWS 프리티어 EC2에 Next.js 프로젝트를 올리는 순간 체감이 왔다.

npm install 중 멈춤
next build 도중 프로세스 종료
메모리 부족
명령어 자체가 버벅임

같은 상황을 꽤 자주 경험했다.

그때 처음

“아 번들 크기는 단순 프론트 문제만이 아니구나”

라는 걸 느꼈다.

실제로는

빌드 메모리
서버 리소스
배포 시간
실행 비용

까지 전부 연결되어 있었다.

코드 스플리팅

예전엔 dynamic import를

"있으면 좋은 최적화"

정도로 생각했다.

근데 실제로는 초기 로딩 자체를 바꾼다.

const Chart = dynamic(() => import('./Chart'));

이렇게 하면 차트를 첫 화면에서 굳이 안 받아도 된다.

즉

초기 JS 감소
초기 파싱 감소
초기 실행 감소

효과가 생긴다.

특히 차트 라이브러리나 에디터처럼 무거운 패키지에서 체감이 크다.

라이브러리 선택

처음엔 라이브러리 크기를 거의 신경 안 썼다.

근데 번들 분석을 해보면 꽤 놀랍다.

예를 들어

moment
lodash 전체 import
chart library
rich text editor

같은 게 엄청 큰 비중을 차지한다.

그래서 지금은

moment → dayjs
lodash → lodash-es

라이브러리에 성능도 성능이지만 크기도 정말 중요한 요소라는게 실감이 났다

트리 쉐이킹

import _ from 'lodash';

이런 방식이면 lodash 전체가 들어올 수도 있다.

import debounce from 'lodash/debounce';

처럼 필요한 것만 가져오면 번들이 줄어든다.

CLS는 숫자가 아니라 “사용자 스트레스”

근데 모바일에서 뉴스 사이트를 보다가:

읽으려는 순간 광고 로딩
→ 화면 밀림
→ 잘못 클릭

을 경험하고 바로 이해됐다.

CLS는 단순 성능 지표가 아니라:

사용자가 그 사이트를 신뢰할 수 있는가

에 영향을 줄수있겠구나

Skeleton UI

"곧 여기에 콘텐츠가 들어옵니다"

라는 공간 예약에 가깝다.

skeleton ui를 사용하면

레이아웃 이동 감소
사용자 예측 가능성 증가
CLS 감소

효과가 생긴다.

애니메이션 최적화

처음엔:

top
left
width

애니메이션을 아무렇지 않게 썼다.

근데 브라우저 렌더링 파이프라인을 공부하고 나서 생각이 바뀌었다.

Layout
→ Paint
→ Composite

이 과정에서 Layout이 가장 비싸다.

즉

transform
opacity

만 사용하는 이유는 단순 팁이 아니라,

브라우저가 가장 적게 일하게 만드는 전략이다

Lazy Rendering

lazy loading이 단순 네트워크 최적화 뿐 아니라

DOM 생성 감소
JS 실행 감소
메모리 감소

까지 연결된다.

즉:

"지금 안 보이는 건 나중에"

전략이다.

특히 무한 스크롤이나 대규모 리스트에서 차이가 크다.

결국 성능 최적화는 “브라우저를 덜 힘들게 하는 것”

예전엔 최적화를

더 빠르게 만들기

라고 생각했다.

근데 지금은 오히려

브라우저와 서버가 해야 할 일을 줄이는 과정

에 가깝다고 느낀다.

JS 줄이기
Layout 줄이기
Paint 줄이기
초기 렌더링 줄이기
메모리 사용 줄이기

결국 전부

"얼마나 덜 시킬 것인가"

문제인것 같다.

Rendering 최적화