페이지로드 속도를 최적화하려면 모든 CSS 파일을 프로그래밍 방식으로 인라인 해야 할까?

페이지로드 속도를 최적화하려면 모든 CSS 파일을 프로그래밍 방식으로 인라인해야합니까?

---

Google PageSpeed는 종종

CSS 전달 최적화를

제안합니다 . 다음과 같이 모든 CSS를 인라인하기 위해 네트워크 왕복을 줄일 것이라고 생각했습니다.

<style type="text/css">

    @{ 
        var bootstrap = File.ReadAllText(Server.MapPath("bootstrap.min.css"));
        var bootstrapTheme = File.ReadAllText(Server.MapPath("theme.min.css"));
        var fontAwesome = File.ReadAllText(Server.MapPath("font-awesome.min.css"));
        var bigfont = File.ReadAllText(Server.MapPath("bigfont.min.css"));
        var bigfontPrint = File.ReadAllText(Server.MapPath("bigfont-print.min.css"));
    }

    @Html.Raw(bootstrap)
    @Html.Raw(bootstrapTheme)
    @Html.Raw(fontAwesome)
    @Html.Raw(bigfont)
    @Html.Raw(bigfontPrint)

</style>

이것은 느린 페이지로드 문제에 대한 합리적인 해결책으로 보이며 PageSpeed ​​점수가 88에서 95로 증가했습니다.코드 스타일을 잠시 제쳐두고, 이런 식으로 모든 CSS를 인라인하지 않는 기술적 이유가 있다면 어떤 것이 있습니까?

---

모든 CSS를 인라인하면 캐시 할 수 없으므로 모든 단일 페이지로드에 필요한 모든 CSS가 포함되며 실제로 낭비되는 대역폭이 많이 될 수있는 대형 라이브러리를 사용할 때 사용됩니다. 예를 들어, Bootstrap은 약 120k입니다. 공유 한 Google 링크는 다음을 지정합니다 (강조 표시).

외부 CSS 리소스가 작 으면

인라인이라고하는 HTML 문서에 직접 삽입 할 수 있습니다.

따라서 단일 페이지로드는 더 빠를 수 있지만 전반적으로 더 느릴 수 있습니다. 개인적으로 나는 그렇게하지 않을 것입니다. 그러나 할 수있는 한 가지 방법은 모든 CSS를 단일 요청으로 묶는 것입니다 (MVC를 사용하므로 비교적 간단합니다). 따라서 CSS 및 다음에 의해 요청 된 모든 향후 페이지를 위해 서버로 단 한 번의 추가 이동 만 수행하면됩니다. 브라우저는 다시 요청할 필요가 없습니다.

---

아무도이 기술의 의도 된 사용 사례를 언급하지 않았으며, 이는 확실히 CSS를 100 %로드하지 않는 것입니다. 오히려이 기술은 사용자 가 페이지가 더 빨리로드

되었다고 생각

하게 만들기위한 것입니다.페이지로드 속도를 높이는 방법을 논의 할 때 실제 목표는 일반적으로 페이지로드 속도를 높이는 것입니다. 사용자 경험의 관점에서 이것은 실제로로드 시간을 줄이는 것보다 훨씬 더 중요합니다. 어쨌든 사람이 그렇게 빨리 파싱 할 수 없기 때문에 전체 페이지를로드하는 데 500ms가 걸리는 것은 중요하지 않습니다. 중요한 것은 페이지가로드되는 속도입니다.따라서이 기술의 적절한 사용법은 페이지를 올바르게 렌더링하기 위해 절대적으로 필수적인 CSS를 즉시로드하는 것입니다. 즉, 이미지를 올바른 크기로 만들고 사물을 올바르게 띄우며 페이스 북 SDK가 비즈니스를 완료하는 동안 페이지 콘텐츠의 끔찍한 모습이 페이지 주위를 뛰어 다니는 것을 방지하는 CSS 규칙이 있습니다. 이 코드는 마크 업이로드되는 순간에 있어야합니다. 해결책 : 중요한 CSS를 인라인하십시오.그러나 확실히 모든 CSS를 인라인하지 마십시오. 어쨌든 비동기 적으로로드되는 콘텐츠 만 CSS 스타일로 지정하면 나중에로드되는 또 다른 100kb가있을 수 있습니다. 그러나 25ms 이후에 올바른 형식이어야하는 페이지 구조가있는 경우 해당 CSS를 인라인해야합니다.

