렌더링 차단 리소스를 제거하는 방법

렌더링 차단 리소스는 웹 페이지의 인프라를 최적화하는 데 중요한 부분입니다.

이를 줄이면 페이지 로드 속도가 훨씬 빨라지고 페이지의 Core Web Vitals가 크게 개선될 수 있습니다.

이러한 렌더링 차단 리소스에는 로드하는 데 너무 오래 걸리는(사용할 필요가 없는) 외부 글꼴, 불필요한 미디어 파일, 사라지지 않는 코드 부풀림, 사라지지 않는 추가 플러그인 등이 포함됩니다. 필요한.

압축하고 결합하여 장치에서 더 빠르게 다운로드하는 단일 파일을 생성하여 훨씬 더 빠른 페이지 속도를 생성할 수 있는 이러한 유형의 리소스는 무수히 많습니다.

이 문제에서 페이지 구조를 최적화하면 Google이 사이트를 크롤링하기 위해 수행해야 하는 작업량을 줄일 수 있으며 결과적으로 사용자 환경을 개선할 수 있습니다.

실제로 이 프로세스를 수행하면 얻을 수 있는 이점은 다음과 같습니다.

• 더 빠른 페이지 속도.
• Google에서 페이지를 로드하는 데 필요한 리소스가 적습니다.
• 코드 팽창으로 인한 문제 감소.
• DOM(문서 개체 모델)의 전체 파일 크기가 작아집니다.
• 다운로드할 JavaScript 및 CSS 파일이 적습니다.
• 다양한 플랫폼과 장치에서 더 빠르고 효과적으로 배포할 수 있습니다.
• 모바일에서 향상된 사용자 상호 작용.
• 전반적인 성능이 향상되었습니다.

분명히 사이트에서 이러한 유형의 최적화 프로세스를 수행하면 엄청난 이점이 있습니다.

렌더링 차단 리소스를 식별해야 하는 이유는 무엇입니까?

웹 페이지 렌더링을 차단하는 리소스를 식별하고 줄이는 것은 페이지 속도를 높이거나 낮출 수 있는 중요한 최적화 지점입니다.

결과적으로 사이트의 페이지 경험 메트릭(및 사용자 만족도)에 배당금을 지불할 수 있을 정도로 매우 중요할 수 있습니다.

2021년에 모바일 웹 페이지를 완전히 렌더링하는 데 걸린 평균 시간은 22초였습니다. 2018년에는 15초였습니다.

분명히 이것은 Google의 권장 시간인 2~3초보다 상당히 높은 수치입니다. 또한 이전보다 훨씬 높아졌습니다.

렌더링 차단 리소스에서 이러한 문제를 일으키는 원인은 무엇입니까?

전체 페이지 렌더링 속도의 증가를 주도하는 요인은 무엇입니까?

주목해야 할 한 가지 흥미로운 추세는 시스템 글꼴에 비해 타사 글꼴에 대한 의존도가 증가하고 있다는 것입니다. 타사 글꼴을 리소스로 사용하면 페이지 처리 및 렌더링을 방해하는 경향이 있습니다.

시스템 글꼴을 사용하면 브라우저가 추가로 로드할 필요가 없으므로 결과적으로 추가 처리 단계가 필요하지 않습니다.

Web Almanac의 스크린샷, 2022년 11월

산업 전반에 걸친 이러한 의존도는 이 렌더링 시간에 영향을 미칠 수 있습니다. 물론 이것이 렌더링 차단 리소스와 관련된 이 문제의 유일한 원인은 아닙니다.

또한 Google 애널리틱스 또는 추적 목적으로 타사 Facebook 픽셀을 사용하는 것과 같은 Google 자체 서비스는 렌더링 시간에 상당한 영향을 미치는 경향이 있습니다.

이러한 기술에 의존하려는 욕구가 마케팅 관점에서 반드시 끔찍한 것은 아닙니다.

그러나 렌더링 차단 리소스의 관점에서 볼 때 페이지 로드 시간과 Google(및 사용자)이 페이지를 인식하는 방식이 크게 증가할 수 있습니다.

이상적인 솔루션은 사용자 상호 작용을 위해 페이지가 최대한 빨리 로드되도록 하는 것입니다.

또한 오늘날 웹 개발자가 사용하는 열악한 웹 개발 관행이 원인일 가능성도 있습니다.

어느 쪽이든 이는 모든 웹 사이트 프로젝트에서 Core Web Vitals 감사의 일부로 해결되어야 하는 것입니다.

그러나 페이지 경험은 전체 페이지가 얼마나 빨리 로드되는지에 관한 것이 아닙니다.

대신 Google의 페이지 경험 프레임워크 또는 Core Web Vitals에서 측정한 페이지의 전반적인 경험에 관한 것입니다.

이것이 DOM 또는 문서 개체 모델 전체에서 중요한 렌더링 경로에 대한 페이지 속도를 개선하고 최적화하는 작업을 원하는 이유입니다.

중요한 렌더링 경로는 무엇입니까?

