CSS 리팩토링: 크기 및 성능 최적화(3부)

이 시리즈의 이전 기사에서 CSS 코드베이스 상태 감사와 점진적 CSS 리팩토링 전략, 테스트 및 유지 관리에 대해 다루었습니다. 리팩토링 프로세스 동안 CSS 코드베이스가 얼마나 개선되었고 유지 관리 및 확장이 가능했는지에 관계없이 최종 스타일시트는 가능한 최고의 성능과 가능한 최소 파일 크기를 위해 최적화되어야 합니다.

리팩토링된 코드베이스를 배포해도 웹사이트 성능이 저하되고 사용자 경험이 나빠져서는 안 됩니다. 결국 사용자는 웹 사이트가 로드될 때까지 영원히 기다리지 않을 것입니다. 또한 경영진은 코드 품질 향상에도 불구하고 최적화되지 않은 코드베이스로 인한 트래픽 감소 및 수익 감소에 불만을 가질 것입니다.

이 기사에서는 CSS 파일 크기, 로딩 시간, 렌더링 성능을 최적화할 수 있는 CSS 최적화 전략 을 다룰 것입니다. 그렇게 하면 리팩토링된 CSS 코드베이스가 유지 관리 및 확장 가능해질 뿐만 아니라 성능이 향상되고 최종 사용자와 관리 모두에게 중요한 모든 상자를 확인할 수 있습니다.

스타일시트 파일 크기 최적화

파일 크기 최적화는 불필요한 문자를 제거하고 CSS 코드를 최적화하여 다른 구문이나 약식 속성을 사용하여 파일의 전체 문자 수를 줄이는 것으로 요약됩니다.

최적화 및 최소화

CSS 최적화 및 최소화 는 수년간 사용되어 왔으며 프론트엔드 최적화의 필수 요소가 되었습니다. cssnano 및 clean-css와 같은 도구는 CSS 최적화 및 축소와 관련하여 제가 가장 좋아하는 도구 중 하나입니다. 코드 최적화 방법과 지원되는 브라우저를 추가로 제어하기 위해 다양한 사용자 지정 옵션을 제공합니다.

