software

Tailwind가 실제로 느린가요?

발행: (2025년 12월 7일 오후 03:00 GMT+9)
8 min read
원문: Dev.to

Source: Dev.to

Tailwind는 많은 개발자들의 마음을 사로잡았을 뿐만 아니라 동시에 많은 사람들에게 가장 혐오받는 CSS 프레임워크가 되었습니다. 사람들은 다양한 이유로 Tailwind를 사랑하고 미워하지만, 오늘은 Tailwind CSS 성능에 대해 이야기하고자 합니다. 일부 회의적인 개발자들은 Tailwind가 로딩 및 렌더링 시간을 악화시킬 수 있다고 믿습니다. 과연 그렇습니까?

이 글에서는 다음과 같은 주장들을 다룹니다:

  • “Tailwind가 렌더링 시간을 악화시킬 수 있다.” – 원자형 CSS 클래스가 너무 많으면 CPU 부하가 추가될 수 있다.
  • “Tailwind가 로딩 시간을 악화시킬 수 있다.” – 지연 로딩에 효율적이지 않다.
  • “Tailwind가 웹사이트 캐시를 악화시킬 수 있다.”
    • Tailwind를 사용할 경우 생성된 HTML 파일 크기가 보통 더 커진다.
    • 생성된 CSS가 BEM이나 CSS Modules에 비해 캐시를 더 자주 리셋할 수 있다.

간단한 주석: Tailwind에 귀속된 일부 문제는 실제로 원자형 스타일링 접근 방식의 문제입니다. Tailwind는 컴포넌트를 만들 수 있게 해 주며(비원자형 스타일링), 많은 개발자들이 Tailwind를 순수하게 원자형 스타일링에만 사용합니다. 이 토론의 초점은 바로 그 부분입니다.

Tailwind가 렌더링 시간을 악화시킬 수 있다

왜 일부 개발자들은 이렇게 생각할까?

일반적인 이해는 페이지에 CSS 선언이 많을수록 브라우저가 이를 처리하는 속도가 느려진다는 것입니다. 원자형 스타일링 접근 방식에서는 대부분의 선언이 1–3개의 CSS 규칙만을 포함하므로, 개발자들은 상대적으로 많은 클래스를 사용하게 됩니다.

예를 들어, Flexbox를 사용해 “div를 중앙에 배치”하려면 세 개의 Tailwind 클래스를 사용합니다:

<!-- Example placeholder -->
<div class="flex items-center justify-center">
  …
</div>

각 클래스는 별도의 스타일 선언을 생성합니다. 비원자형 접근 방식(예: CSS Modules 또는 BEM)에서는 이러한 규칙들을 하나의 선택자로 결합할 수 있습니다.

벤치마크

주장을 검증하기 위해 벤치마크를 설정했습니다.

TailwindCSS Modules
컴포넌트~5 000~5 000
전체 DOM 노드~20 000~20 000
CSS 파일 크기1.4 MB1.4 MB
스타일 선언35 K10 K

샘플 컴포넌트

// Tailwind component (class names differ per component)
<header className="flex gap-[0.0px]">
  {/* … */}
  <h2>Heading</h2>
</header>
// CSS Modules component (unique class name per component)
<header className={styles.header}>
  {/* … */}
  <h2>Heading 0</h2>
</header>
/* CSS Modules generated rules (repeat Tailwind styling) */
.egTxNhojHMGgAu4egvUQ { /* … */ }
.egTxNhojHMGgAu4egvUQ > header { /* … */ }

결과 (다운로드 후 파싱/렌더링만)

Benchmark chart

브라우저TailwindCSS Modules차이
Chrome169 ms121 ms+28 %
Safari406 ms272 ms+33 %
Firefox114 ms82 ms+25 %

스타일 선언 수가 많아지면 렌더링 시간이 증가한다는 것을 확인할 수 있습니다.

HTML 크기가 영향을 미칠까?

Tailwind의 클래스 목록은 길어 HTML 크기가 커집니다(≈ 1.1 MB vs. 0.4 MB). 효과를 분리하기 위해 CSS Modules의 클래스 이름을 Tailwind와 동일한 HTML 크기로 패딩했습니다:

<header className="flex gap-[0.0px]">
  …
</header>

HTML 크기가 동일해도 CSS Modules 파일은 2.7 MB( Tailwind는 1.4 MB)로 늘어났지만, Tailwind가 여전히 더 빠른 결과를 보였습니다. 클래스 이름 길이가 추가하는 지연은 몇 밀리초에 불과하며, 주요 요인은 CSS 선언 수입니다.

정리

  • 원자형 접근 방식 자체가 문제는 아니다; 고유 선언이 지나치게 많아지는 것이 문제다.
  • 일반적인 패턴(mt-1, mt-2, mt-4 등)에는 Tailwind 유틸리티 클래스를 활용한다.
  • 필요하지 않은 경우 임의값(mt-[7px], [&>header]:flex)을 많이 생성하지 않는다. 이러한 임의값은 고유 선택자를 만들고 스타일시트를 부풀려 성능을 저하시킨다.

📌 Tailwind와 원자형 접근 방식을 사용할 때 렌더링 성능에 부정적인 영향을 줄 수 있지만, 이는 많은 고유하고 임의적인 클래스 이름을 남용할 때만 해당됩니다.

Tailwind가 로딩 시간을 악화시킬 수 있다

Tailwind는 지연 로딩에 의존하지 않습니다. 페이지가 지연 로드되고 스타일이 Tailwind로 선언된 경우, 해당 스타일 전체가 초기 로드 CSS 파일에 포함됩니다. 따라서 100개의 지연 로드 페이지가 있다면, 100개의 페이지에 대한 스타일이 모두 초기 CSS 페이로드에 번들링되어 브라우저가 렌더링 전에 다운로드해야 할 CSS 양이 증가합니다.

이를 완화하기 위해 다음을 고려하세요:

  • 사용되지 않는 유틸리티 제거(예: Tailwind의 purge/content 옵션 사용)하여 초기 뷰에 실제로 사용되는 클래스만 포함한다.
  • 라우트별 CSS 번들링(webpack, Vite, Next.js 내장 CSS 코드 스플리팅 등)으로 CSS를 분할한다.
  • 컴포넌트 추출(@apply 또는 커스텀 컴포넌트)으로 고유 유틸리티 클래스 수를 줄인다.

Tailwind의 빌드 파이프라인을 신중하게 구성하면 초기 CSS 페이로드를 작게 유지하고 불필요한 로딩 오버헤드를 피할 수 있습니다.

Back to Blog

관련 글

더 보기 »