주요 렌더링 경로는 브라우저가 처음 데이터 수신을 시작할 때부터 최종 렌더링에서 페이지를 최종적으로 컴파일할 때까지 전체 페이지를 렌더링하는 데 걸리는 모든 단계를 나타냅니다.

이것은 올바르게 최적화하면 몇 밀리초 밖에 걸리지 않는 프로세스입니다.

중요한 렌더링 경로를 최적화한다는 것은 다양한 장치에서 렌더링 성능을 최적화한다는 것을 의미합니다.

이것은 중요한 렌더링 경로를 최적화하여 가능한 한 빨리 첫 번째 페인트에 도달함으로써 달성됩니다.

기본적으로 시각적 콘텐츠를 최대한 빨리 표시하기 위해 사용자가 빈 흰색 화면을 보는 데 소비하는 시간을 줄이고 있습니다(아래 0.0초 참조).

web.dev의 스크린샷, 2022년 11월

이를 수행하는 방법에 대한 전체 프로세스가 Google의 개발자 가이드 문서에 요약되어 있지만 특히 렌더링 차단 리소스를 줄이는 한 가지 강력한 타자에 집중할 것입니다.

중요한 렌더링 경로는 어떻게 작동합니까?

주요 렌더링 경로는 HTML, CSS 및 JavaScript를 화면의 실제 픽셀로 변환하여 페이지를 렌더링하기 위해 브라우저가 수행하는 일련의 단계를 나타냅니다.

Medium의 스크린샷, 2022년 11월

기본적으로 브라우저는 모든 시각적 콘텐츠 렌더링을 시작하기 전에 모든 HTML 및 CSS 파일(및 일부 추가 작업)을 요청, 수신 및 구문 분석해야 합니다.

이 프로세스는 (대부분의 경우) 1초 이내에 발생합니다. 브라우저가 이 단계를 완료할 때까지 사용자에게는 빈 흰색 페이지가 표시됩니다.

다음은 페이지 로드 프로세스의 여러 단계에 따라 페이지가 로드되는 방식을 사용자가 경험할 수 있는 방법의 예입니다.

web.dev의 스크린샷, 2022년 11월

따라서 중요한 렌더링 경로를 개선하면 전체 페이지 경험이 개선되어 Core Web Vitals 지표의 성능을 개선하는 데 도움이 될 수 있습니다.

중요한 렌더링 경로를 어떻게 최적화합니까?

중요한 렌더링 경로를 개선하려면 렌더링 차단 리소스를 분석해야 합니다.

모든 렌더링 차단 리소스는 페이지의 초기 렌더링을 차단하여 결과적으로 Core Web Vitals 점수에 부정적인 영향을 미칠 수 있습니다.

여기에는 다음과 같은 최적화 프로세스가 포함됩니다.

• 렌더링 경로에 중요한 리소스의 수를 줄입니다. 이는 가능한 렌더링 차단 리소스에 대해 defer 메서드를 사용하여 수행할 수 있습니다.
• 스크롤 없이 볼 수 있는 콘텐츠의 우선순위 를 지정하고 가능한 한 빨리 중요한 미디어 자산을 다운로드합니다.
• 나머지 중요한 리소스 의 파일 크기를 압축합니다 .

이렇게 하면 Core Web Vitals와 페이지가 사용자에게 물리적으로 렌더링되는 방식을 모두 개선할 수 있습니다.

주요 렌더링 경로를 최적화하는 데 사용할 수 있는 최적화 기술에 대해 논의하기 전에 초기 브라우저 로드 프로세스와 주요 렌더링 경로가 중요한 이유에 대해 논의하는 것이 중요합니다.

이 프로세스에는 다음이 포함됩니다.

• 페이지 요소를 미리 로드합니다.
• 중요한 스타일 인라인.
• JavaScript 파일의 로딩을 연기합니다.
• 초기 힌트.

페이지 요소 미리 로드

첫째, 브라우저가 서버에서 페이지를 가져올 때 브라우저는 처음에 다운로드할 모든 페이지 요소를 스캔하고 찾습니다. 기본적으로 이는 브라우저가 모든 요소를 ​​동시에 다운로드하는 프로세스에서 발생합니다.

그러나 다운로드할 페이지 요소가 많으면 어떻게 됩니까(예: WordPress 웹 사이트에서 자주 발생합니까?). 이로 인해 서버 리소스가 정체되어 페이지 로드 시간이 더 늘어날 수 있습니다.

이 문제를 어떻게 해결합니까? 미리 로드 링크를 사용하여 페이지 렌더링을 차단하는 중요한 파일을 비동기적으로 다운로드합니다(이 문서의 뒷부분에서 설명).

요소 미리 로드는 다른 모든 파일을 로드하기 전에 프로세스의 첫 번째 페인트 단계에 필요한 중요한 파일을 로드하기 때문에 렌더링 차단 스타일 시트를 제거하는 데 도움이 되는 기술입니다.

CSS, JS, 글꼴 또는 이미지를 미리 로드할 수 있습니다. 다음은 미리 로드하는 방법의 예입니다.

JavaScript 사전 로드

 <link rel="preload" as="script" href="critical.js">

CSS 사전 로드

 <링크 rel="preload" href="style.css" as="스타일" />

