얼마 전에 웹 사이트의 로딩 시간을 개선하기로 결정했습니다. 이미 꽤 빨리 로드 되지만 개선의 여지가 있고 그중 하나가 CSS로드 라는 것을 알고 있었습니다. 프로세스를 안내하고 로드 시간을 개선 할 수 있는 방법도 보여 드리겠습니다.
https://pustelto.com/blog/optimizing-css-for-faster-page-loads/
로딩 시간이 중요한 이유는 무엇입니까?
시간은 돈이기 때문입니다. 이 속담은 특히 웹 페이지 로드 시간에 해당됩니다. 페이지 로드 시간은 수익에 직접적인 영향을 미칩니다. 사람들은 느린 전자 상점보다 빠른 전자 상점에서 무언가를 구매할 가능성이 더 높습니다. 연구에 따르면 Milliseconds는 모바일 사이트에서 수백만 개가 0.1 초씩 개선되어 여행 사이트에서 전환이 10.1 %, 주문 가치가 1.9 % 증가했습니다. 그것은 많은 돈이 될 수 있습니다.
따라서 수익성 있는 비즈니스를 구축하려면 페이지 로드 시간을 과소 평가해서는 안됩니다.
참고 :이 패턴을 확인하는 더 많은 연구가 있습니다. 내가 찾을 수 있는 가장 최근의 연구이기 때문에 위에서 언급 한 연구의 예를 사용했습니다.
CSS가 로드 시간에 미치는 영향
CSS가 웹 페이지 로드 시간에 어떤 영향을 미치는지 확인하려면 먼저 브라우저가 HTML 문서를 기능적인 웹 페이지로 변환하는 방법을 알아야 합니다.
먼저 HTML 문서를 다운로드하고 파싱하여 DOM (Document Object Model)을 만들어야 합니다. 외부 리소스 (CSS, JS, 이미지 등)를 만날 때마다 다운로드 우선 순위를 할당하고 다운로드를 시작합니다. 일부 리소스는 페이지를 렌더링 하는 데 중요하지만 (예 : 기본 스타일 시트 및 JS 파일) 다른 리소스는 덜 중요 할 수 있으므로 (다른 미디어 유형의 이미지 또는 스타일 시트) 우선 순위가 중요합니다.
HTTP / 1.1은 또한 한 도메인 당 연결 수에 대한 엄격한 제한이 있습니다 (정확한 수는 브라우저에 따라 다르며 요즘에는 보통 6 개입니다). 따라서 한 도메인에서 많은 수의 리소스를 다운로드하려면 우선 순위가 더 높은 리소스의 다운로드가 완료 될 때까지 일부 리소스가 대기열에서 기다려야 합니다. 따라서 HTTP / 1.1을 사용할 때는 요청 수를 적게 유지하십시오. HTTP / 2에는 이러한 제한이 없지만 지금까지 모든 사이트가 HTTP / 2를 사용하는 것은 아닙니다.
CSS의 경우 CSSOM (CSS Object Model)을 만드는 데 스타일 시트가 필요하기 때문에 일반적으로 이 우선 순위가 높습니다. 웹 페이지 브라우저를 렌더링 하려면 DOM과 CSSOM을 모두 구성해야 합니다. 이러한 브라우저가 없으면 화면에 픽셀을 렌더링 하지 않습니다. 그 이유는 스타일이 페이지의 모양을 정의하고 먼저 페이지를 렌더링 하지 않으면 처리 능력과 나쁜 사용자 경험을 낭비하기 때문입니다. 브라우저에서 DOM과 CSSOM을 모두 사용할 수 있는 경우에만 이를 결합하여 렌더링 트리를 만들고 화면 렌더링을 시작할 수 있습니다. 간단히 말해 CSS가 다운로드 되지 않고 페이지가 렌더링 되지 않습니다.
보시다시피 CSS는 웹 페이지 로드 시간에 큰 영향을 미칩니다. CSS에 대해 이야기 할 때 웹 페이지 로드 시간에 영향을 미치는 두 가지 기본 영역이 있습니다.
이를 개선 할 수 있는 방법을 자세히 살펴 보겠습니다.
스타일 시트 크기 제한
TLDR : 가능할 때마다 최신 코드를 사용하도록 도구를 올바르게 구성하십시오.
로드 시간을 단축하려면 CSS 파일을 더 작게 만드는 것이 좋습니다. 요즘에는 일부 도구를 사용하여 빌드시 CSS (포스트 프로세서 또는 PostCSS)를 수정하여 이전 브라우저 또는 기타 개선 사항에 대한 대체 기능을 제공하는 것이 일반적입니다.
불필요한 팽창에 대한 결과 코드를 확인하는 것이 좋습니다. 특히 여러 플러그인과 함께 PostCSS를 사용하는 경우. 제 경우에는 CSS 변수에 대해 생성 된 폴 백과 이전 flexbox 구문에 대한 접두사가 있는 CSS가 있었습니다. 효과가 거의 없는 사소한 문제처럼 보일 수 있지만 결과적으로 저와 같은 작은 스타일 시트의 경우 약 3KB가 절약되었습니다. 나는 그것이 아주 적은 작업에 대한 큰 개선이라고 생각합니다. 그리고 큰 CSS의 경우 더 큰 영향을 미칠 가능성이 있습니다.
old index.css: 12.5kB (without GZip)
new index.css: 9.2kB (without GZip, ~26.4% smaller)내가 해야 할 일은 Autoprefixer 및 기타 유사한 도구에서 특정 브라우저 버전에 대해 생성 된 코드를 대상으로 하는 브라우저 목록 구성을 업데이트하는 것 뿐이었습니다. PostCSS 구성도 약간 업데이트했습니다. (또한 추가 공간을 절약하기 위해 미디어 쿼리를 함께 연결하는 플러그인을 추가했습니다). 정확한 설정을 보려면 소스 코드의 PostCSS 구성과 내 브라우저 목록 정의를 참조하십시오.
중요한 CSS 사용
그래서 우리는 CSS 파일을 축소했지만 여전히 다운로드 해야 합니다. 네트워크 요청을 줄여 웹 페이지 로드 시간을 단축 할 수 있습니다. 그리고 최상의 네트워크 요청은 전혀 요청이 없습니다. 외부 스타일 시트를 다운로드 할 필요가 없으므로 시간을 절약하기 위해 스타일을 HTML에 직접 인라인 할 수 있습니다.
물론 모든 페이지에 전체 9kb 스타일 시트 (또는 더 큰 프로젝트의 경우 큰)를 포함하는 것은 그다지 효과적이지 않습니다. 따라서 접힌 부분 위에 페이지 부분을 렌더링하고 나머지 스타일은 지연로드 하는 데 필요한 스타일 만 포함합니다. 이렇게 하면 다른 페이지에 대한 브라우저 캐싱을 계속 활용하고 웹 페이지를 더 빠르게 로드 할 수 있습니다. 페이지 렌더링에 중요한 스타일을 포함하기 때문에 이 기술을 Critical CSS라고 합니다.
다행히 HTML에 어떤 스타일을 포함할지 결정할 필요가 없습니다. Addy Osmani의 Critical과 같은 일부 도구가 이를 수행합니다. 이 기술은 타협에 관한 것임을 명심하십시오. 이 기술은 페이지를 로드 할 때 하나의 요청을 저장하지만 각 페이지를 더 크게 만들어서 다운로드 시간이 길어 지므로 포함 할 내용과 CSS 크기 사이의 적절한 균형을 찾아야 합니다. 따라서 이를 실험하고 결과를 측정하여 사이트에 가장 적합한 설정을 찾고 싶습니다.
지연로드 스타일 시트
Critical CSS를 사용하기 때문에 페이지 렌더링을 차단하지 않도록 스타일 시트를 지연로드 하려고 합니다. 일부 오래된 브라우저를 지원할 필요가 없는 한, 요즘 최신 솔루션은 스타일 시트에 사용하는 일반 링크 태그를 사용하지만 미디어 유형이 다르고 JS가 약간 있습니다. 이 영리한 트릭은 Filament Group 블로그 게시물에 자세히 설명되어 있습니다. 아래에서 게시물에서 CSS 지연 로딩에 대한 스니펫을 볼 수 있지만 전체 내용을 읽는 것이 좋습니다.
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">참고 : 위의 Critical 패키지를 사용하면 스타일 시트가 자동으로 지연로드 되도록 변환됩니다.
JS가 비활성화 된 경우 대체를 포함 할 수 있습니다. 이렇게 하면 스타일이 정상적으로 로드 되고 사용자 경험에 나쁜 영향을 미치는 스타일이 지정되지 않은 콘텐츠를 피할 수 있습니다.
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
<noscript>
<link rel="stylesheet" href="/path/to/my.css" media="screen">
</noscript>아래의 폭포 다이어그램에서 중요한 CSS가있는 페이지는 즉시 렌더링을 시작하고 (브라우저 주 스레드 행의 그래프의 보라색 부분) CSS 파일을 먼저 다운로드 해야 하는 이전 버전에 비해 훨씬 더 빠르게 상호 작용하는 것을 볼 수 있습니다.
중요한 CSS가 없는 프로젝트 페이지의 폭포 차트.
중요한 CSS가 있는 프로젝트 페이지의 폭포 차트.
스타일 시트에 코드 분할 사용
최신 브라우저에 필요한 속성이 있는 CSS가 있으며 중요한 CSS를 사용하고 나머지는 지연로드 합니다. 하지만 파일 크기를 조금 더 줄일 수 있습니다. Chrome 개발 도구에는 Coverage라는 도구가 있습니다. 현재 페이지에서 사용되는 CSS 및 JS 파일 부분을 보여줄 수 있습니다. 개발 도구를 열고 Ctrl + Shift + p를 눌러 명령 팔레트를 열고 Coverage를 입력합니다. 패널을 표시하려면 범위 표시 옵션을 선택합니다. 이제 페이지를 다시 로드 하십시오.
내 CSS 코드의 거의 50 %가 페이지에서 사용되지 않았습니다. 다른 페이지를 확인하면 사용하지 않은 CSS의 거의 54 %를 더 많이 얻을 수 있습니다. 많은 불필요한 코드입니다. 이 수치는 대규모 레거시 앱에서 더 클 수 있습니다.
JS를 사용할 때 우리는 종종 코드 분할을 사용하여 여러 개의 작은 파일 (번들)을 만듭니다. 페이지 로드시 하나의 큰 JS 번들을 가져 오는 대신 필요할 때 해당 번들을 다운로드합니다. CSS에도 비슷한 접근 방식을 사용할 수 있습니다. CSS를 세 가지 방법으로 나눌 수 있습니다.
미디어 쿼리를 기반으로 CSS 분할
이 접근 방식에서는 미디어 쿼리를 기반으로 큰 CSS를 더 작은 스타일 시트로 분할하고 (PostCSS에는 플러그인이 있음) HTML에서 해당 스타일 시트를 참조합니다.
<link rel="stylesheet" href="index.css" media="all" />
<link rel="stylesheet" href="mobile.css" media="(max-width:44.9375rem)" />
<link rel="stylesheet" href="table.css" media="(min-width: 45rem)" />이 방법은 Critical CSS를 사용하고 스타일 시트를 지연 로드 할 때 별로 의미가 없습니다. 브라우저는 사용되는 미디어 쿼리에 관계없이 모든 스타일 시트를 다운로드합니다. 미디어 속성 만 사용하여 다운로드 우선 순위를 지정합니다. 따라서 기본적으로 활성 미디어 쿼리에 대해 우선 순위가 높은 CSS를 다운로드하고 나머지 스타일 시트를 지연로드 합니다.
페이지 기반 코드 분할
또 다른 접근 방식은 각 페이지에 대해 별도의 CSS를 사용하는 것입니다. 위에서 살펴본 것처럼 다른 페이지에 사용되지 않는 스타일이 많이 있습니다. 사용하지 않는 스타일을 제거하고 주어진 페이지에 필요한 것만 유지할 수 있다면 좋을 것입니다. 이것이 제가 하기로 선택한 것입니다. 안타깝게도 이 작업을 수행하는 도구를 찾을 수 없습니다. 하나의 큰 CSS 파일을 가져 와서 해당 콘텐츠를 기반으로 각 페이지에 대해 더 작은 번들을 생성합니다.
꽤 간단하게 들리기 때문에 저는 이것을 시도하고 이런 종류의 일을 할 수 있는 노드 스크립트를 만들기로 결정했습니다. CSS Split이라고 하며 정적 사이트 생성기를 사용하여 구축 한 사이트 (예 : 내 사이트에 사용하는 Eleventy)에 적합합니다. PurgeCSS를 사용하여 사용되지 않는 스타일을 제거하므로 다른 비 HTML 파일에서도 작동합니다 (문서에 따라). HTML 이외의 다른 항목에 대해서는 테스트하지 않았으므로 이런 방식으로 사용할 때는 결과를 다시 확인해야 합니다.
이 기술을 사용하여 요청 된 CSS의 파일 크기를 거의 50% 줄일 수 있었습니다. 다음은 Critical CSS 및 페이지 기반 코드 분할을 구현 한 후의 몇 가지 통계입니다.
single index.css for all pages: 9.2kB (without GZip)
CSS file for homepage: 5.4kB (without GZip)
CSS file for projects: 4.4kB (without GZip)
아직 사용되지 않은 바이트가 있음을 알 수 있습니다. Coverage에는 마우스 오버 또는 포커스 상태 또는 쿼리가 포함되지 않으므로 괜찮습니다. 사용하지 않은 바이트를 0으로 만들 가능성은 거의 없습니다.
구성 요소 기반 코드 분할
해리 로버츠로부터 이 팁을 받았습니다. 또한 구성 요소별로 CSS를 분할하고 페이지에서 사용하는 구성 요소 (바닥 글, 머리글, 기사 등)에 대해서만 점진적으로 CSS를로드 할 수 있습니다. 이 깔끔한 트릭에 대한 자세한 내용은 Harry의 기사에서 읽을 수 있습니다. 이 기술은 기사의 마지막 섹션에 설명되어 있습니다. 그러나 전체 기사를 읽으십시오. 여기에서 다루지 않은 CSS 네트워크 성능 향상에 대한 훌륭한 정보로 가득 차 있습니다 (어쨌든 더 잘 쓸 수는 없었습니다).
현재 설정과 비교하여 얼마나 잘 작동하는지 확인하기 위해 이 기술을 테스트하지는 않았지만 할 일 목록에 있습니다. 그러니 앞으로의 기사를 기대해주세요.
요약
내 사이트는 상당히 단순하고 개선 할 여지가 많지 않지만 여기에 언급 된 기술을 사용하여 웹 페이지의 초기 로드 속도를 높이고 자산의 총 크기를 줄일 수 있었습니다. 모든 웹 페이지에 동일한 프로세스를 사용하여 로드 성능을 개선 할 수 있습니다 (대규모 프로젝트의 경우 더 나은 결과를 얻을 수 있음).
아래에서 업데이트 후 몇 가지 최종 결과를 볼 수 있습니다. 그래프는 페이지의 몇 퍼센트가 언제 렌더링 되었는지 보여줍니다. 이러한 테스트는 느린 3G 연결에서 실행되었으므로 페이지를 로드 하는 데 시간이 오래 걸립니다.
홈페이지 – 최종 비교
Projects page – final comparison
Single article – final comparison
등록된 댓글이 없습니다.
