CSS-in-JS와 성능

2021-06-28

리액트같은 컴포넌트 기반 도구를 사용할 때 CSS를 JS안에 포함(CSS-in-JS)시키는 도구를 많이 사용한다. CSS를 JS 안에 작성하면 컴포넌트 파일을 하나로 유지하면서 기능과 스타일을 같이 관리할 수 있어서 선호하는 사람이 많다. CSS가 JS안에 포함된 경우와 별도의 파일로 분리된 경우의 성능을 비교를 한 글(Real-world CSS vs. CSS-in-JS performance comparison)을 봤다.

결론부터 얘기하자면 원 글에도 나와 있듯이 결국 JS의 크기를 줄이는 것이 성능에 유리하고 결과적으로 CSS는 별도로 분리하는 것이 더 좋다. 여러 비교 수치가 나와 있는데 대부분은 그 차이가 크지 않아서 정말로 파일 크기 줄어든 만큼의 성능 향상 효과가 있는가 싶었는데 가장 마지막에 있는 수치는 좀 주목을 끌었다. 특정 사용자 인터랙션 블로킹 시간이 1862ms와 994ms로 거의 두 배 가까이 차이가 나고 그 차이도 0.9초 정도로 상당히 크다. 그렇지 않아도 JS 번들은 점점 비대해지는데 CSS를 뽑아 내는 것만으로도 상당한 성능 개선이 된다면 안 할 이유가 없다.

그렇다고 JS 파일에서 CSS 코드를 다 없애야 만 하는 것은 아니다. 원 글에서 한 것 처럼 스타일드 컴포넌트(Styled Components)를 르내리아(Linaria)로 교체하고 빌드할 때 CSS를 뽑아내면 된다. 글 마지막에 vanilla-extract페이스북 스타일링 라이브러리도 소개되어 있으니 살펴보면 좋을 것 같다.

스벨트(Svelte)는 빌드할 때 CSS를 분리해서 별도 파일로 만들어 주기 때문에 성능 저하를 피할 수 있다. 뷰(Vue)도 스벨트 처럼 표준 스타일 문법을 써서 같은 방식인가 살펴보니 뷰는 별도의 CSS 파일을 생성해 주지 않고 컴포넌트 별로 헤드 요소에 스타일을 집어 넣는 방식이다. 스벨트에서 CSS 방출을 안하게 설정(emitCss: false)한 것과 동일해 보인다. 점점 뷰를 쓸 이유는 없어지는 듯 하다.

Comments

Post a comment

:

: 공개 되지 않습니다. Gravatar를 표시 합니다.

:

: HTML 태그를 사용할 수 없습니다.