글꼴 사전 로드

 <link rel="preload" href="fonts/webfont.woff2" as="font" type="font/woff2" 크로스오리진 />

이미지 사전 로드

 <link rel=preload href="cat.png" as=image 이미지>

이는 페이지 처리 속도를 높이는 데 도움이 됩니다. 그러나 이것은 이상적인 방법이 아닙니다.

이상적인 방법은 2~3개의 플러그인, 아마도 2~3개의 다른 파일만 사용하도록 사이트를 최적화하고 전체 페이지 렌더링을 위해 최소한으로 유지하는 것입니다.

슬프게도 이것은 추구하려는 현실적인 노력이 아닙니다.

WordPress 사이트에는 개발자가 기꺼이 다루지 않는(또는 원하지 않는) 많은 플러그인과 리소스가 있는 경향이 있기 때문에 성공으로 가는 가장 쉬운 길은 특정 플러그인을 사용하여 이러한 리소스를 적절하게 최적화하는 것입니다.

중요 스타일 인라인

Critical CSS는 스크롤 없이 볼 수 있는 콘텐츠에 대한 CSS를 추출하여 콘텐츠를 사용자에게 최대한 빠르게 렌더링하는 기술입니다.

일반적으로 최소한 다음이 필요합니다.

• 모든 글꼴 선언.
• 모든 레이아웃 관련 CSS.
• 스크롤 없이 볼 수 있는 DOM(문서 개체 모델) 요소에 대한 모든 CSS 스타일 규칙입니다.

모든 리소스를 동시에 로드하는 페이지의 이전 예제를 사용하여 중요한 스타일 인라인에는 HTML <head> 태그 자체 내의 코드 사용이 포함됩니다.

예를 들어 google.com 소스 코드를 확인하면 중요한 CSS가 HTML의 <head> 섹션에 인라인된 것을 볼 수 있습니다.

Google.com 소스 코드의 스크린샷, 2022년 11월

중요한 CSS를 추출하는 데 도움이 되는 몇 가지 도구가 있습니다.

• Criticalcss.com.
• 위독한.
• HTML 크리티컬 웹팩 플러그인.

JavaScript 파일의 로딩 지연

이 방법을 사용하면 DOM 트리의 다른 중요한 요소가 로드될 때까지 JavaScript 파일의 로드를 연기할 수 있습니다. 그러나 여기에는 몇 가지 주의 사항이 있습니다.

JavaScript 파일을 연기하는 방법의 예:

 <스크립트 지연 src="script.js"></script>

첫 번째는 JavaScript 파일의 로드를 지연할 때 사이트의 모양에 부정적인 영향을 미칠 수 있다는 것입니다. 이러한 파일 중 일부는 페이지를 완전히 로드하는 데 필요한 요소일 수 있기 때문입니다.

두 번째는 주의하지 않으면 JavaScript 파일의 로드를 지연하여 잠재적으로 페이지의 상호 작용(다음 페인트 Core Web Vitals 메트릭에 대한 상호 작용)에 문제를 일으킬 수 있다는 것입니다.

세 번째는 사이트가 전반적으로 작동하는 방식에 문제를 일으킬 수도 있다는 것입니다.

아이디어는 이러한 유형의 최적화에 대해 작업할 때 주의해야 하므로 프로세스의 다른 곳에서 실수로 문제를 일으키지 않도록 해야 한다는 것입니다.

이렇게 하면 페이지 속도와 Google이 사이트를 보는 방식에 큰 영향을 미칠 수 있습니다.

그러나 다른 문제는 Nitro와 같은 플러그인을 사용하여 CSS 및 JavaScript와 같은 중요한 파일을 연기하는 경우입니다.

이는 페이지 속도에 긍정적인 영향을 미칠 수 있지만 주요 문제는 페이지가 문서의 HTML 부분을 로드할 때까지 플러그인이 모든 중요한 파일을 연기한다는 것입니다.

이것은 무엇을 의미 하는가? 이는 Google이 표시하려는 전체 문서를 볼 수 없음을 의미합니다. 이것은 robots.txt를 사용하여 CSS 파일과 자바스크립트 파일을 차단하는 것과 유사합니다. Google은 귀하의 사이트가 모바일 친화적인지 여부를 결정해야 합니다.

공식 Google 개발자 페이지에는 다른 곳에서 언급된 바와 같이 다음과 같이 나와 있습니다.

“최적의 렌더링 및 인덱싱을 위해 항상 Googlebot이 웹사이트에서 사용하는 JavaScript, CSS 및 이미지 파일에 액세스하도록 허용하여 Googlebot이 일반 사용자처럼 사이트를 볼 수 있도록 합니다.

사이트의 robots.txt 파일이 이러한 자산의 크롤링을 허용하지 않는 경우 Google 알고리즘이 콘텐츠를 얼마나 잘 렌더링하고 색인을 생성하는지에 직접적인 피해를 줍니다. 이로 인해 차선책이 될 수 있습니다.”

SEO상의 이유로 중요한 CSS 및 JavaScript 파일을 연기하는 경우 Google이 페이지 로드 시 이러한 파일을 볼 수 있도록 보장하는 한 Google이 귀하의 사이트를 보는 방식과 관련하여 주요 문제에 부딪히지 않아야 합니다.

