Next, Nest, Nuxt… Nust? #

웹앱은 연관성이 있는 정보를 빠르게 전달하면서도 검색엔진으로 검색해서 찾기 쉬워야 합니다.

Web Vitals #

웹앱의 성능척도는 보통 Google Chrome 팀에서 소개한 Web Vitals라고 불리는 항목들로 확인할 수 있습니다.

Time to First Byte(TTFB) #

요청 이후, 서버 응답의 첫번째 byte가 클라이언트로 돌아올 때 걸리는 시간입니다.

First Paint(FP) #

요청 이후, 화면에 페이지가 보여지기 시작하기 직전까지 시간으로 "TTFB + 브라우저 렌더링 computation 시간"과 동일합니다.

First Contentful Paint(FCP) #

요청 이후, 화면에 첫번째 텍스트나 이미지 등의 painting이 시작하는데 걸리는 시간으로 "사용자에게 computation 이후 렌더링이 시작한다는 것을 알려주는 시점까지 시간"과 동일합니다.

Largest Contentful Paint(LCP) #

요청 이후, 가장 큰 텍스트나 이미지 등의 painting이 시작하는데 걸리는 시간으로 "사용자가 원하는 페이지가 완전히 나타날 때까지 시간"입니다.

Time to Interactive(TTI) #

요청 이후, 페이지에 반응성이 부여되기까지 걸리는 시간으로 LCP와 TTI는 거의 동일해야 정상동작하는 것으로 사용자가 인식할 수 있습니다.

렌더링 전략 #

사용자 계정별, 현재 상태별, 접근방식별로 웹 컨텐츠가 달라지려면 동적(조건/반복문에 의한) 컨텐츠를 생성해야 합니다.

클라이언트 단에서 DOM을 생성/수정/삭제하는 JS코드를 언제, 어디서 실행하느냐에 따라 rendering strategy가 달라집니다.

CSR #

서버 단에서 전달한 JS코드로 첫 렌더링부터 DOM을 생성하고 중간에 필요할 때마다 HTTP 요청을 전송하고 DOM을 조작합니다.

장점 #

• 모든 DOM 연산들이 클라이언트에서만 일어나므로 확장성(UI?)이 용이하고 브라우저의 Web API를 사용할 수 있습니다.
• 서버에서는 정적인 JS 코드만 전달만 하면 되기 때문에 요청 이후 응답이 올 때까지 시간이 오래 걸리지 않습니다.

단점 #

• 단일 JS 번들이 브라우저에 load + DOM 구성하는데까지 시간이 걸려서 페이지의 첫 렌더링이 지연될 수 있습니다. 그래서 첫 로딩이 완료될 때까지 splash screen을 노출하여 잠시 대기 중 메시지를 줄 수 있습니다.
• 검색엔진 웹 크롤러가 웹 페이지가 load되어 interactive 상태가 될 때까지 기다리지 않기 때문에 SEO에 불리합니다.

SSR #

클라이언트 요청이 오면 서버에서 HTML 파일(+ script tag + link rel="stylesheet")을 동적으로 생성하여 응답으로 전달합니다.

장점 #

• 이미 만들어진 웹페이지를 받으므로 SEO 최적화에 유리합니다.
• 첫 페이지 로딩속도가 CSR보다 빠릅니다.

단점 #

• 요청이 가고나서 서버 단에서 연산이 일어나므로 응답이 올 때까지 걸리는 시간이 CSR보다 깁니다.
• 서버 단의 연산량이 늘어나서 확장성이 어렵습니다.
• 사용자별로 비슷한 모양의 페이지가 노출된다면 비슷한 연산의 중복이 발생합니다.

SSG #

기존 on-demand 방식이 아닌 web app을 빌드 초반에 dynamic page들을 미리 만들어두고 나중에 요청이 올 때마다 pre-computed 페이지를 응답으로 전달합니다.

장점 #

• CSR, SSR의 단점(computing 지연)을 해결하고 확장성이 용이합니다.
• 중복된 연산을 줄여서 리소스를 절약할 수 있습니다.

단점 #

• SSG로 만들어진 페이지들은 사용자가 누구든지 모두 동일한 내용을 볼 수 있습니다.
• 페이지 내의 사소한 변경사항이 있을 때 전체 web app을 재빌드해야 한다는 번거로움이 있습니다. 그래서 해결책으로 첫 요청이 왔을 때만 computing을 하고 그 뒤에는 생성된 페이지를 응답으로 전달하는 incremental, deferred generation 방식이 있습니다.

Hybrid #

CSR, SSR, SSG는 공통적으로 html 파일을 생성하는 computation을 클라이언트와 서버 둘 중 하나에서만 전담합니다.

장점 #

• 서버에서 미리 렌더링해서 정적인 html을 구성하고 브라우저 단에서 html 파싱 중 다운로드한 script로 사용자별로 다르게 보일 내용을 렌더링하거나 반응성을 부여(hydrate)합니다.
• 페이지가 로드되는 속도가 빠르고 이미 렌더링된 페이지라서 SEO에 유리합니다.

단점 #

• 클라이언트와 서버에서 렌더링할 부분을 어떻게 분담할지 결정하는게 쉽지 않습니다.

보통 실무에서 위 4가지를 포함한 다수 rendering 기법들을 페이지별, 용도별 다르게 적용하는데 이 부분은 웹 프레임워크를 활용하면 구현하기가 용이해집니다.

참고자료 #

Next, Nest, Nuxt… Nust?