티스토리 뷰

1.1 SSG(Static Site Generation)

: WS가 페이지를 제공 -> (컴파일 타임에) 미리 렌더링된 페이지를 반환

  • 비 실시간성
  • SEO 가능(서버에서 만들어진 페이지이므로)
  • 서버의 렌더링 부담 제거

출처: ASAC7기 수업자료


1.2  SSR(Server-Side Rendering)

: WS가 페이지를 제공 -> (런타임에) 요청이 올 때마다 렌더링한 페이지를 반환함

  • 실시간성(요청에 따른 실시간 데이터가 반영된 최신 페이지 반환) => 실시간 데이터가 중요한 곳에 이용
  • SEO 가능

출처: ASAC7기 수업자료

-> build의 결과물 == `거대한 JS` 이를 이용하여 빈 HTML을 채울 `템플릿 엔진` 필요

-> `템플릿 엔진`은 Render의 주체로 결과로 view를 생성(이런 식으로 이해)

-> Render가 서버에서 발생하므로 SSR


1.3 CSR(Client-Side Rendering)

: WB가 페이지 제공 -> 매 요청 시, 렌더링 후 페이지 반환

: 앱과 같이 부드러운 페이지 전환을 보임(SSG, SSR의 경우 새로운 페이지를 가져올 때, 흰화면-끊김현상)

  • 실시간성
  • SEO 불가
    -> 웹 크롤러의 경우 js엔진 x
    -> bundled js로 화면을 구성하는 CSR페이지 해석 X
  • 초기 로딩 속도 느림(거대한 JS를 받아야하므로) + 이후 로딩 속도 빠름
  • 화면의 부드러운 이동

출처: ASAC 7기 수업자료

-> Build의 결과물 == `거대한 JS` 이를 이용하여 빈 HTML을 채울 `템플릿 엔진` 필요

-> `템플릿 엔진`은 Render의 주체로 결과로 view를 생성(이런 식으로 이해)

-> Render가 클라이언트에서 발생하므로 CSR


2.1 Static Websites

: 정적 페이지를 반환하는 웹서버(WS) ==> NginX, Apache, S3

: 가장 초기의 웹 페이지 형태로, `미리 만들어진` 정적 웹페이지를 요청에 따라 반환

    -> Ex) 100명의 유저 정보 페이지 = 100명의 유저 정보 페이지

특징 - 서버 불필요
장점 - 서버가 가지고 있는 정적 웹페이지를 반환만 하기에
    -> 매우 빠른 웹페이지 전환 속도
- 구글과 같은 검색 엔진 최적화(SEO)에 유리
단점 - 서버가 반환하고자 하는 모든 정적 웹페이지를 소유
    -> 과한 용량
- 웹 페이지 버전 변경 시, 매번 파일을 변경해줘야 함

출처: ASAC 7기 수업자료

-> 단지 완성된 각각의 페이지가 저장되는 서버 or 스토리지 하나만 필요


2.2 MPA(Multi-Page-Application) = SSR

: 동적 페이지를 반환하는 웹 어플리케이션 서버(WAS) ==> Tomcat(Spring Boot + Thymeleaf)

: 서버가 모든 정적 페이지를 저장하니 많은 용량 필요 -> 이를 해결하기 위해 MPA 등장

    => 서버는 요청 시에 동적 웹페이지를 만들어 반환

    => 반복되는 템플릿과 실시간 정보를 분리

    -> Ex) 100명의 유저 정보 페이지 = 1개의 유저 정보 페이지 템플릿 + 100명의 유저 정보 DB

: SSR의 실시간성 -> 실시간 데이터가 중요한 곳에서 이용

특징 - 서버 필요
장점 -서버다 동적 웹 페이지 생성 및 반환
    -> 각 데이터에 따른 모든 페이지 저장 X, 템플릿과 데이터만 저장
- 구글과 같은 검색엔진 최적화(SEO) 가능 -> 크롤러의 수집 OK
단점 - 서버에서 웹 페이지 생성 및 반환
    -> 유저가 보기까지의 시간이 오래 걸림
    -> 웹서버의 DB 조회속도, 생성 속도에 의존 및 서버 사용량에 따른 비용 부담
  => 비용 문제에 대한 해결: Serverless

 

출처: ASAC 7기 수업자료 -

- 이전 포스트에서 작성한 MVC 패턴을 적용(: 빈 HTML에 템플릿을 통해 요청 페이지 실시간 생성)

    - API or DB: 요청에 따른 데이터(Model) 제공

    - Render(Template E): Model + View Template => View 생성

        - 정적인 코드의 저장소인 storage와 렌더링의 주체인 server 필요

출처: ASAC 7기 수업자료 이전 포스트의 설명과 같이 WAS를 구현하기 위해 CGI로 연결, 나아가 내장 App


2.3 SPA(Single-Page-Application) = CSR

: WB 내 js를 활용해 동적 페이지 생성 ==> js 반환을 위한 WS or Storage필요

: Fast Route Transition(앱과 유사한 UX제공)을 위해 SPA Route 등장

: 요청에 따라 WB가 생성

특징 - 서버 불필요
    -> S3와 같은 저장소 존재 시, 해당
    -> 이 때, 데이터 통신에 이용되는 API 서버 필요함
장점 - WB가 동적 웹 페이지를 생성
    -> 화면 전환 시, 깜빡임 X
단점 - 최적의 UX를 제공하려다 보니 Bundled JS의 크기다 너무 큼
    -> Initial Loading...
- 구글과 같은 검색엔진 최적화(SEO) 불가

출처: ASAC 7기 수업자료
출처: ASAC 7기 수업자료

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
글 보관함