더 나은 서버 최적화를 위한 초기 힌트 사용

초기 힌트에 대해 이야기하기 전에 서버가 웹 페이지를 로드하는 프로세스에 대해 논의해야 합니다. 사이트는 실제로 최근 몇 년 동안 더욱 정교해졌습니다.

따라서 서버도 마찬가지입니다. 하지만, 한계가 있습니다. 서버가 하루 종일 사소한 작업을 수행할 수 있고 실제로 수행하더라도 서버가 사이트의 리소스를 처리하는 방법을 과도하게 생각하여 수렁에 빠질 가능성은 여전히 ​​있습니다.

따라서 이런 일이 발생하면 그렇지 않은 경우보다 추가 대기 시간이 발생하며 이는 브라우저가 페이지 렌더링을 시작하기 전에 발생합니다.

이 대기 시간이 발생하면 사이트가 브라우저 창에 표시되기까지 몇 초가 걸리는 상황이 발생할 수 있습니다.

그리고 서버가 파일을 제대로 렌더링하는지 확인하는 것은 페이지 속도를 높이는 훌륭한 첫 단계입니다.

다음은 서버가 제대로 응답하지 않고 특정 리소스를 처리하는 데 너무 오래 걸리는 경우 발생하는 상황의 예입니다.

developer.chrome.com의 스크린샷, 2022년 11월

그렇다면 초기 힌트는 어떻게 작동합니까?

구글 크롬 개발자 가이드에 따르면 초기 힌트는 최종 응답에 앞서 정확한 예비 HTTP 응답을 보내는 데 사용되는 HTTP 상태 코드(103 초기 힌트)입니다.

이것은 무엇을 달성합니까?

이를 통해 서버는 웹 페이지 자체에서 로드 및 사용할 가능성이 있는 특정 중요 리소스(JavaScript 파일, CSS 스타일 시트 등)에 대해 브라우저에 특정 유형의 힌트를 제공할 수 있습니다.

이 프로세스는 서버가 기본 페이지 리소스를 렌더링하는 동안 몇 밀리초 이하의 시간 동안 발생합니다.

Early Hints는 "브라우저를 도와주고" 이 로딩 작업을 미리 수행하여 서버가 생각하는 시간을 단축하는 것입니다.

이 때문에 이 프로세스는 결과적으로 페이지 로드 시간을 단축하는 데 도움이 됩니다.

중요한 렌더링 경로를 최적화하는 데 도움이 되는 도구

당신은 뛰어난 코드 마스터가 아니며 코드, 플러그인 및 웹 사이트 후드 아래에 있는 것들로 작업하고 최적화할 수 없습니까?

음, 절대 두려워하지 마세요(너무 많이!). 그렇게 하는 데 도움이 되는 워드프레스 플러그인이 있습니다.

다음은 성공을 위해 중요한 렌더링 경로를 최적화하는 데 사용할 수 있는 도구 목록입니다.

• 중요한 CSS 플러그인 : 이 편리한 도구를 사용하면 사이트에 필요한 중요한 CSS를 생성할 수 있습니다. URL을 추가하고 생성을 클릭하기만 하면 됩니다.
• 페이지 속도 자동 최적화 플러그인: 이 특정 플러그인은 중요한 파일을 연기할 수 있는 또 다른 페이지 속도 플러그인입니다. 또한 인라인 CSS를 페이지 머리글에 삽입하고 스크립트를 바닥글로 옮기고 HTML 파일을 축소하는 데 도움이 됩니다.
• WP Rocket Page Speed ​​플러그인: 이 페이지 속도 플러그인은 가장 강력한 캐싱 플러그인 중 하나입니다. 설치 후 이 특정 플러그인을 사용하면 페이지 캐싱, GZIP 압축, 캐시 사전 로드 및 브라우저 캐싱을 활용할 수 있습니다.
• WP-최적화: 이것은 빠른 로드 시간을 위해 사이트를 더 잘 최적화하는 데 도움이 되는 몇 가지 작업을 수행할 수 있는 WordPress 플러그인입니다. 여기에는 CSS 및 JavaScript 파일 축소 및 비동기화와 함께 데이터베이스 최적화, 이미지 압축 및 페이지 캐싱이 포함됩니다.

참고: 이 작성자는 이러한 도구에 대해 금전적 편견이 없습니다.

왜 관심을 가져야 합니까?

Google의 사용자 행동 데이터에 따르면 대부분의 사용자는 약 3초 후에 느린 사이트를 이탈합니다.

페이지 로드 시간을 줄이고 페이지 경험을 개선하면 사용자 만족도가 높아진다는 연구 결과 외에도 준비해야 할 몇 가지 주요 Google 업데이트가 있습니다.

렌더링 차단 리소스를 식별하고 최적화하는 것은 이러한 업데이트가 적용되었을 때 게임을 최상으로 유지하는 데 매우 중요합니다.

Google은 2022년에 데스크톱에서 페이지 경험을 구현하고 2월에 데스크톱 페이지 경험을 시작하여 3월에 완료할 예정입니다.