이러한 도구는 유사한 방식으로 작동합니다. 먼저 최적화되지 않은 코드는 구성에 설정된 규칙에 따라 구문 분석되고 변환됩니다. 결과는 더 적은 수의 문자 를 사용하지만 여전히 서식(줄 바꿈 및 공백)을 유지하는 코드입니다.

 /* Before - original and unoptimized code */ .container { padding: 24px 16px 24px 16px; background: #222222; } /* After - optimized code with formatting */ .container { padding: 24px 16px; background: #222; }

마지막으로 불필요한 텍스트 서식을 모두 제거하여 트랜스파일된 최적화된 코드를 축소합니다 . 구성에 설정된 코드베이스 및 지원되는 브라우저에 따라 더 이상 사용되지 않는 공급업체 접두사가 있는 코드도 제거될 수 있습니다.

 /* Before - optimized code with formatting */ .container { padding: 24px 16px; background: #222; } /* After - optimized and minified code */ .container{padding:24px 16px;background:#222}

이 기본 예에서도 전체 파일 크기를 76바이트에서 55바이트로 줄여 23% 줄였습니다. 코드베이스와 최적화 도구 및 구성에 따라 CSS 최적화 및 축소가 훨씬 더 효과적일 수 있습니다.

CSS 최적화 및 축소는 CSS 워크플로를 약간만 조정하면 상당한 보상을 받을 수 있으므로 쉽게 승리 할 수 있는 것으로 간주할 수 있습니다. 이것이 바로 축소가 프로젝트의 모든 스타일시트에 대한 최소한 의 성능 최적화 및 요구 사항으로 취급되어야 하는 이유입니다.

미디어 쿼리 최적화

CSS로 미디어 쿼리를 작성할 때, 특히 여러 파일(PostCSS 또는 Sass)을 사용할 때 일반적으로 전체 프로젝트에 대한 단일 미디어 쿼리 아래에 코드를 중첩하지 않습니다. 개선된 유지 관리, 모듈성 및 코드 구조를 위해 일반적으로 여러 CSS 구성 요소에 대해 동일한 미디어 쿼리 표현식을 작성합니다.

최적화되지 않은 CSS 코드베이스의 다음 예를 살펴보겠습니다.

 .page { display: grid; grid-gap: 16px; } @media (min-width: 768px) { .page { grid-template-columns: 268px auto; grid-gap: 24px; } } /* ... */ .products-grid { display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 16px; } @media (min-width: 768px) { .products-grid { grid-template-columns: repeat(3, 1fr); grid-gap: 20px; } }

보시다시피 더 나은 가독성과 유지 관리를 위해 구성 요소당 반복되는 @media (min-width: 768px) 가 있습니다. 이 코드 예제에서 최적화 및 축소를 실행하고 결과를 살펴보겠습니다.

 .page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns:268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){.products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

이것은 읽기가 조금 어려울 수 있지만 우리가 주목해야 할 것은 반복되는 @media (min-width: 768px) 미디어 쿼리입니다. 우리는 이미 스타일시트의 문자 수를 줄이고 단일 미디어 쿼리 아래에 여러 선택기를 중첩할 수 있다는 결론을 내렸습니다. 그런데 축소자가 중복된 표현식을 제거하지 않은 이유는 무엇입니까? 거기에는 간단한 이유가 있습니다.

CSS에서는 규칙 순서가 중요 하므로 중복된 미디어 쿼리를 병합하려면 코드 블록을 이동해야 합니다. 이로 인해 규칙 순서가 변경되어 스타일에 원치 않는 부작용이 발생할 수 있습니다.

그러나 미디어 쿼리를 결합하면 코드베이스 및 구조에 따라 파일 크기가 더 작아질 수 있습니다. postcss-sort-media-queries와 같은 도구 및 패키지를 사용하면 중복된 미디어 쿼리를 제거하고 파일 크기를 더욱 줄일 수 있습니다.

물론 규칙 순서에 의존하지 않는 잘 구조화된 CSS 코드베이스 구조 를 가져야 한다는 중요한 경고가 있습니다. CSS 리팩터링을 계획하고 기본 규칙을 설정할 때 이 최적화를 고려해야 합니다.

최적화의 이점이 잠재적인 위험을 능가하는지 먼저 확인하는 것이 좋습니다. 이것은 CSS 감사를 실행하고 미디어 쿼리 통계를 확인하여 쉽게 수행할 수 있습니다. 그렇다면 나중에 추가하고 자동 회귀 테스트를 실행하여 결과적으로 발생할 수 있는 예기치 않은 부작용과 버그를 잡는 것이 좋습니다.

사용하지 않는 CSS 제거

리팩토링 프로세스 중에 완전히 제거되지 않은 사용되지 않은 레거시 스타일 이 남거나 사용되지 않는 새로 추가된 스타일이 있을 가능성이 항상 있습니다. 이러한 스타일은 전체 문자 수와 파일 크기에도 추가됩니다. 그러나 자동화된 도구를 사용하여 이러한 사용되지 않는 스타일을 제거하는 것은 도구가 실제로 사용되는 스타일을 정확하게 예측할 수 없기 때문에 다소 위험할 수 있습니다.

purgecss와 같은 도구는 프로젝트의 모든 파일을 살펴보고 파일에 언급된 모든 클래스를 선택기로 사용합니다. 다른 잠재적인 경우 중에서도 주의를 기울이고 JavaScript가 삽입된 동적 요소에 대한 선택기를 실수로 삭제하지 않기 위해서입니다. 그러나 purgecss는 이러한 잠재적인 문제와 위험에 대한 해결 방법으로 유연한 구성 옵션을 제공합니다.

그러나 이러한 개선은 잠재적인 이점이 위험을 능가하는 경우에만 수행되어야 합니다. 또한 이 최적화 기술은 설정, 구성 및 테스트하는 데 상당한 시간이 필요하며 의도하지 않은 문제가 발생할 수 있으므로 주의하여 진행하고 설정이 방탄인지 확인하십시오.

렌더링 차단 CSS 제거

기본적으로 CSS는 렌더링 차단 리소스입니다. 즉, 연결된 모든 스타일시트와 해당 종속성(예: 글꼴)이 브라우저에서 다운로드되고 구문 분석될 때까지 웹 사이트가 사용자에게 표시되지 않습니다 .

스타일시트 파일의 파일 크기가 크거나 타사 서버 또는 CDN에 있는 여러 종속성이 있는 경우 네트워크 속도 및 안정성에 따라 웹 사이트 렌더링이 크게 지연될 수 있습니다.

LCP( Large Contentful Paint )는 지난 몇 개월 동안 중요한 지표가 되었습니다. LCP는 성능뿐만 아니라 SEO에도 중요합니다. LCP 점수가 더 좋은 웹사이트는 검색 결과 순위가 더 좋습니다. CSS와 같은 렌더링 차단 리소스를 제거하는 것은 LCP 점수를 향상시키는 한 가지 방법입니다.

그러나 스타일시트 로드 및 처리를 연기하면 FOUC( Flash Of Unstyled Content )가 발생합니다. 콘텐츠가 사용자에게 즉시 표시되고 스타일이 로드되어 잠시 후 적용됩니다. 이 스위치는 이상하게 보일 수 있으며 일부 사용자에게 혼란을 줄 수도 있습니다.

중요한 CSS

Critical CSS를 사용하면 웹사이트가 처음 렌더링될 때 페이지에서 사용되도록 보장되는 최소한의 스타일로 웹사이트가 로드 되도록 할 수 있습니다. 이런 식으로 FOUC를 훨씬 덜 눈에 띄게 만들거나 대부분의 경우 제거할 수 있습니다. 예를 들어 홈페이지에 탐색이 포함된 헤더 구성 요소와 스크롤 없이 볼 수 있는 부분에 영웅 구성 요소가 있는 경우 중요한 CSS에는 이러한 구성 요소에 필요한 모든 전역 및 구성 요소 스타일이 포함되고 페이지의 다른 구성 요소에 대한 스타일은 포함됩니다. 연기됩니다.

이 CSS는 style 태그 아래 HTML에 인라인되어 있으므로 스타일이 HTML 파일과 함께 로드되고 구문 분석됩니다. 이렇게 하면 HTML 파일 크기가 약간 더 커지지 만(축소해야 함) 다른 모든 중요하지 않은 CSS는 지연되고 즉시 로드되지 않으며 웹 사이트가 더 빠르게 렌더링됩니다. 대체로 HTML 파일 크기의 증가보다 이점이 더 큽니다.

 <head> <style type="text/css"><!-- Minified Critical CSS markup --></style> </head>

설정에 따라 중요한 CSS를 추출하고 지연된 스타일시트를 생성할 수 있는 자동화된 도구와 NPM 패키지가 많이 있습니다.

스타일시트 연기

CSS를 non-blocking으로 만들려면 어떻게 해야 할까요? 페이지 HTML이 처음 다운로드될 때 HTML head 요소에서 참조되어서는 안 된다는 것을 알고 있습니다. Demian Renzulli는 그의 기사에서 이 방법을 설명했습니다.

렌더링 차단 리소스의 로드를 최적화하거나 지연하는 기본 HTML 접근 방식 은 아직 없으므로 초기 렌더링 후에 중요하지 않은 스타일시트를 HTML 마크업에 삽입하려면 JavaScript를 사용해야 합니다. 또한 사용자가 브라우저에서 JavaScript가 활성화되지 않은 페이지를 방문하는 경우 이러한 스타일이 최적이 아닌(렌더링 차단) 방식으로 로드되는지 확인해야 합니다.

 <!-- Deferred stylesheet --> <link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'"> <!-- Fallback --> <noscript> <link rel="stylesheet" href="path/to/stylesheet.css"> </noscript>

link rel="preload" as="style" 를 사용하면 스타일시트 파일이 비동기식으로 요청되는 반면 onload JavaScript 핸들러는 HTML 문서 로드가 완료된 후 브라우저에서 파일을 로드하고 처리합니다. 약간의 정리가 필요하므로 이 함수가 여러 번 실행되고 불필요한 재렌더링이 발생하지 않도록 onload 를 null 로 설정해야 합니다.

이것이 바로 Smashing Magazine이 스타일시트를 처리하는 방식입니다. 각 템플릿(홈페이지, 기사 카테고리, 기사 페이지 등)에는 head 요소의 HTML style 태그 내부에 인라인된 템플릿별 중요한 CSS 와 중요하지 않은 모든 스타일을 포함하는 지연된 main.css 스타일시트 가 있습니다.

그러나 rel 매개변수를 토글하는 대신 페이지 로드가 완료되면 미디어 쿼리가 자동으로 지연된 낮은 우선순위 print 미디어에서 높은 우선순위 all 속성으로 전환되는 것을 볼 수 있습니다. 이것은 중요하지 않은 스타일시트의 로드를 연기하기 위한 동등하게 실행 가능한 대안입니다.

 <link href="/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

미디어 쿼리로 스타일시트 분할 및 조건부 로드

앞서 언급한 최적화를 적용한 후에도 최종 스타일시트 파일의 파일 크기가 큰 경우 미디어 쿼리를 기반으로 스타일시트를 여러 파일로 분할 하고 링크 HTML 요소에서 참조하는 스타일시트의 미디어 속성을 사용하여 조건부로 로드할 수 있습니다. .

 <link href="print.css" rel="stylesheet" media="print"> <link href="mobile.css" rel="stylesheet" media="all"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)"> <link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

그렇게 하면 모바일 우선 접근 방식이 사용되는 경우 더 느리거나 신뢰할 수 없는 네트워크에서 실행될 수 있는 모바일 장치에서 더 큰 화면 크기에 대한 스타일이 다운로드되거나 구문 분석되지 않습니다.

다시 말하지만, 이전에 언급한 최적화 방법의 결과로 파일 크기가 최적이 아닌 스타일시트가 나온 경우 이 방법을 사용해야 합니다. 일반적인 경우 이 최적화 방법은 개별 스타일시트 크기에 따라 효과가 없거나 영향력이 없습니다.

글꼴 파일 및 스타일시트 연기

글꼴 스타일시트(예: Google 글꼴 파일)를 연기하는 것도 초기 렌더링 성능에 도움이 될 수 있습니다. 스타일시트가 렌더링 차단이라는 결론을 내렸지만 스타일시트에서 참조하는 글꼴 파일도 마찬가지입니다. 글꼴 파일은 또한 초기 렌더링 성능 에 상당한 오버헤드를 추가 합니다.

글꼴 스타일시트와 글꼴 파일을 로드하는 것은 복잡한 주제이며 모든 실행 가능한 접근 방식을 설명하기 위해 완전히 새로운 기사가 ​​필요할 것입니다. 운 좋게도 Zach Leatherman은 이 멋진 종합 가이드에서 많은 실행 가능한 전략을 설명하고 각 접근 방식의 장단점을 요약했습니다. Google 글꼴을 사용하는 경우 Harry Roberts는 Google 글꼴을 가장 빠르게 로드하기 위한 전략을 설명했습니다.

글꼴 스타일시트를 연기하기로 결정하면 FOUT(Flash of Unstyled Text)이 발생합니다. 페이지는 지연된 글꼴 파일과 스타일시트가 다운로드되고 구문 분석될 때까지 대체 글꼴로 처음 렌더링되며, 이 시점에서 새 스타일이 적용됩니다. 이 변경 사항 은 매우 눈에 띌 수 있으며 개별 사례에 따라 레이아웃이 변경되고 사용자를 혼란스럽게 할 수 있습니다.

Barry Pollard는 FOUT을 처리하는 데 도움이 될 수 있는 몇 가지 전략을 설명하고 FOUT을 보다 쉽고 기본적으로 처리하는 방법을 제공할 예정인 크기 조정 CSS 기능에 대해 이야기했습니다.

서버 측 최적화

HTTP 압축

최소화 및 파일 크기 최적화 외에도 HTML, CSS 파일, JavaScript 파일 등과 같은 정적 자산. Gzip 및 Brotli와 같은 HTTP 압축 알고리즘을 사용하여 다운로드한 파일 크기를 추가로 줄일 수 있습니다.

HTTP 압축은 기술 스택 및 구성에 따라 달라지는 서버에서 구성해야 합니다. 그러나 브라우저가 여전히 압축 파일을 압축 해제하고 구문 분석해야 하므로 성능 이점은 다를 수 있으며 표준 스타일시트 축소 및 최적화만큼 많은 영향을 미치지 않을 수 있습니다.

스타일시트 캐싱

정적 파일 캐싱 은 유용한 최적화 전략입니다. 브라우저는 여전히 첫 번째 로드 시 서버에서 정적 파일을 다운로드해야 하지만 일단 캐시되면 후속 요청에서 직접 로드되어 로드 프로세스 속도가 빨라집니다.

캐싱은 서버 수준에서 Cache-Control HTTP 헤더를 통해 제어할 수 있습니다(예: Apache 서버에서 .htaccess 파일 사용).

max-age 를 사용하면 브라우저에서 파일이 캐시된 상태로 유지되어야 하는 시간(초 단위)을 나타낼 수 있고 public 을 사용하면 브라우저와 다른 캐시에서 파일을 캐시할 수 있음을 나타냅니다.

 Cache-Control: public, max-age=604800

고정 자산에 대한 보다 공격적이고 효과적인 캐시 전략은 immutable 수 없는 구성으로 달성할 수 있습니다. 이것은 이 특정 파일이 절대 변경되지 않으며 새로운 업데이트로 인해 이 파일이 삭제되고 다른 파일 이름을 가진 새 파일이 그 자리를 차지할 것임을 브라우저에 알립니다. 이를 캐시 무효화 라고 합니다.

 Cache-Control: public, max-age=604800, immutable

적절한 캐시 무효화 전략 이 없으면 사용자의 브라우저에 캐시되는 파일에 대한 제어권을 잃을 위험이 있습니다. 즉, 파일이 변경되면 브라우저는 업데이트된 파일을 다운로드해야 하고 오래된 캐시 파일을 사용하지 않아야 한다는 것을 알 수 없습니다. 그리고 그 시점부터 이 문제를 해결하기 위해 우리가 할 수 있는 일은 거의 없으며 사용자는 만료될 때까지 오래된 파일을 계속 사용하게 됩니다.

스타일시트의 경우, 새로운 스타일이 필요한 구성요소와 새로운 콘텐츠로 HTML 파일을 업데이트하는 경우 오래된 스타일시트가 캐시 무효화 전략 없이 캐시되고 브라우저가 이를 알지 못하기 때문에 이러한 스타일이 표시되지 않을 수 있음을 의미할 수 있습니다. 새 파일을 다운로드해야 합니다.

스타일시트 또는 기타 정적 파일에 대한 캐싱 전략을 사용하기 전에 오래된 정적 파일이 사용자의 캐시에 걸리는 것을 방지하기 위해 효과적인 캐시 무효화 메커니즘을 구현해야 합니다. 캐시 무효화를 위해 다음 버전 관리 메커니즘 중 하나를 사용할 수 있습니다.

• 파일 이름에 쿼리 문자열 추가.
  예를 들어 styles.css?v=1.0.1. 그러나 일부 CDN은 파일 이름에서 쿼리 문자열을 완전히 무시하거나 제거하여 파일이 사용자의 캐시에 멈춰 업데이트되지 않을 수 있습니다.
• 파일 이름 변경 또는 해시 추가.
  예: styles.a1bc2.css 또는 styles.v1.0.1.css. 이것은 파일 이름에 쿼리 문자열을 추가하는 것보다 더 안정적이고 효과적입니다.

CDN 또는 자체 호스팅?

CDN(콘텐츠 전송 네트워크)은 이미지, 비디오, HTML 파일, CSS 파일, JavaScript 파일 등과 같은 정적 자산을 안정적이고 빠르게 전달하는 데 일반적으로 사용되는 지리적으로 분산된 서버 그룹입니다.

CDN이 자체 호스팅 정적 자산에 대한 훌륭한 대안으로 보일 수 있지만 Harry Roberts는 해당 주제에 대한 심층 연구를 수행했으며 자체 호스팅 자산이 성능에 더 유익하다는 결론을 내렸습니다.

“정적 자산을 다른 사람의 인프라에 남겨둘 이유가 거의 없습니다. 인식된 이점은 종종 신화이며, 그렇지 않더라도 트레이드오프는 그만한 가치가 없습니다. 여러 출처에서 자산을 로드하는 것이 확실히 더 느립니다."

즉, 기본적으로 스타일 시트(가능한 경우 글꼴 스타일시트 포함)를 자체 호스팅하고 실행 가능한 이유나 다른 이점이 있는 경우에만 CDN으로 이동하는 것이 좋습니다.

CSS 파일 크기 및 성능 감사

WebPageTest 및 기타 유사한 성능 감사 도구를 사용하여 웹사이트 로딩 프로세스, 파일 크기, 렌더링 차단 리소스 등에 대한 자세한 개요를 얻을 수 있습니다. 이러한 도구를 사용하면 다양한 장치 에서 웹사이트가 로드되는 방식에 대한 통찰력을 얻을 수 있습니다. 고속 네트워크에서 실행되는 데스크톱 PC에서 느리고 신뢰할 수 없는 네트워크에서 실행되는 저가형 스마트폰에 이르기까지 다양합니다.

이 시리즈의 첫 번째 기사에서 언급한 웹사이트(2MB의 CSS 축소)에서 성능 감사를 수행해 보겠습니다.

먼저 콘텐츠 분석 을 살펴보고 가장 많은 대역폭을 차지하는 리소스를 결정합니다. 다음 차트에서 이미지가 대부분의 요청을 차지한다는 것을 알 수 있습니다. 즉, 지연 로드가 필요합니다. 두 번째 차트에서 파일 크기 측면에서 스타일시트와 JavaScript 파일이 가장 큰 것을 알 수 있습니다. 이는 이러한 파일을 최소화 및 최적화하거나, 리팩토링하거나, 여러 파일로 분할하고 비동기식으로 로드해야 한다는 좋은 표시입니다.

Web Vital 차트에서 더 많은 결론을 도출할 수 있습니다. LCP(Large Contentful Paint) 차트를 보면 렌더링 차단 리소스에 대한 자세한 개요와 이러한 리소스가 초기 렌더링에 미치는 영향을 확인할 수 있습니다.

우리는 이미 웹사이트 스타일시트가 LCP와 로딩 통계에 가장 큰 영향을 미칠 것이라는 결론을 내릴 수 있습니다. 그러나 글꼴 스타일시트, JavaScript 파일 및 스타일시트 내에서 참조되는 이미지도 렌더링 차단되는 것을 볼 수 있습니다. 위에서 언급한 최적화 방법을 적용하여 렌더링 차단 리소스를 제거하여 LCP 시간을 줄일 수 있음을 알고 있습니다.

결론

코드 상태 및 품질이 개선되고 코드베이스 약점 및 문제가 수정된 경우 리팩토링 프로세스가 완료되지 않습니다. 리팩토링된 코드베이스는 레거시 코드베이스와 비교하여 동일하거나 향상된 성능 을 제공해야 합니다.

최종 사용자는 리팩토링된 코드베이스에서 성능 문제나 긴 로딩 시간을 경험해서는 안 됩니다. 운 좋게도 코드베이스가 강력하고 성능이 좋은지 확인하는 방법이 많이 있습니다. 간단한 최소화 및 최적화 방법부터 렌더링 차단 리소스 및 코드 분할 제거 와 같은 보다 복잡한 방법에 이르기까지 다양합니다.

WebPageTest 와 같은 다양한 성능 감사 도구 를 사용하여 로딩 시간, 성능, 렌더링 차단 리소스 및 기타 요인에 대한 자세한 개요를 얻을 수 있으므로 이러한 문제를 조기에 효과적으로 해결할 수 있습니다.

참고문헌

• "Render Blocking CSS", Ilya Grigorik
• Demian Renzulli, "비중요 CSS 연기"
• "글꼴 로딩 전략에 대한 종합 가이드", Zach Leatherman
• "글꼴 로딩 영향을 줄이는 새로운 방법: CSS 글꼴 설명자", Barry Pollard
• "정적 자산 자체 호스팅", Harry Roberts
• "WebFont 로딩 및 렌더링 최적화", Ilya Grigorik