---

PageSpeed ​​제안을 오해했습니다. 권장 사항은 작은 CSS 파일에 대한 것입니다.

외부 CSS 리소스가 작 으면 인라인이라고하는 HTML 문서에 직접 삽입 할 수 있습니다. [...] CSS 파일이 큰 경우 CSS를 완전히 인라인하면 PageSpeed ​​Insights에서 보이는 콘텐츠 우선 순위 지정을 통해 페이지의 스크롤없이 볼 수있는 부분이 너무 크다는 경고를 표시 할 수 있습니다.

실제로이 기사에서는 나중에 큰 CSS 파일에 대한 균형 잡힌 접근 방식을 제안합니다. 중요한 CSS를 인라인하고 나머지 CSS 파일을 지연로드하는 것입니다.

---

이제 PageSpeed가 큰 CSS 파일 *을 인라인 한 후 적절한 점수를 제공하더라도 여전히 나쁜 생각 일 수 있습니다.

여분

인라인 CSS 파일은

<style>...</style>

페이지간에 태그 를 복제한다는 것을 의미합니다 . 즉, 후속 또는 반복 페이지보기에 대해 중복 데이터를 제공합니다. 중복 데이터는 대역폭을 소모하고 다운로드 시간을 증가시킵니다.강력한 캐싱 헤더와 함께 별도의 CSS 파일을 사용하면 중복을 제거 할 수 있습니다. 캐싱 헤더는 브라우저가 첫 번째 페이지보기에서 CSS 파일을 캐시하고 후속 또는 반복 페이지보기에서 재사용하도록 지시합니다.

콘텐츠 대 데이터

인라인 CSS 파일은 페이지에서 "실제"콘텐츠의 비율을 줄입니다. 인라인 CSS 파일을 사용하려면 콘텐츠 위에 CSS를 삽입해야하지만 대부분의 사람들은 실제 콘텐츠를 상단 HTML 근처에 배치하려고 노력합니다.또한 인라인 CSS는 브라우저가 JavaScript 및 이미지와 같은 다른 리소스를 다운로드하기 전에 추가 바이트를 다운로드하도록합니다.

압축 비용

HTML 페이지가 동적으로 생성되는 경우 대부분 압축되지 않은 상태로 제공됩니다. 일부 서버 (예 : IIS) 및 소프트웨어 (예 : Wordpress)는 동적 콘텐츠의 압축을 허용하지만 정적 콘텐츠 (예 : CSS 파일)의 압축에 비해 더 많은 CPU + 메모리를 필요로합니다. 이것이 CSS를 별도의 파일에 보관해야하는 또 다른 이유입니다.위의 이유 때문에 한 페이지 웹 사이트에서도 CSS를 결합, 축소, 압축 및 캐시 한 상태로 별도의 파일에 보관합니다.

---

* 인라인 스타일 과 혼동하지 마십시오.

---

This is too long to fit in a comment. There where I work, we use Content Security Policy header directives (specifically style-src) to explicitly prohibit the use of inline CSS. The rationale not to use inline CSS in this case is minimizing the risks of CSS injection for pages created dynamically. OWASP has detailed information about this topic, including exploit samples: https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005). If only static content is served to the browser, there should be no risk.

ReferenceURL : https://stackoverflow.com/questions/32814706/should-i-inline-all-css-files-programmatically-to-optimize-page-load-speed