-
브라우저가 서버로부터 html 문서를 모두 전달 받음
-
렌더링 엔진은 전달받은 html 문서를 파싱해 dom 트리 구축
-
외부 css 파일과 함께 포함된 스타일 요소 파싱해 cssom 트리 구축
cssom: css object modal로 dom이 어떻게 화면에 표시될 지를 알려줌
-
dom 트리와 cssom 트리를 합쳐 렌더 트리 구축
렌더트리: 화면에 표시되어야 할 모든 노드의 컨텐츠, 스타일 정보를 포함하고 있는 트리
-
렌더 트리의 요소들의 크기와 위치 계산
-
계산된 크기와 위치에 맞게 화면에 출력 (Layout - Paint - Composite)
Layout 계산을 다시 수행하는 것을 Reflow, 픽셀을 렌더링 하는 Paint 작업을 다시 하는 것을 Repaint
Layout 과정에서 reflow가 발생하는 경우
- 요소의 크기나 위치가 바뀔 때
- 브라우저 창의 크기가 바뀌었을 때
Paint 과정에서 repaint가 발생하는 경우
- 배경 이미지, 텍스트 색상 등 레이아웃의 수치를 변화시키지 않는 스타일의 변경이 있을 때
→ 고려하지 않으면 코드가 원하는대로 작동이 되지 않을 수 있음,,
→ 이게 필요한 이유는 브라우저마다 렌더링 엔진이 다르기 때문
Client Side Rendering으로 렌더링이 클라이언트 쪽에서 일어남
-
User가 Website 요청을 보냄
-
CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라로 보냄
CDN: aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 물리적으로 가까운 서버에서 요청에 응답하는 방식
-
클라는 html과 js 다운받음 (이 때 유저는 아무것도 볼 수 없음)
-
생략
-
다운이 완료된 js가 실행됨. 데이터를 위한 api 호출 (이 때 유저는 placeholder를 봄)
-
서버가 api로부터의 요청에 응답
-
api로부터 받아온 data를 placeholder 자리에 넣어줌 → 페이지는 상호작용이 가능해짐!
Server Side Rendering으로 서버쪽에서 렌더링 준비를 끝마친 상태로 클라에게 전달
- User가 Website 요청을 보냄
- Server는 Ready to Render, 즉 즉시 렌더링 가능한 html 파일을 만듦
- 클라에게 전달되는 순간 이미 렌더링 준비가 되어있어 html은 즉시 렌더링 됨, 그러나 사이트는 조작 x
- 클라가 자바스크립트 다운받음
- 다운받아지고 있는 사이 유저는 컨텐츠는 볼 수 있지만 사이트 조작 불가
- 브라우저가 js 프레임워크 실행
- js까지 성공적으로 컴파일 되어 기억하고 있던 사용자 조작이 실행됨 → 페이지는 상호작용이 가능해짐!
- 웹사이트를 로딩하는 시간
- 첫 페이지 로딩 시간 (평균적으로 SSR이 더 빠름)
- 왜냐면.. CSR은 모든 스크립트들을 한번에 불러오는데 SSR은 필요한 부분의 스크립트를 불러오기 때문
- 나머지 로딩 시간
- 첫 페이지 로딩 후 사이트의 다른 곳으로 이동하는 동작이라면?
- CSR은 이미 첫 페이지 로딩할 때 나머지 부분을 구성하는 코드를 받아와서 빠름
- SSR은 첫 페이지를 로딩한 과정을 정확하게 다시 실행해서 더 느림
- 첫 페이지 로딩 후 사이트의 다른 곳으로 이동하는 동작이라면?
- 간편한 사용자 지정과 콘텐츠 업데이트 지원
- 사이트 요소 최적화에 필요한 도구 제공하는 플랫폼으로 웹사이트 제작
- 순위 향상에 도움이 되는 메타데이터, 링크와 같은 세부 사항 신경써야 함
- 웹 크롤러 사용
-
웹페이지가 어떤 콘텐츠를 가지고 있는지 판단
-
해당 페이지가 무엇에 대한 것인지 판단
-
웹 크롤러 작동 과정
- 코드를 스캔해 웹페이지에 표시되는 텍스트, 이미지 등을 수집해 가능한 모든 정보를 얻음
- 각 페이지에서 사용할 수 있는 정보 유형에 대한 충분한 정보를 수집
- 해당 내용이 검색자에게 유용하다고 판단하면 해당 페이지 색인에 추가
-