웹 사이트 1초 이내 렌더링하기

개요,

구글은 모바일 네트워크에서 1초 내에 페이지를 렌더링하도록 권장하고 있다. 렌더링 시간이 1초 이상 지연되면 사용자의 흐름이 끊겨 사용환경이 저하된다고 한다. 그래서 우리는 전체 페이지를 로딩하지 않고 사용자가 인지할 수 있는 영역을 최대한 빠르게 로딩하여 상호작용이 가능하도록하고 스크롤 아랫부분을 백그라운드에서 로딩하도록 한다.

 

여전히 ATF(Above the fold) 를 사용해야하는 이유다.

 

여전히 ATF(Above the fold) 를 사용해야하는 이유

 

 

 

 

웹 사이트 로딩 시간 분석

 

 

모바일 네트워크는 전세계에서 가장 많이 사용하는 4G(LTE) 기준으로 테스트를 진행하는 것을 권장한다.

브라우저와 서버 간의 일반적인 흐름을 보면 DNS를 조회하고 TCP 핸드쉐이킹, TLS 연결 등 네트워크 오버타임에 약 300ms 정도 소요된다고 한다. 그럼 우리가 제어할 수 있는 남은 시간은 700ms 이며 HTTP 연결해서 서버에서 수행한 결과를 전송하고 클라이언트의 자바스크립트와 화면 렌더링 수행을 완료해야 한다.

이 많은 일을 우리는 700ms 이내 처리하는 것이 사용자에게 최적의 사용환경을 제공하는 방법인 것이다.

 

참고로 한국은 모바일 인터넷 속도가 세계 1위인 점을 감안하여 네트워크에 제한을 두고 테스트하는 것도 좋다.

또한 모바일기기에 탑재된 칩과 스토리지에 따라 I/O와 렌더닝 성능의 차이도 감안해야 할 것이다.

 

 

 

 

1초 렌더링 환경 제공하기,

구글의 PageSpeed Insight 모바일 웹 사이트 가이드

 

• 서버가 응답을 200 ms 이내로 렌더링해야 합니다. 
   서버 응답 시간은 서버가 초기 HTML을 반환하는 데 걸리는 시간에서 네트워크 전송 시간을 제외한 시간입니다. 시간이 많지 않으므로 이 시간은 최소(200 ms 이내)로 유지해야 합니다.
   먼저 서버에서 운영체제의 최신 버전을 실행 중인지 확인하세요. 증가된 초기 TCP 혼잡 윈도우(IW10)를 활용하려면 Linux 커널 2.6.39 이상이 필요합니다. 다른 운영체제의 경우 도움말을 참조하세요. 서버 응답 시간을 최적화하려면 코드를 계측하거나 애플리케이션 모니터링 솔루션을 사용하여 병목 현상(예: 스크립트 런타임, 데이터베이스 호출, RPC 요청, 렌더링 등)을 확인하세요. 200 ms 이내에 HTML 응답을 렌더링하는 것이 목표입니다.
• 리디렉션 수를 최소화해야 합니다. 
   HTTP 리디렉션이 추가되면 네트워크 왕복이 1~2번 더 발생하여(추가 DNS 조회가 필요한 경우 2회) 4G 네트워크에서 수백 밀리초의 추가 지연 시간이 생깁니다. 따라서 리디렉션 수를 최소화하거나 가능하면 완전히 없애는 것이 좋습니다. 이는 특히 HTML 문서에서 중요하며, 가능한 경우 'm.' 리디렉션을 사용하지 않아야 합니다.
• 첫 렌더링을 위한 왕복 수를 최소화해야 합니다. 
   TCP에서 연결 용량을 추정하는 방법(예: TCP 느린 시작)으로 인해 새로운 TCP 연결은 클라이언트와 서버 간에 사용 가능한 전체 대역폭을 즉시 사용할 수 없습니다. 이로 인해 서버는 새로운 연결의 첫 번째 왕복에서 최대 10개의 TCP 패킷(~14 KB)을 보낸 후 클라이언트에서 이 데이터를 확인할 때까지 기다린 뒤에야 혼잡 윈도우를 늘리고 더 많은 데이터를 전송할 수 있습니다. 
   또한 10개의 패킷 수(IW10) 제한은 최신 TCP 표준에서 추가된 것이므로 이 변경사항을 활용하려면 서버를 최신 버전으로 업그레이드해야 합니다. 업그레이드하지 않으면 패킷 수가 3~4개로 제한될 수 있습니다. 
   이러한 TCP 동작으로 인해, 콘텐츠를 최적화하여 페이지의 첫 렌더링에 필요한 데이터를 전송하는 데 요구되는 왕복 수를 최소화하는 것이 중요합니다. ATF 콘텐츠 크기가 98 KB 미만인 것이 바람직합니다. 그러면 브라우저가 단 3번의 왕복 후에 페이지를 표시할 수 있어서 서버 응답 지연 시간과 클라이언트 렌더링을 위한 시간이 충분히 확보됩니다. 
   페이지의 콘텐츠가 클라이언트 측 자바스크립트로 구성된 경우, 추가 네트워크 왕복을 피하기 위해 관련 자바스크립트 모듈을 삽입하는 것을 고려해야 합니다. 마찬가지로 서버 측 렌더링을 활용하면 첫 페이지 로드 성능을 대폭 개선할 수 있습니다. 즉, 서버에서 JS 템플릿을 렌더링하고 그 결과를 HTML에 삽입한 다음 애플리케이션이 로드된 후 클라이언트측 템플릿을 사용하는 것입니다.
  
