웹 동작 원리

웹의 역사

~1990년 중반 Static Sites

• 서버에 이미 잘 만들어진 html 문서 ⭕️
• 사용자가 브라우저에 www.hello.com 등의 주소에 접속
• 그럼 서버에 이미 배포되어져 있는 HTML 문서를 받아와서 보여주는 형식
• 👎🏻 페이지 내에서 다른 링크를 클릭하면 다시 서버에서 해당 페이지의 HTML을 받아와서 페이지 전체가 업데이트

1996년 iframe

• 문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그 도입
• 페이지 내에서 부분적으로 문서를 받아와서 업데이트

1998년 ~

• 많이 사용하고 있는 fetch API의 원조 -> XMLHttpRequest API 개발
• HTML문서가 아닌 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있음
• JSON을 자바스크립트를 이용해서 동적으로 HTML 요소를 생성해서 페이지에 업데이트하는 방식

2005년 AJAX

• AJAX를 이용하여 구글에서 Gmail, GooleMaps 등 웹 어플리케이션 개발
• 현재 널리 쓰이고 있는 SPA(Single Page Application)
• 사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와서 부분적으로 업데이트

CSR(Client Side Rendering)

• 클라이언트에서 모든 것을 처리하는 방식
• 서버에서 index라는 HTML 파일을 클라이언트에 전송

• body안에는 root 하나, 어플리케이션에서 필요한 자바스크립트의 링크만 담겨있음
• 그래서 HTML은 텅텅 비어있기 때문에 처음에 접속하면 빈 화면만 보임
• 다시 링크된 어플리케이션 자바스크립트(로직, 프레임워크 및 라이브러리의 소스코드들)를 서버로부터 다운로드 => 사이즈가 커서 다운로드 받는 데 시간이 소요
• 추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음에 Data + app.js를 기반으로 하여 동적으로 HTML을 생성하여 사용자에게 최종적인 어플리케이션을 보여줌
• 👎🏻 사용자가 첫 화면을 보기까지 시간이 오래 소요될 수도 있다는 점
• 👎🏻 좋지않은 SEO
  • SEO (Search Engine Optimization, 검색엔진최적화) : 구글, 네이버와 같은 검색 엔진들이 서버에 등록된 웹사이트를 하나하나씩 돌아다니면서 웹 사이트의 HTML 문서를 분석해서 검색엔진에 등록해서 우리가 검색할 때 웹사이트를 빠르게 검색할 수 있게 도와주는 것
  • CSR에서 사용되어지고 있는 HTML의 body는 대부분 텅텅 비어져 있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움

🚀 사용자가 1) 웹 사이트를 볼 수 있음(TTV:Time To View)과 동시에 2)클릭하거나 인터랙션이 가능(TTI:Time To Interact)

SSR(Server Side Rendering)

• 웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML파일 생성
• 만들어진 HTML파일을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트에게 전송
• 클라이언트 측에서는 잘 만들어진 HTML 문서를 받아와서 바로 사용자에게 보여줌
• 👍🏻 페이지 로딩이 빨라지는 장점
• 👍🏻 모든 컨텐츠가 HTML에 담겨져 있기 때문에 조금 더 효율적인 SEO 가능
• 👎🏻 깜박임 이슈 존재
  • 사용자가 클릭을 하게 되면 전체적인 웹사이트를 다시 서버에서 받아 오는 것과 동일하기 때문에 썩 좋지않은 UX(User Experience, 사용자 경험)를 겪을 수 있음
• 👎🏻 서버 과부하가 걸리기 쉬움
  • 사용자가 많은 제품일수록 사용자가 클릭할 때마다 서버에 요청해서 필요한 데이터를 가지고 와서 HTML을 만들어야 하기 때문
• 👎🏻👎🏻 사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트는 아직 다운로드 받지 못해 여기 저기 클릭시 반응이 없는 경우 발생

🚀 사용자가 1) 웹 사이트를 볼 수 있음(TTV:Time To View)과 2)클릭하거나 인터랙션이 가능(TTI:Time To Interact)한 시간의 단차가 꽤 긴 편

• 기타