Google에 따르면 동일한 세 가지 Core Web Vitals 메트릭(LCP, FID 및 CLS)이 관련 임계값과 함께 이제 데스크톱 순위에 연결됩니다.

또한 Google은 최대 이벤트 기간과 총 이벤트 기간을 고려하여 완전히 새롭고 실험적인 Core Web Vitals 지표를 개발하고 있습니다.

그들이 고려하고 있는 이러한 요인에 대한 설명은 다음과 같습니다.

최대 이벤트 기간: 상호 작용 대기 시간은 상호 작용 그룹의 모든 이벤트에서 가장 큰 단일 이벤트 기간과 같습니다.
총 이벤트 기간: 상호작용 대기 시간은 모든 이벤트 기간의 합계이며 중복은 무시됩니다.

페이지 로드 시간 감소를 귀중한 KPI(전환율, 이탈률, 사이트에 머문 시간) 개선과 연결하는 많은 연구를 통해 사이트 대기 시간 개선은 많은 조직에서 최우선 비즈니스 목표가 되었습니다.

우리의 역할은 종종 비즈니스 목표와 웹 개발자의 우선 순위 사이의 격차를 해소하는 것이므로 SEO 전문가는 이러한 노력을 안내할 수 있는 고유한 위치에 있습니다.

사이트를 감사하고, 결과를 분석하고, 개선이 필요한 영역을 식별하는 능력은 개발자와 협력하여 성능을 개선하고 결과를 주요 이해 관계자에게 전달하는 데 도움이 됩니다.

렌더링 차단 리소스 최적화의 목표

중요한 렌더링 경로를 최적화하는 주요 목표 중 하나는 스크롤 없이 볼 수 있는 중요한 콘텐츠를 렌더링하는 데 필요한 리소스가 최대한 빨리 로드되도록 하는 것입니다.

모든 렌더링 차단 리소스와 페이지의 빠른 렌더링을 방해하는 모든 리소스의 우선 순위를 낮춰야 합니다.

각 최적화 지점은 페이지 속도, 페이지 경험 및 Core Web Vitals 점수의 전반적인 향상에 기여합니다.

렌더링 차단 CSS를 개선해야 하는 이유는 무엇입니까?

구글은 코딩이 순위에 반드시 중요한 것은 아니라고 여러 번 말했습니다.

그러나 동일한 토큰으로 페이지 속도 최적화 개선으로 순위 이점을 얻는 것은 쿼리에 따라 잠재적으로 도움이 될 수 있습니다.

CSS 파일의 경우 렌더링 차단 리소스로 간주됩니다.

왜 이런거야?

대부분의 경우 밀리초 이내에 발생하더라도 브라우저는 모든 CSS 스타일을 요청, 수신 및 처리할 수 있을 때까지 페이지 콘텐츠 렌더링을 시작하지 않습니다.

브라우저가 스타일이 제대로 지정되지 않은 콘텐츠를 렌더링하면 스타일이 지정되지 않은 일반 텍스트와 링크만 보게 됩니다.

이것은 귀하의 페이지가 더 나은 용어가 없기 때문에 기본적으로 "네이키드"임을 의미합니다.

CSS 스타일을 제거하면 문자 그대로 사용할 수 없는 페이지가 생성됩니다.

대부분의 콘텐츠는 사용자에게 최소한의 입맛에 맞는 것처럼 보이도록 다시 칠해야 합니다.

페이지 렌더링 프로세스를 살펴보면 아래의 회색 상자는 모든 CSS 리소스를 가져오는 데 필요한 브라우저 시간을 나타냅니다. 이렇게 하면 CSS(또는 CCSOM 트리)의 DOM 구성을 시작할 수 있습니다.

이러한 리소스를 로드하기 위해 서버에서 수행해야 하는 작업에 따라 밀리초에서 몇 초까지 걸릴 수 있습니다.

또한 이러한 CSS 파일의 크기와 수량에 따라 달라질 수 있습니다.

다음 렌더링 트리는 DOM 내에서 CSS와 함께 모든 파일을 렌더링하는 브라우저의 예를 보여줍니다.

Medium의 스크린샷, 2022년 11월

또한 다음은 모든 파일이 로드되는 페이지의 렌더링 순서에 대한 예를 보여줍니다. 이 과정에서 DOM의 구성부터 페이지의 최종 페인팅 및 합성에 이르기까지 이를 핵심 렌더링 경로라고 합니다. .

CSS는 기본적으로 렌더링 차단 리소스이므로 페이지 렌더링 프로세스에 부정적인 영향을 미치지 않는 지점까지 CSS를 개선하는 것이 좋습니다.

공식 Google 권장 사항은 다음과 같습니다.

“CSS는 렌더링 차단 리소스입니다. 첫 번째 렌더링 시간을 최적화하기 위해 가능한 한 빨리 클라이언트에게 전달하십시오.”

HTML은 브라우저가 작업할 수 있는 DOM으로 변환되어야 합니다. CSS 파일도 같은 방식입니다. 이것은 CSSOM으로 변환되어야 합니다.

