5. Element render delay 줄이기

여기서의 목표는 리소스의 로드가 완료된 시점에 관계없이 LCP 요소가 즉시 렌더링될 수 있도록 하는 것

LCP 요소가 로드 완료되었음에도 즉시 렌더링되지 않는 주된 이유는 렌더링이 다음의 이유들로 인해 차단되었기 때문임

1. Element render delay 줄이기

이처럼 불필요한 Element render delay를 줄이는 방법은 다음과 같음

스타일 시트(.css)는 CSSOM을 구성해야 하는 리소스이자, 사용자에게 스타일이 적용되지 않은 HTML을 렌더링할 순 없기 때문에 렌더링을 차단하는 리소스로 동작함

하지만 만약 스타일 시트의 파일 사이즈가 너무 커서 네트워크를 통해 스타일 시트를 로드하는 시간이 LCP 요소를 로드하는 시간보다 훨씬 더 오래 걸리는 경우에는 LCP 요소가 로딩 완료되었다고 하더라도 LCP 요소가 렌더링되지 않게 됨

ddd

이를 개선하기 위해서는 다음의 옵션이 있음

index.html


<!-- <link rel="stylesheet" href="style.css"/> -->
 
<!-- .html 내에 인라인 형태로 작성 -->
<style>
    p {
        color: red;
    }
</style>

스타일 시트의 크기를 줄이기 위한 몇 가지 권장사항
사용하지 않는 CSS 제거
중요하지 않은 CSS는 지연 로딩
CSS 축소, 압축

JavaScript 역시 브라우저의 HTML 요소들을 파싱하는 과정을 차단하기 때문에 결과적으로 스타일 시트처럼 렌더링을 차단하는 리소스로 동작함

따라서 async나 defer를 사용하지 않은 동기식 스크립트는 대부분 성능에 부정적인 영향을 미침

금지 사항


<head>
    <script src="server.com/main.js"></script>
</head>

특정 JS 코드가 페이지 로딩 과정에서 최대한 빨리 실행되어야 하는 경우 렌더링이 지연되지 않도록 인라인으로 처리하는 방식이 권장됨

하지만 스타일 시트와 마찬가지로 스크립트의 사이즈가 작은 경우에만 인라인으로 처리하는 것이 좋음

권장 사항


<head>
    <script>
        // 적은 분량을 가진 코드만 인라인으로 활용하기
    </script>
</head>

서버 사이드 렌더링(SSR) 은 서버 측에서 대부분 완성된 형태의 HTML 마크업을 생성하여 클라이언트 브라우저에게 응답하는 렌더링 방식을 말함
→ 추후 Next.js에서 학습 및 활용 예정

LCP를 개선하는 측면에서 SSR의 주요 이점은 크게 두 가지가 있음

반대로 SSR의 단점은 그만큼 서버가 HTML 마크업을 작업, 처리하는 시간이 길어지므로 TTFB가 느려질 수 있음

하지만 서버의 처리 시간은 개발자가 제어할 수 있지만, 사용자가 보유한 디바이스나 네트워크 상황은 제어할 수 없기 때문에 SSR이 더 유의미할 수 있음

💡

Tip

SSG(Static site generation)

운영 중인 서비스에 사용자를 통한 동적인 처리를 수행하는 기능이 없다는 전제 하에 SSR보다 더 유용할 수 있는 옵션
빌드 과정에서 모든 HTML 마크업을 미리 생성해두고 응답하는 방식
→ 본 교안 페이지가 SSG 방식

앞선 개선사항들을 적용했음에도 LCP가 지연될 수 있음

가장 대표적인 원인은 JavaScript의 파일 사이즈가 너무 커서 로딩 시간이 오래 걸리는 경우로,

예를 들어 이미지 리소스가 LCP 요소라고 가정할 때, 이미지는 다운로드가 완료되었다고 하더라도 해당 이미지와 관련이 없는 스크립트를 모두 다운받고 실행을 완료할 때까지 기다려야 렌더링을 수행할 수 있는 상황이 있음

오늘날 대부분의 브라우저는 메인 스레드에서 이미지를 렌더링하는데, 그 말은 메인 스레드를 차단하는 어떤 리소스도 Element render delay를 증가시킬 수 있다는 것을 말함