• 스크롤 없이 볼 수 있는 콘텐츠에 외부 차단 자바스크립트와 CSS를 사용하지 않습니다. 
   브라우저는 페이지를 파싱한 후에야 사용자를 위해 페이지를 렌더링할 수 있습니다. 파싱하는 동안 비동기가 아닌 스크립트 또는 외부 차단 스크립트가 있으면 파싱을 중지하고 그 리소스를 다운로드해야 합니다. 이때마다 네트워크 왕복이 추가되어 페이지의 첫 렌더링 시간이 지연됩니다. 
   따라서 스크롤 없이 볼 수 있는 부분을 렌더링하는 데 필요한 자바스크립트와 CSS는 인라인으로 삽입되어야 하고 페이지에 기능을 더 추가하는 데 필요한 자바스크립트나 CSS는 ATF 콘텐츠가 전송된 후에 로드되어야 합니다.  
   Chrome 개발자 도구에서 감사 패널을 열고 웹페이지 성능 보고서를 실행한 다음 생성된 보고서에서 사용되지 않은 CSS 규칙 삭제를 찾으세요. 또는 다른 타사 도구나 스크립트를 사용하여 각 페이지에 적용된 CSS 선택기를 확인하세요.
   CSP를 사용 중이라면 기본 정책을 업데이트해야 할 수 있습니다. 먼저 가능하면 HTML 요소의 인라인 CSS 속성(예: &lt p style=...&gt)을 피해야 합니다. 이 속성을 사용하면 불필요한 코드 중복이 발생하고 CSP에서 기본적으로 차단됩니다('style-src'에서 'unsafe inline'을 통해 사용 중지됨). CSP를 사용 설정하면 모든 인라인 스크립트 태그가 기본적으로 차단됩니다. 인라인 자바스크립트가 있다면 스크립트 해시 또는 nonce를 사용하거나 'unsafe-inline'을 사용하여 모든 인라인 스크립트가 실행되도록 CSP 정책을 업데이트해야 합니다. 인라인 스타일이 있다면 스타일 해시 또는 nonce를 사용하거나 'unsafe-inline'을 사용하여 모든 인라인 스타일 블록이 처리될 수 있도록 CSP 정책을 업데이트해야 합니다.
• 브라우저 레이아웃 및 렌더링을 위한 시간(200 ms)을 남겨 둡니다. 
   HTML과 CSS를 파싱하고 자바스크립트를 실행하는 프로세스에는 시간과 클라이언트 리소스가 필요합니다. 휴대기기 속도와 페이지 복잡성에 따라 이 프로세스에 수백 밀리초가 걸릴 수 있습니다. 따라서 브라우저 오버헤드에 200 ms를 남겨두는 것이 좋습니다.
• 자바스크립트 실행 및 렌더링 시간을 최적화합니다. 
   복잡한 스크립트와 비효율적인 코드는 실행하는 데 수십, 수백 밀리초가 소요될 수 있으므로 브라우저에서 기본 제공되는 개발자 도구를 사용하여 코드를 프로파일링하고 최적화합니다. 유용한 입문 자료인 Google의 Chrome 개발자 도구 관련 양방향 과정을 참조하세요.
   JQuery와 같은 대부분의 자바스크립트 라이브러리는 페이지 기능을 향상하여 상호작용, 애니메이션, 기타 효과를 더 추가하는 데 사용됩니다. 하지만 이러한 동작 중 상당수는 ATF 콘텐츠를 렌더링한 후 추가하는 편이 안전합니다. 페이지가 로드될 때까지 이러한 자바스크립트의 실행 및 로드를 지연하는 것을 고려해 보세요.

 

 

 

브라우저 리플로우 최소화  |  PageSpeed Insights  |  Google Developers

Lighthouse  |  Tools for Web Developers  |  Google Developers