DOM 및 CSSOM 내에서 CSS 파일을 최적화하면 브라우저가 모든 것을 렌더링하는 데 걸리는 시간을 줄일 수 있으므로 향상된 페이지 경험에 크게 기여할 수 있습니다.

렌더링 차단 JavaScript를 개선하는 이유는 무엇입니까?

자바스크립트 로딩이 항상 필요한 것은 아니라는 사실을 알고 계셨나요?

JavaScript를 사용하면 모든 JavaScript 리소스를 다운로드하고 구문 분석하는 것이 페이지를 완전히 렌더링하는 데 필요한 단계가 아닙니다.

따라서 이것은 실제로 페이지 렌더링의 기술적으로 필요한 부분이 아닙니다.

그러나 이에 대한 주의 사항은 다음과 같습니다. 대부분의 최신 사이트는 스크롤 없이 볼 수 있는 경험을 렌더링하기 위해 JavaScript(예: Bootstrap JS 프레임워크)가 필요한 방식으로 코딩되어 있습니다.

그러나 브라우저가 페이지의 첫 번째 렌더링 전에 JavaScript 파일을 찾으면 나중에 JavaScript 파일이 완전히 실행될 때까지 렌더링 프로세스가 중지될 수 있습니다.

그렇지 않으면 나중에 사용할 수 있도록 JavaScript 파일을 연기하여 지정할 수 있습니다.

이에 대한 한 가지 예는 HTML에 내장된 경고와 같은 JS 기능이 있는 경우입니다. 이로 인해 이 JavaScript 코드가 실행될 때까지 페이지 렌더링이 중지될 수 있습니다.

JavaScript는 HTML 및 CSS 스타일을 모두 수정할 수 있는 유일한 권한을 가지고 있으므로 이는 의미가 있습니다.

JavaScript가 잠재적으로 전체 페이지 콘텐츠를 변경할 수 있기 때문에 JavaScript의 구문 분석 및 실행이 지연될 수 있습니다. 이 지연은 기본적으로 브라우저에 내장되어 있습니다. 이러한 "만약의 경우" 시나리오를 위한 것입니다.

공식 Google 추천:

“JavaScript는 페이지가 렌더링될 때 DOM 구성 및 지연을 차단할 수도 있습니다. 최적의 성능을 제공하려면 … 중요한 렌더링 경로에서 불필요한 JavaScript를 제거하십시오.”

렌더링 차단 리소스를 식별하는 방법

중요한 렌더링 경로를 식별하고 중요한 리소스를 분석하려면:

• webpagetest.org를 사용하여 테스트를 실행하고 "폭포" 이미지를 클릭합니다.
• 녹색 "렌더링 시작" 라인 이전에 요청되고 다운로드된 모든 리소스에 집중하십시오.

폭포 보기를 분석하십시오. 녹색 "렌더링 시작" 라인 전에 요청되었지만 스크롤 없이 볼 수 있는 콘텐츠를 로드하는 데 중요하지 않은 CSS 또는 JavaScript 파일을 찾습니다.

WebPageTest의 스크린샷, 2022년 11월

(잠재적으로) 렌더링 차단 리소스를 식별한 후 이를 제거하여 스크롤 없이 볼 수 있는 콘텐츠가 영향을 받는지 확인합니다.

내 예에서 중요할 수 있는 일부 JavaScript 요청을 발견했습니다.

중요하긴 하지만 때때로 이러한 스크립트 제거를 테스트하여 사이트의 변화하는 요소가 경험에 어떤 영향을 미치는지 테스트하는 것이 좋습니다.

WebPageTest의 스크린샷, 2022년 11월

이러한 리소스를 개선하는 다른 방법도 있습니다.

중요하지 않은 JavaScript 파일의 경우 페이지 하단에 이러한 파일을 포함하여 파일을 결합하고 연기하는 방법을 살펴볼 수 있습니다.

중요하지 않은 CSS 파일의 경우 하나의 파일로 결합하고 압축하여 가지고 있는 CSS 파일 수를 줄일 수도 있습니다.

코딩 기술을 개선하면 파일 다운로드 속도가 빨라지고 페이지의 렌더링 속도에 미치는 영향이 줄어들 수 있습니다.

페이지에서 렌더링 차단 요소를 줄이는 방법

렌더링 차단 리소스가 스크롤 없이 볼 수 있는 부분의 콘텐츠를 렌더링하는 데 중요하지 않다고 판단되면 페이지 렌더링을 개선하고 중요하지 않은 리소스를 연기하기 위해 사용할 수 있는 수많은 방법을 탐색하고 싶을 것입니다.

JavaScript 및 CSS 파일을 연기하는 것부터 CSS가 미칠 수 있는 영향을 줄이는 것까지 이 문제에 대한 많은 솔루션이 있습니다.

한 가지 가능한 해결책은 @import 규칙을 사용하여 CSS를 추가하지 않는 것입니다.

@Import 규칙을 사용하여 CSS를 추가하지 않도록 확인

성능 관점에서 보면 @import가 HTML 파일을 깔끔하게 유지하는 것처럼 보이지만 실제로는 성능 문제를 일으킬 수 있습니다.

