spa
- single page application 페이지 하나에서 해결한다
- 목록 마이페이지 메뉴페이지 카테고리 페이지 처럼 많은데 html 은 하나다
검색과 seo
- search engine optimization 검색 최적화
- 사이트를 만들고 배포하면 바로 배포되지않는데, ex구글에서 크롤러를 해야함(구글봇)
- html을 긁어와서 사이트를 이해하고 배포하는데 결정한다
- 프론트가 태그를 잘써야하는 이유가 이러한 검색시스템 때문이다.
래리 페이지가 구글만들때
페이지 랭크
크롤링 - 웹페이즐ㄹ 방문하여 모든링크를 찾은다음, 이 링크를 목록화한다.
그다음 이 링크들을 이전에 방문한적이 있는지 아닌지 판단함.
현재 검색의 알고리즘
키워드검색과 웹페이지에 담김ㄴ 텍스트비교, 반복석, 키워드, 대문자등등
—-> seo의 중요성
seo- 잘노출되게한다.
우리사이틀가 여기저기 링크되어있어야함
head에 메타정보를 잘넣어야함
public폴더에 인텍스js에 head태그 잘써야함
원래 웹의 역사의 시작은
static website 매우 정적인 사이트다
ex) 페이지 하나하나가 html 하나하나
크롤러는 기계안에서 응답온 html파일 하나를 판단하기때문에,
태그 하나하나를 다 분석 크롤링한다
요즘은 전부 dynamic website이다
csr, ssr
브라우저에서 호출은
프론트에서 html파일을 응답하도록 설정해놓은다
프론트에서 백엔에 api호출하는건 자바스크립트이다
csr client side rendering
예전엔 백엔드에서 호출받고 html을 일일히 동적으로 만들어줘서 보냈다.
프론트엔드가 중간입장으로 새로생김
브라우저에서 요청을하면 미리 가지고 있는 자바스크립트 가 알아서 응답한다.
사이트 유저가 급증함으로서 백엔드에서 서버가 느려지는 상황발생
사이트에 이벤트많아지면서 프론트엔드 위치 중요해짐
동적으로 만들어지는 곳이
하나의 html div태그 하나안에서 여러개의 jsx가 많이 있음
리액트 csr 이자 spa이 검색노출이 잘안되는 이유는 ??
크롤링은 들어가자마자 html만 딱거내서 그 내용만 본다.
-> 그래서 spa 이기때문에 div태그 하나만 있기 때문에 크롤러가 검색에 문제가있음
—> 그래서 검색엔진최적화가 별로 좋지않다.
해결방안
—> ssr server side rendering
무조건 로그인해야하는 페이지 어드민페이지 -> 장고나 리액트로 쉽게만들수잇음
하지만 문제는 노출!!
next.js —ssr에 중요한것!
코드스플리팅 —
ssr장단점
자바스크립트 파일이 너무커서 초기 렌더링이 너무느리다.
장점은 자바스크립트 한번만 가져오면되니까 다른페이지로넘어갈때는 빠르다.
매번 페이지마다 계속 html이 필요한 서버를 요청함
서버지용 증가 유저가 몰릴때 느려질수잇음
넥스트 가 나오기전까지는 spa를 진짜 많이씀
처음에만 느리고 유저의 요청에 따라 페이지가 빠름
단지 검색때문에 csr를 버리기시작 그래서 합쳐진걸 쓰기시작함
처음접근때만 ssr을 사용 그다음엔 csr구조를 쓰는걸 설정하기 시작함
그래서 cra으로는 그게 잘되지않음. eject라는 스크립트가 잇음
이젝트를 실행하는 리액트의 설정파일이 다 풀어져있음 개발자가 직접 커스텀가능 하지만 되돌아갈수없음
그래서 현재의 방식은 ssr과 csr을 합친 방법을 선호/ 많이 사용
