이 글에서는 CSS 성능 최적화를 위한 8가지 팁을 소개합니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.
우리 모두는 페이지 렌더링 및 콘텐츠 표현의 중요한 부분인 CSS가 전체 웹 사이트에 대한 사용자의 첫 경험에 영향을 미친다는 것을 알고 있습니다. 따라서 이와 관련된 성능 최적화는 무시할 수 없습니다.
우리는 프로젝트가 완료될 때만 성능 최적화를 고려하는 경우가 많으며, 프로젝트가 끝날 때까지 연기되거나 심각한 성능 문제가 노출된 경우에도 이에 대해 깊이 이해하고 있다고 믿습니다.
저자는 이런 상황을 피하기 위해서는 먼저 성능 최적화와 관련된 작업에 주목하고 이를 전체 제품 디자인 및 개발에 통합해야 한다고 믿습니다. 둘째, 프로젝트 개발 과정에서 성능 관련 내용을 이해하고 자연스럽게 성능 최적화를 수행하는 것이다. 마지막으로 가장 중요한 것은 지금 최적화를 시작하는 것입니다.
Qiwu Weekly에서 이전에 추천한 "야, 웹 성능 최적화 맵을 알려줄게" 1 기사를 읽어보는 것이 좋습니다. 이 기사는 해야 할 일과 필요한 문제에 대한 전반적인 개념을 형성하는 데 도움이 될 수 있습니다. 성능 최적화를 위해 고려됩니다
.
이 글에서는 CSS 성능 최적화와 관련된 기술을 실무와 제안의 두 가지 범주로 나누어 총 8가지 팁을 자세히 소개합니다. 실용적인 기술은 프로젝트에 빠르게 적용할 수 있으며 성능을 크게 향상시킬 수 있으며 저자도 자주 사용합니다. 가능한 한 빨리 모든 사람이 프로젝트에서 연습하는 것이 좋습니다. 제안된 기술 중 일부는 성능에 큰 영향을 미치지 않을 수도 있고, 일부는 모든 사람이 사용하지 않을 수도 있으므로 독자가 각자의 상황에 따라 중점적으로 알아보지는 않겠습니다. (동영상 공유 학습: css 동영상 튜토리얼)
공식 시작에 앞서 브라우저의 작동 원리에 대해 어느 정도 이해해야 합니다. 2. 필요한 친구는 먼저 간략하게 이해할 수 있습니다.
이제 첫 화면의 핵심 CSS부터 시작해서 실용적인 최적화 기법 4가지를 소개하겠습니다.
성능 최적화에 중요한 지표가 있습니다. - First Effective Paint(첫 번째 의미 있는 페인트, FMP라고 함)는 페이지의 기본 콘텐츠(기본 콘텐츠)를 나타냅니다. 화면에 나타납니다. 이 지표는 사용자가 페이지를 보기 전에 기다려야 하는 시간에 영향을 미치며, 인라인 크리티컬 CSS(Critical CSS, 첫 화면에서는 Critical CSS라고 부를 수 있음)가 이 시간을 줄일 수 있습니다.
모든 사람은 링크 태그를 통해 외부 CSS 파일을 참조하는 데 익숙해져야 합니다. 하지만 알아야 할 것은 CSS를 HTML 문서에 직접 인라인하면 CSS 다운로드 속도가 빨라진다는 것입니다. 외부 CSS 파일을 사용하는 경우 HTML 문서 다운로드 후 참조할 CSS 파일을 알고 다운로드해야 합니다. 따라서 인라인 CSS를 사용하면 HTML 다운로드가 완료된 후에 렌더링할 수 있으므로 브라우저가 페이지 렌더링을 더 일찍 시작하도록 할 수 있습니다.
인라인 CSS는 페이지 렌더링 시작 시간을 앞당길 수 있으므로 모든 CSS를 인라인할 수 있나요? 대답은 분명히 '아니요'입니다. 이 방법은 더 큰 CSS 파일을 인라인하는 데 적합하지 않습니다. 초기 혼잡 창 3(TCP 관련 개념, 일반적으로 14.6kB, 압축 크기)에 제한이 있으므로 인라인 CSS 이후의 파일이 이 제한을 초과하면 시스템은 서버와 브라우저 간에 더 많은 라운드를 수행해야 합니다. 여행을 하더라도 페이지 렌더링 시간이 빨라지지 않습니다. 따라서 스크롤 없이 볼 수 있는 콘텐츠를 HTML로 렌더링하는 데 필요한 중요한 CSS만 HTML에 인라인해야 합니다.
첫 번째 화면 위에 핵심 CSS를 인라인하면 성능을 최적화할 수 있다는 점을 알았으므로 다음 단계는 첫 번째 화면 위의 핵심 CSS를 결정하는 방법입니다. 분명히 중요한 CSS가 스크롤 없이 볼 수 있는 부분 위에 어떤 콘텐츠가 있는지 수동으로 결정할 필요는 없습니다. Github에는 첫 번째 화면에 속한 주요 스타일을 추출할 수 있는 Critical CSS4라는 프로젝트가 있습니다. 프로젝트를 살펴보고 자신의 빌드 도구와 함께 사용할 수 있습니다. 물론, 정확성을 위해서는 추출된 내용이 누락되었는지 직접 확인하시는 것이 가장 좋습니다.
그러나 인라인 CSS의 단점이 있습니다. 인라인 CSS는 캐시되지 않으며 매번 다시 다운로드됩니다. 하지만 위에서 언급한 것처럼 인라인 파일 크기를 14.6kb 이내로 조절한다면 큰 문제는 되지 않을 것 같습니다.
위에서 핵심 CSS를 인라인해야 하는 이유와 인라인 처리 방법을 소개했습니다. 그렇다면 나머지 CSS는 어떻게 처리할까요? 비동기적으로 로드하는 것 외에도 캐싱을 가능하게 하는 나머지 CSS를 도입하려면 외부 CSS를 사용하는 것이 좋습니다.
CSS는 CSS 파일 요청, 다운로드 및 구문 분석이 완료될 때까지 처리된 콘텐츠를 렌더링하지 않습니다. 필요한 CSS가 로드되기 전에 브라우저가 페이지 렌더링을 시작하는 것을 원하지 않기 때문에 이러한 차단이 필요한 경우가 있습니다. 그러면 첫 번째 화면의 주요 CSS가 인라인된 후에는 나머지 CSS 콘텐츠의 렌더링을 차단할 필요가 없으며 외부 CSS를 비동기적으로 사용하고 로드할 수 있습니다.
그렇다면 CSS의 비동기 로딩을 구현하는 방법은 무엇일까요? 브라우저
에서 CSS의 비동기 로딩을 구현하는 방법에는 다음 네 가지가 있습니다.
첫 번째 방법은 JavaScript를 사용하여 스타일시트 링크 요소를 동적으로 생성하고 이를 DOM에 삽입하는 것입니다.
// 创建link标签 const myCSS = document.createElement( "link" ); myCSS.rel = "stylesheet"; myCSS.href = "mystyles.css"; // 插入到header的最后位置 document.head.insertBefore( myCSS, document.head.childNodes[ document.head.childNodes.length - 1 ].nextSibling );
두 번째 방법은 링크 요소의 media 속성을 사용자의 브라우저가 일치하지 않는 미디어 유형(또는 미디어 쿼리)으로 설정하는 것입니다(예: media="print" 또는 전혀 그렇지 않은 경우). -존재 유형 미디어 = "존재하지 않음". 브라우저의 경우 스타일 시트가 현재 미디어 유형에 적합하지 않으면 우선 순위가 낮아지고 페이지 렌더링을 차단하지 않고 다운로드됩니다.
물론 이는 CSS의 비동기 로딩을 달성하기 위한 것입니다. 파일이 로드된 후 미디어 값을 screen 또는 all로 설정하여 브라우저가 CSS 구문 분석을 시작하도록 하세요.
<link rel="stylesheet" href="mystyles.css" media="noexist" onload="this.media='all'">
두 번째 방법과 유사하게, rel 속성을 통해 링크 요소를 대체 선택적 스타일 시트로 표시할 수도 있으며, 이는 브라우저에 의한 비동기 로딩도 달성할 수 있습니다. 또한 로딩이 완료된 후 rel을 다시 변경하는 것을 잊지 마세요.
<link rel="alternate stylesheet" href="mystyles.css" onload="this.rel='stylesheet'">
위의 세 가지 방법은 모두 비교적 오래된 방법입니다. 이제 웹 표준 rel="preload"5는 CSS와 유사한 리소스를 포함하여 리소스를 비동기적으로 로드하는 방법을 지적합니다.
<link rel="preload" href="mystyles.css" as="style" onload="this.rel='stylesheet'">
필요에 따라 참고하세요. as 속성을 무시하거나 잘못된 as 속성을 사용하면 사전 로드가 XHR 요청과 동일해지며, 브라우저는 어떤 콘텐츠가 로드되는지 알 수 없으므로 해당 리소스의 로드 우선 순위는 매우 낮습니다. as의 선택값은 위의 표준 문서를 참조할 수 있습니다.
rel="preload"의 사용법은 위의 두 가지와 다르지 않은 것 같습니다. 둘 다 특정 속성을 변경하여 브라우저가 CSS 파일을 비동기적으로 로드하지만 로드가 완료되고 수정 사항이 복원될 때까지 구문 분석하지 않습니다. 그런 다음 구문 분석을 시작합니다.
그러나 실제로는 매우 중요한 차이점이 있습니다. 즉, 사전 로드를 사용하면 일치하지 않는 미디어 방법을 사용하는 것보다 CSS 로드를 더 빨리 시작할 수 있다는 것입니다. 따라서 이 표준에 대한 지원이 아직 완전하지 않더라도 이 방법을 먼저 사용하는 것이 좋습니다.
이 표준은 이제 후보 표준이 되었으며, 브라우저는 점차적으로 이를 지원하게 될 것이라고 믿습니다. 각 브라우저의 지원 수준은 아래 그림과 같습니다.
성능을 최적화할 때 가장 쉽게 생각할 수 있는 방법 중 하나는 파일 압축입니다.
파일 크기는 브라우저의 로딩 속도에 직접적인 영향을 미치며, 이는 네트워크 상태가 좋지 않을 때 특히 두드러집니다. webpack, gulp/grunt, Rollup 등과 같은 오늘날의 구성 도구도 CSS 압축 기능을 지원하는 것은 이미 모든 사람이 익숙하다고 생각합니다. 압축된 파일의 크기를 대폭 줄일 수 있어 브라우저의 로딩 시간을 크게 줄일 수 있습니다.
파일을 압축하면 파일 크기가 줄어들 수 있습니다. 그러나 CSS 파일 압축은 일반적으로 불필요한 공백만 제거하므로 CSS 파일의 압축 비율이 제한됩니다. CSS를 간소화하는 다른 방법이 있나요? 대답은 '예'입니다. 압축 파일이 여전히 예상 크기를 초과하는 경우 코드에서 쓸모 없는 CSS를 찾아 제거할 수 있습니다.
일반적으로 쓸모없는 CSS 코드에는 두 가지 유형이 있습니다. 하나는 다른 요소나 다른 상황에서 반복되는 코드이고, 다른 하나는 전체 페이지에 적용되지 않는 CSS 코드입니다. 전자의 경우 코드를 작성할 때 공용 클래스를 최대한 추출하여 중복을 줄여야 합니다. 후자의 경우, 다른 개발자가 코드를 유지 관리하는 과정에서 더 이상 사용되지 않는 CSS 코드가 항상 생성되기 마련입니다. 물론, 한 사람이 작성하는 경우에도 이러한 문제가 발생할 수 있습니다. 이러한 쓸모없는 CSS 코드는 브라우저의 다운로드 볼륨을 증가시킬 뿐만 아니라 브라우저의 구문 분석 시간도 증가시켜 성능을 크게 저하시킵니다. 그래서 우리는 이런 쓸모없는 코드를 찾아서 제거해야 합니다.
물론, 이런 쓸모없는 CSS를 수동으로 삭제하는 것은 매우 비효율적입니다. Uncss7 라이브러리의 도움으로 이를 수행할 수 있습니다. Uncss는 스타일 시트에서 쓸모없는 CSS를 제거하는 데 사용할 수 있으며 다중 파일 및 JavaScript 삽입 CSS를 지원합니다.
우리는 이미 네 가지 실용적인 최적화 기법에 대해 이야기했습니다. 이제 제안된 네 가지 기법을 소개하겠습니다.
대부분의 친구들은 CSS 선택기가 오른쪽에서 왼쪽으로 수행된다는 것을 알고 있습니다. 이 전략은 다양한 유형의 선택기 간에 성능 차이를 가져온다는 것을 의미합니다. #markdown-content-h3과 비교하면 #markdown .content h3을 사용할 때 브라우저가 렌더링 트리를 생성하는 데 더 많은 시간이 걸립니다. 후자는 먼저 DOM에서 모든 h3 요소를 찾은 다음 .content가 아닌 상위 요소를 필터링하고 마지막으로 #markdown이 아닌 .content의 상위 요소를 필터링해야 하기 때문입니다. 상상해 보세요. 페이지에 더 많은 중첩 수준과 더 많은 요소가 있으면 일치하는 데 드는 시간 비용이 자연스럽게 높아집니다.
그러나 최신 브라우저는 이 측면에서 많은 최적화를 수행했으며 다양한 선택기 간의 성능 차이는 명확하지 않거나 매우 작습니다. 또한 다양한 브라우저의 다양한 선택기 성능은 완전히 동일하지 않으며 CSS를 작성할 때 모든 브라우저를 고려하는 것은 불가능합니다. 이 두 가지 이유를 고려하여 선택기를 사용할 때 다음 사항만 기억하면 되며 나머지는 전적으로 선호도에 따라 결정될 수 있습니다.
간단하게 유지하고 너무 많이 중첩되어 지나치게 복잡한 선택기를 사용하지 마세요.
와일드카드와 속성 선택기는 효율성이 가장 낮고 가장 일치하는 요소가 필요하므로 사용하지 마세요.
h3#markdown-content와 같은 요소 태그를 수정하기 위해 클래스 선택기와 ID 선택기를 사용하지 마세요. 이는 불필요하며 효율성을 떨어뜨립니다.
속도를 추구하면서 가독성과 유지관리성을 포기하지 마세요.
위 사항에 대해 여전히 궁금한 점이 있으면 저자는 CSS 작성 사양으로 다음 CSS 방법론(BEM9, OOCSS10, SUIT11, SMACSS12, ITCSS13, Enduring CSS14 등) 중 하나를 선택할 것을 권장합니다. 통일된 방법론을 사용하면 모든 사람이 통일된 스타일을 형성하고, 명명 충돌을 줄이고, 위의 문제를 피할 수 있습니다. 즉, 아직 사용해 본 적이 없다면 빨리 사용해 보세요.
팁: CSS 선택기가 오른쪽에서 왼쪽으로 일치하는 이유는 무엇인가요?
CSS의 더 많은 선택자는 일치하지 않으므로 성능 문제를 고려할 때 고려해야 할 것은 선택자가 일치하지 않을 때 효율성을 어떻게 향상시킬 수 있는지입니다. 오른쪽에서 왼쪽으로 일치하는 것은 이 목적을 달성하기 위한 것입니다. 이 전략은 일치하지 않을 때 CSS 선택기를 더 효율적으로 만들 수 있습니다. 이렇게 생각하면 매칭 시 더 많은 성능을 소모하는 것이 합리적입니다.
브라우저가 화면을 그릴 때 브라우저가 작동하거나 계산해야 하는 모든 속성은 상대적으로 비용이 많이 듭니다. 페이지 다시 그리기가 발생하면 브라우저의 렌더링 성능이 저하됩니다. 따라서 CSS를 작성할 때 box-shadow/border-radius/filter/transparency/:nth-child 등과 같은 비용이 많이 드는 속성의 사용을 줄이도록 노력해야 합니다.
물론 이것이 모든 사람이 이러한 속성을 사용해서는 안 된다는 의미는 아닙니다. 왜냐하면 이러한 속성은 우리가 자주 사용하는 속성이어야 하기 때문입니다. 내가 이것을 언급하는 이유는 모든 사람이 이것을 이해할 수 있도록 하기 위한 것입니다. 선택할 수 있는 옵션이 두 가지인 경우 값비싼 속성이 없거나 값비싼 속성이 적은 옵션에 우선순위를 둘 수 있습니다. 매번 이 옵션을 선택하면 웹사이트 성능이 무의식적으로 향상됩니다.
웹사이트를 사용하는 동안 특정 작업으로 인해 스타일이 변경됩니다. 이때 브라우저는 이러한 변경 사항을 감지하고 다시 렌더링해야 합니다. 많은. FPS가 60이면 사용자가 웹 사이트를 사용할 때 편안함을 느낄 것이라는 것은 모두가 알고 있는 사실입니다. 즉, 각 렌더링과 관련된 모든 작업을 16.67ms 이내에 완료해야 하므로 비용이 많이 드는 작업을 최소화하도록 노력해야 합니다.
3.1 리플로우 감소
리플로우를 사용하면 브라우저가 전체 문서를 다시 계산하고 렌더링 트리를 다시 작성하게 됩니다. 이 프로세스는 브라우저의 렌더링 속도를 감소시킵니다. 아래에 표시된 것처럼 일정 변경을 트리거하는 작업이 많으므로 이러한 작업을 자주 트리거하지 않아야 합니다.
글꼴 크기 및 글꼴 계열 변경
요소의 내부 및 외부 여백 변경
JS를 통해 CSS 클래스 변경
을 통해 DOM 요소의 위치 관련 속성 가져오기 JS(너비/높이/왼쪽 등)
CSS 의사 클래스 활성화
스크롤 막대를 스크롤하거나 창 크기를 변경하세요
또한 어떤 속성이 트리거되는지 쿼리할 수도 있습니다. CSS Trigger15를 통해 리플로우 및 다시 그리기.
일부 CSS 속성이 리플로우 성능이 더 좋다는 점을 언급할 가치가 있습니다. 예를 들어 Flex를 사용할 경우 inline-block 및 float를 사용할 때보다 reflow가 더 빠르므로 레이아웃 시 Flex에 우선순위를 부여할 수 있습니다.
3.2 불필요한 다시 그리기 방지
요소의 모양(예: 색상, 배경, 가시성 및 기타 속성)이 변경되면 다시 그리기가 시작됩니다. 홈페이지 이용 중에는 재작성이 불가피합니다. 그러나 브라우저는 이를 최적화하고 여러 리플로우 및 다시 그리기 작업을 하나의 실행으로 병합합니다. 그러나 페이지가 스크롤될 때 트리거되는 hover 이벤트와 같은 불필요한 다시 그리기는 여전히 피해야 합니다. 그러면 페이지가 더 부드럽게 스크롤될 수 있습니다.
또한 CSS로 애니메이션 관련 코드를 점점 더 많이 작성하고 사용자 경험을 개선하기 위해 애니메이션을 사용하는 데 익숙해졌습니다. 애니메이션을 작성할 때 위의 내용도 참조하여 다시 그리기 및 재배열의 트리거를 줄여야 합니다. 또한 하드웨어 가속 16 및 will-change17을 통해 애니메이션 성능도 향상시킬 수 있습니다. 이 기사에서는 이에 대해 자세히 소개하지 않습니다. 관심 있는 친구는 링크를 클릭하여 볼 수 있습니다.
마지막으로 주목해야 할 점은 사용자의 장치가 상상만큼 좋지 않을 수 있다는 것입니다. 적어도 우리 개발 기계만큼 좋지는 않을 것입니다. Chrome의 개발자 도구를 사용하여 CPU 속도를 늦춘 다음 관련 테스트를 수행할 수 있습니다
모바일 측에서 액세스해야 하는 경우 모바일 측의 성능이 저하되는 경우가 많기 때문에 속도 제한을 낮게 설정하는 것이 가장 좋습니다. .
마지막으로 @import를 사용하여 CSS를 소개하지 마세요. 모든 사람이 거의 사용하지 않는 것 같아요.
다음 두 가지 이유로 @import를 주로 사용하지 않는 것이 좋습니다.
우선 @import를 사용하여 CSS를 도입하면 브라우저의 병렬 다운로드에 영향을 미칩니다. @import를 사용하여 참조된 CSS 파일은 자신을 참조하는 CSS 파일이 다운로드된 후에 다운로드 및 구문 분석해야 하는 다른 CSS 파일이 있다는 것만 알게 됩니다. 그런 다음 해당 파일을 다운로드하고 구문 분석, 렌더링 트리 구축 등을 시작합니다. 일련의 작업을 다운로드한 후. 이로 인해 브라우저가 필요한 스타일 파일을 병렬로 다운로드할 수 없게 됩니다.
두 번째로 @import를 여러 개 사용하면 다운로드 순서가 혼란스러워집니다. IE에서 @import는 리소스 파일의 다운로드 순서를 방해합니다. 즉, @import 뒤에 나열된 js 파일이 @import보다 먼저 다운로드되고 @import 자체의 병렬 다운로드를 방해하거나 심지어 파괴합니다.
그러므로 이 방법을 사용하지 말고 링크 태그를 사용하세요.
더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 교육을 방문하세요! !
위 내용은 알아야 할 8가지 CSS 성능 최적화 팁의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