@import 선언은 실제로 브라우저가 CSS 파일을 더 느리게 처리하도록 합니다. 왜요? 가져온 파일도 모두 다운로드하기 때문입니다.

프로세스가 완료될 때까지 렌더링이 완전히 차단됩니다.

실제로 가장 좋은 해결책은 HTML에서 <link rel=”stylesheet”> 선언을 사용하여 CSS 스타일시트를 포함하는 표준 방법을 사용하는 것입니다.

CSS 및 JavaScript 파일 축소

WordPress를 사용하는 경우 플러그인을 사용하여 CSS 및 JavaScript 파일을 축소하면 엄청난 영향을 미칠 수 있습니다.

축소 프로세스는 파일 내의 모든 불필요한 공간을 가져오고 더 압축하므로 멋진 성능 향상을 얻을 수 있습니다.

또한 WordPress를 사용하지 않더라도 자격을 갖춘 개발자의 서비스를 사용하여 프로세스를 수동으로 완료할 수 있습니다.

시간이 더 걸리지만 그만한 가치가 있습니다.

축소된 파일은 일반적으로 이전 파일보다 훨씬 가볍습니다. 즉, 초기 렌더링이 훨씬 빠르게 완료됩니다.

이 외에도 축소 프로세스 이후에는 렌더링되지 않는 리소스를 다운로드하는 데 필요한 시간이 줄어들기 때문에 다운로드 프로세스가 더 빨라질 수도 있습니다.

타사 글꼴 대신 시스템 글꼴 사용

타사 글꼴이 사이트를 "더 예쁘게" 만드는 것처럼 보일 수 있지만 꼭 그렇지는 않습니다.

표면적으로는 멋져 보일 수 있지만 이러한 타사 글꼴 파일은 종종 로드하는 데 시간이 오래 걸리고 렌더링 차단 리소스 문제에 기여할 수 있습니다.

외부 파일로 인해 브라우저는 페이지를 렌더링하기 위해 이러한 파일을 다운로드하도록 외부 요청을 해야 하므로 다운로드 시간이 상당히 길어질 수 있습니다.

이상적이지 않은 개발 모범 사례가 있는 팀에 속한 경우 사이트를 렌더링하는 데 필요하지 않은 타사 글꼴 파일이 많다는 것은 당연할 수 있습니다.

이 경우 이러한 불필요한 파일을 모두 제거하면 렌더링 차단 리소스를 크게 개선하고 Core Web Vitals의 전반적인 개선에 기여할 수 있습니다.

반면에 시스템 글꼴을 사용하면 외부 요청 없이 브라우저 내에서만 처리가 유지됩니다.

또한 사용하는 타사 글꼴과 매우 유사한 시스템 글꼴이 있을 수 있습니다.

그러나 반드시 타사 글꼴을 사용해야 하는 경우 타사 글꼴의 특정 측면과 관련된 문제를 완화하는 데 도움이 되는 두 가지 작업이 있습니다.

첫째, 미리 로드 및 글꼴 교환과 함께 사용하면 타사 글꼴 문제가 문제가 되지 않습니다.

타사 글꼴을 사용할 때의 또 다른 문제는 글꼴 자체가 로드될 때까지 글꼴이 보이지 않아 Core Web Vitals 및 사용자 경험에 부정적인 영향을 미친다는 것입니다. 이를 방지하기 위해 font-swap CSS를 사용할 수 있습니다.

작동 방식은 다음과 같습니다 . 글꼴 교환 CSS는 특정 글꼴을 사용하는 텍스트는 시스템 글꼴을 사용하여 즉시 표시되어야 한다고 브라우저에 설명합니다. 사용자 정의 글꼴이 준비되면 이 사용자 정의 글꼴이 시스템 글꼴을 대체합니다. 이것은 페이지 로드 중에 보이지 않는 글꼴을 방지하는 데 사용할 수 있는 가장 효과적인 방법입니다.

The New Kid On The Block: 가변 글꼴

2020년부터 가변 글꼴은 대부분의 브라우저에서 널리 지원됩니다. 가변 글꼴이란 정확히 무엇입니까?

가변 글꼴을 사용하면 모든 글꼴 스타일이 단일 파일에 포함됩니다. 그러나 가변 글꼴이 보편화되기 전에는 글꼴에 대해 여러 개의 개별 글꼴 파일이 필요했습니다.

또한 가변 글꼴을 사용하면 다음과 같은 몇 가지 이점이 있습니다.

• 더 작은 파일 크기: 가변 글꼴은 너비, 두께 및 기타 속성의 모든 변형을 포함하는 단일 글꼴 파일이기 때문에 파일 크기가 더 작습니다.
• 보다 유연한 디자인 범위: 다른 유형의 글꼴을 사용하는 경우 사이트의 디자인 언어/음성을 각각 표현하려면 3~5개의 서로 다른 글꼴 파일이 필요합니다. 그리고 여기에는 제목, 본문 카피 등의 모든 순열이 포함됩니다. 그러나 가변 글꼴을 사용하면 단일 글꼴 파일을 사용하여 글꼴 디자인과 연관될 수 있는 모든 가능한 변형을 활용할 수 있습니다.
• 적은 수의 파일만: 이 파일 크기 절약으로 인해 페이지 크기를 더 압축하고 페이지 속도를 줄이는 데 도움이 됩니다. 그리고 단일 파일 이점 자체를 통해 웹마스터는 페이지 속도를 훨씬 더 압축할 수 있습니다.

다음 문서에서는 가변 글꼴과 이를 구현하는 방법에 대해 설명합니다. 타사 글꼴을 반드시 구현해야 하는 경우 이러한 이점 때문에 가변 글꼴을 사용하는 것이 허용되는 대안입니다.

코딩 기술 및 파일 결합 향상

코드로 직접 작업하는 경우 기술이 최적이 아님을 알 수 있습니다(또는 아무도 판단하지 않을 수 있음).

한 가지 예: 모든 곳에서 인라인 CSS를 사용하고 있으며 이로 인해 브라우저 내에서 처리 및 렌더링 결함이 발생합니다.

쉬운 해결책은 모든 인라인 CSS를 가져와서 CSS 스타일시트 파일 내에서 적절하게 코딩하는지 확인하는 것입니다.

다른 개발자의 코드가 최신 상태가 아닌 경우 페이지 렌더링에 중대한 문제가 발생할 수 있습니다.

예를 들어, 현대적이고 간결한 기술이 아닌 이전 기술을 사용하여 코딩된 페이지가 있다고 가정해 보겠습니다.

이전 기술에는 상당한 코드 부풀림이 포함되어 결과적으로 페이지 렌더링 속도가 느려질 수 있습니다.

이를 제거하기 위해 더 간결하고 덜 부푼 코드를 만들어 코딩 기술을 개선하여 훨씬 더 나은 페이지 렌더링 경험을 얻을 수 있습니다.

파일을 결합하면 상황을 개선할 수도 있습니다.

예: 모두 동일한 작업에 기여하는 8개 또는 10개의 JavaScript 파일이 있는 경우 이러한 파일을 모두 결합할 수 있는 개발자를 고용할 수 있습니다.

덜 중요한 JavaScript 파일인 경우 페이지 렌더링 문제를 더 줄이기 위해 이러한 파일을 페이지의 HTML 코드 끝에 추가하여 연기할 수도 있습니다.

파일을 결합하고 코딩 기술을 개선하면 더 나은 페이지 렌더링 환경에 크게 기여할 수 있습니다.

주요 테이크 아웃

렌더링 차단 리소스를 찾고 줄이기 위한 고유한 프로세스를 만들고 싶다면 이제 그렇게 할 수 있는 도구가 있습니다. 프로세스는 다음과 같이 설명됩니다.

• 1단계: Screaming Frog 또는 기타 크롤링 도구를 사용하여 사이트를 크롤링합니다.
• 2단계: 페이지 속도가 느린 페이지를 식별합니다.
• 2a단계: 이 용도로 Google Search Console 또는 Google Analytics를 사용할 수도 있습니다.
• 3단계: 우선 순위가 지정된 목록에서 찾은 성능이 가장 낮은 페이지를 정렬합니다.
• 4단계: 위의 체크리스트 항목으로 이동하고(원하는 경우 페이지당 각 항목의 스프레드시트를 만들 수도 있음) 필요에 따라 이러한 렌더링 차단 리소스를 찾거나 줄이거나 복구합니다.
• 5단계: 사이트의 모든 페이지를 헹구고 반복합니다.

아이디어는 쉽게 확장 가능하고 쉽게 구현되며 결과적으로 훨씬 더 작은 페이지 속도로 성공의 길로 안내할 수 있는 프로세스를 만드는 것입니다.

이 프로세스를 통해 귀하도 얻게 될 이점의 이점을 누릴 수 있으며 Google의 Core Web Vitals에서 향상을 경험할 수도 있습니다.

렌더링 차단 리소스를 식별하고 복구하는 것은 대부분의 감사에서 이 단계를 특징으로 하는 속도 최적화의 중요한 부분입니다. 그 이유는 순위 페이지에 대해 가능한 최상의 렌더링 시간을 생성하는 데 도움이 되기 때문입니다.

Google은 항상 페이지 속도를 개선하기 위해 노력하고 있습니다. 그러나 항상 일관된 한 가지가 있습니다. 페이지 속도가 빠를수록 좋습니다.

이 작업을 신속하게 수행할 수 있는 확장 가능한 프로세스를 통합하면 가장 크고 복잡한 페이지 속도 최적화 프로젝트도 비교적 쉽게 처리할 수 있습니다.

그리고 이것은 또한 더 나은 사용자 경험으로 이어집니다.

렌더링 차단 리소스를 찾아 복구함으로써 사용자가 사이트를 경험하는 방식을 개선할 수 있으며 웹 사이트 방문자를 계속 만족시킬 수 있습니다.

After all, keeping your site in top shape for prime time is what all of this optimization work is all about!

추가 리소스:

• Advanced Core Web Vitals: A Technical SEO Guide
• Difference Between Search Console CWV Report & PageSpeed Insights
• Core Web Vitals: A Complete Guide

Featured Image: SuperOhMo/Shutterstock