3주 차 다섯 번째 수업 TIL

원티드 프리온 보딩 프론트 앤드 3주 차 다섯 번째 수업  TIL (22.01.24~22.03.03)

프리온 보딩 프론트 앤드의 강사님은 위 코드의 공동 창업자&이사의 직책을 가지고 계신 김예리 님이 강의를 해주셨습니다.

 

 

 

Breakpoint

        데탑 스타일링   |   ipad 스타일링   |   phone 스타일링

                              **`1024px`**             **`768px`** 

• 보통 2개 - 1024 / 768
• 관리 편하게 하려면 1개 - 768

Media Query

미디어 쿼리에 대해 간략하게 설명해주셨고 scss에서 변수로 지정해주고 쉽게 사용하는 방법도 알려주셨습니다

@media only screen and (max-width: 480px) {
	body {
		font-size: 12px;
	}
}

• @media : media 쿼리를 시작
• only screen : 어떤 디바이스에서 적용하는지 알려줍니다. 예를 들면 프린트를 하고 싶을 때 적용하려면 only print라고 작성하면 됩니다. screen이라고 할 경우 어떤 디바이스에 상관없이, 화면에 보이는 스크린이기만 하면 전부 적용됩니다.
• and (max-width : 480px) : 이건 media feature라고 불리는 부분입니다. 어느 조건에 아래의 css를 적용할지 작성해줘야 합니다.

 

 

SCSS에서 관리 쉽게 하기

/* mediaQuery.scss */

$phone: "only screen and (max-width: 768px)";
$desktop: "screen and (min-width: 769px)";

• box.scss

@import './mediaQuery.scss';

.big-box {
	@media #{$phone} {
		display: none;
	}

	@media #{$desktop} {
		display: block;
	}
}

 

 

SPA, CSR, SSR

SPA가 무엇인지?

• 답 : 한개의 페이지를 가지고 js를 이용하여 동적인 사이트를 보여주는 것입니다. 사용자가 링크를 타고 움직일 땐 js에서의 router를 이용하여 해당하는 js컴포넌트로 이동시켜서 보여주는 기술입니다. 장점으로는 동적인 사이트를 만들 때 유용하고 한 번에 모든 것을 렌더링 하지 않고 사용자에게 보여줄 것만 렌더를 하기 때문에 빠르다는 장점이 있습니다. 단점으로는 맨 처음 로딩 화면에서 모든 파일들을 다운로드하고  그 이후엔 요청하지 않기 때문에 로딩 시간이 길어진다는 단점이 있고 그 단점으로 인해 사용자들이 사이트를 나가는 경우가 생길 것입니다.

CSR과 SSR의 차이점은?

• 답 : CSR 은 클라이언트 사이드 렌더링으로 사이트에 html,css,js 파일이 있다면 사용자의 브라우저에서 그 파일들을 가지고 렌더링을 하는 것이고 , SSR은 서버 사이드 렌더링으로 사이트의 html, css, js 파일을 미리 서버에서 렌더링을 하여 사용자에게 보여주는 것의 차이점이 있습니다. 따라서 사용자가 만약 js 파일을 비활성화해놓았다면 CSR에서는 아예 화면이 뜨지 않고 에러 메시지도 출력되지 않지만 SSR에서는 페이지를 구성하는 html 화면은 보여줄 수 있다는 차이점도 있습니다. 그리고 CSR에서는 설정해둔 로딩 중 화면을 실시간으로 보여주며 유저를 붙잡을 수 있다면 SSR에서는 서버에서 렌더링을 끝내고 오기 때문에 화면이 뜨기 전에는 흰 화면을 유지하기에 유저에게 그 시간 동안에는 어떠한 소통도 불가능하고 로딩이 끝난 후 한 번에 모든 것을 보여주는 방식의 차이점 또한 있습니다.

CSR과 SSR 각각의 장단점은?

• 답 : CSR 은사용자에게 로딩 중에 메시지를 준다거나 처음에 사이트 접속할 때 html, css, js 파일을 넘기기에 웹 서버의 호출을 최소화할 수 있다는 장점들이 있습니다. 단점으로는 body에 noscript 태그나 빈 div만이 존재하기 때문에 검색 알고리즘들이 사이트를 판단할 때 비정상적인 사이트로 판단하여 검색 랭킹에 도움이 되는 점수를 안 좋게 줄 확률이 높다는 단점이 있습니다.
• SSR 은 CSR 의 단점인 SEO(Search Engine Optimization)에서 강하다는 장점이 있습니다. 서버에서 모든 렌더를 끝낸 후 동작하기 때문에 검색 엔진이 판단할 때 정상적인 header, content, footer 등의 태그들로 이루어진 사이트로 판단하여 높은 점수를 얻을 수 있습니다. 또한 사용자의 사용 경험적인 입장에서는 사이트가 한 번에 뜨고 동작 또한 모두 되기 때문에 오히려 더 좋은 만족감을 얻을 수도 있다는 장점이 있습니다. 

SSR 하려면 어떻게 해야 하는지?

• 답 : 몇몇의 개발자들은 직접 SSR을 할 서버를 이용해서 직접 하는 것이 낫다고 하는 말 또한 있지만  지금 현재 나와있는 Gatsby NextJS Remix의 프레임워크들을 이용하여 제공해주는 서버와 우리의 코드를 SSR 해주는 컴파일러를 이용하여 SSR을 할 수 있습니다. 또한 CRA로 만들었을 때처럼 index.html 에 모든 파일을 넣는 것이 아닌 pages 폴더에 원하는 route들을 설정하여 각각의 페이지를 만들면 SSR 이 가능합니다.

CSR + SPA로도 SEO를 챙기려면 어떻게 해야 하는지?

• 답 : 리액트에서 React Helmet이라는 라이브러리를 통해 Header 부분에서 meta, title을 적절히 변경시켜 좋은 사이트라는 인식을 검색 엔진에게 줄 수도 있을 것 같고 react-snap이라는 라이브러리를 이용한다면 빌드할 때 html 파일을 만들어두기 때문에 검색 엔진이 크롤링하러 사이트에 들어왔을 때, 빈 껍데기 html 파일 대신 내용물을 가져갈 수 있도록 할 수 있습니다. 아니면 SSR 프레임워크인 NEXT를 이용하여 CSR 만 사용해야 한다고 하면 첫 화면만은 SSR로 만들어 SEO를 챙기고 다른 화면들은 CSR로 만들어 활용할 수 있을 것 같습니다.

 

검색과 SEO

검색에 대한 부분과 마케팅팀에서 노력하는 것뿐만 아니라 프런트 앤드 개발자 또한 링크가 검색이 잘 되게끔 설정해주는 것이 중요하다. 무분별한 div의 사용보다는 HTML5 시멘틱 구조를 이용하여 올바른 인터넷 페이지의 구성요소를 갖춰야 구글에서의 검색 알고리즘이 더 높은 점수를 부여해 회사에 검색 순위가 높아진다는 설명을 해주셨고 이러한 지식이 많이 없었던 저에게 도움이 많이 되는 수업이었습니다.

현재의 검색 알고리즘

• 모든 웹페이지와 수십억 가지의 검색어, 모든 링크를 다 합친 것이 페이지랭크
• → 하나가 아닌 여러 개의 알고리즘으로 구성되어있다.
• →  전통적인 판단 요소를 시그널(signal)이라고 한다. 검색 품질에 대단히 중요한 역할을 한다.

SEO(Search Engine Optimization, 검색 최적화)

🤔 구글 왈

검색엔진 최적화의 효과를 보려면 시간이 다소 걸립니다. 변경을 시작해서 성과가 나타날 때까지 보통 4개월에서 1년 정도 소요됩니다.

사이트를 컴퓨터가 이해할 수 있도록 만든다.

레퍼런스

https://developers.google.com/search/docs/beginner/seo-starter-guide?hl=ko&visit_id=637664932657806093-2379697166&rd=1 

SEO 기본 가이드: 기본사항 | Google 검색 센터  |  Google Developers

웹의 역사와 발전

Web System Architecture History

그동안 웹의 역사와 발전을 들으며 지금 내가 리 엑트를 쓰기까지 무슨 일들이 있었고 왜 이런 방향으로 발전하게 되었는지 알 수 있는 시간이었습니다

 

1세대 웹 - 전통적인 Web System Architecture. 정적 웹.

• 웹 서버가 모든 내용이 담긴 HTML 페이지를 클라이언트(ex. Web browser)에게 전송
• 초창기 웹사이트/서비스에 적합했던 시스템 - 초창기 웹사이트는 단순한 정보 제공 위주였다. 특별히 기능이 많지 않으며, 무엇보다 User Interaction 이 많이 요구되지 않았다.
• 1세대 웹이 정적인 이유? HTML, CSS 자체가 정적
• Hyper Text : 링크로 연결된 문서
• Markup Language : “이렇게 보여줘라”에 대한 지시
• HTML : 웹페이지의 내용을 브라우저에게 어떻게 렌더링(rendering) 해주라고 마크업 해주는 것
• 어떻게 보이는가에 대한 것이기 때문에 로직(동적)이 없다. 정적.

 

 

2세대 웹 - User Interaction의 증가. 동적 웹(자바스크립트)

• 웹서비스들이 점점 발전함에 따라 단순한 정적 페이지가 아닌 다이내믹한 interaction이 요구되어 웹 기반의 언어인 자바스크립트가 출현
• 그러나 아직 JavaScript 는 일부분에서만 사용되었고, 또한 현재 통용되는 API의 개념이 아직은 널리 사용되지 않음 → 동일한 서버에서 HTML, Javascript(프런트 영역) 데이터(백엔드 영역) 둘 다 전송.
  • ex) Django Template, PHP Laravel

 

 

3세대 웹 - SPA(Single Page Application) - 구별되기 시작하는 Frontend와 Backend

• 주객전도. 동적인 기능이 주가 되어버림
• 기존의 방식대로 서버가 페이지 구성에 필요한 모든 요소(HTML, JavaScript, Data)를 매번 전송하는 것이 아니라, 파일은 처음 한 번만 송수신. 그 뒤로는 실시간 데이터만 주고받음.
  • AJAX(Asynchronous JavaScript and XML)의 등장은 혜성☄️ 과도 같았다..
  • AJAX는 js를 사용하여 브라우저가 서버에게 비동기 방식으로 데이터를 요청하고, 응답한 데이터를 수신하여 웹페이지를 일부 동적으로 갱신.
  • 제일 처음 전송된 단일 HTML 페이지에 포함되어 있는 JavaScript 에서 필요한 데이터를 API 서버로부터 호출하여 필요한 화면을 dynamic 하게 새롭게 구성해주는 방식.
• 즉 HTML/JavaScript 부분과 데이터 부분이 구조적으로 분리되기 시작
  • → Frontend 개발과 Backend 개발이 독립적으로 분리 (프런트 - UI UX / 백엔드 - Data)
• “명확히 두 개로 나눌 수 있겠다!” → 프런트엔드와 백엔드가 나뉘게 되는 기점.
  • Frontend와 Backend가 구조적으로 분리가 되면서, Frontend 서버와 Backend API 서버도 분리가 되며 그에 따라 Frontend 개발과 Backend 개발 업무가 분리가 되는 구조로 발전된다.

• 기술 스택도 각자에 맞는 스택을 시용하기 시작함. (ex. React의 출현!)
• 프런트엔드가 개발의 혁신이 빠른 이유도 이 분야 자체의 역사가 짧음.

 

 

 

SPA

정적인 웹사이트인 Static과 js로 동적으로 작동하는 Dynamic 사이트에 대해서 배웠고 사이트의 페이지가 실제로 여러 개가 있는 멀티 페이지 애플리케이션과 리액트와 같이 index.js 에서 오직 js로만 사용자에게 어떤 부분을 렌더 해줄지 정하는 싱글 페이지 애플리케이션에 대해 배웠습니다.

Static Website

Dynamic Website

Multi Page Application (MPA)

SPA (Single Page Application)

 

 

CSR vs SSR

리액트 앱에서 검색이 잘 안 된다는 건 사실 이번에 수업을 듣기 전까진 알지 못하였었는데 이런 문제점이 있어서 Next.js 가 유행을 하는 거구나라고 생각하였고 당연히 회사 입장에서는 검색이 안 되는 사이트는 손해이기 때문에 Next에 대한 선호가 늘 것 같고 마케팅부에서 어떤 마케팅을 해도 그만큼 유입이 덜 될 수 있는 치명적인 상황이기 때문에 예리 님이 알려주신 내용은 저에게 너무 유익한 내용들이었습니다.

1. Create React App (CRA) ← Only CSR

• 별도의 초기 설정 없이도 CRA를 통해 React 기반의 SPA 사이트를 구현할 수 있게 됨.
• 그런데 얼마 간 시간이 지나면서 조금씩 이상한 점이 드러나기 시작.
  • 🤔: "우리 사이트가 검색 노출이 잘 안 되는데?"
  • 원인) CRA로 build 한 프로젝트는 Only CSR(Client Side Render)로 실행되기 때문.

 

2. CSR

• 웹 페이지의 렌더링이 클라이언트(브라우저) 측에서 일어나는 것을 의미.
• 브라우저는 최초 요청에서 html, js, css 확장자의 파일을 차례로 다운로드.
• 최초로 불러온 html의 내용은 비어있음. (html, body 태그만 존재) - public/index.html
• js 파일의 다운로드가 완료된 다음, 해당 js 파일이 dom을 빈 html 위에 그리기 시작.
• 웹서버 호출을 최소화할 수 있음
  • 최초 호출 때만 html, js, css를 요청
  • 이후에는 화면에서 변화가 일어나야 하는 만큼의 데이터만 요청 (ex. AJAX/JSON)
• 라우팅(새로운 페이지로 이동)을 하더라도 html 자체가 바뀌는 것이 아니라 JavaScript 차원에서 새로운 화면을 그려내는 것!

 

3. SEO (Search Engine Optimization)

• 하지만 웹 크롤러 입장에서 CSR로 구성된 페이지에 접속하는 시나리오를 재구성해보자.
• 웹 크롤러가 각 사이트를 돌아다니며 조사를 하는 상황이라고 가정.
• CRA로 신나게 만들었던 페이지들이 검색 노출이 잘 안 된다는 (충격적인) 사실이 알려지면서, SEO에 민감한 커머스 등의 비즈니스 영역은 대안을 찾아야 하는 상황.
  • 🤔 : "SPA의 장점을 살리면서 SEO도 같이 챙길 수는 없을까?"
  • ⇒ SSR (Server Side Rendering)

 

4. SSR (Server Side Rendering)

• 위에서 언급했던 CSR과 SSR의 차이에서 알 수 있듯, SSR은 서버에서 첫 페이지의 렌더링을 클라이언트 측이 아닌 서버 측에서 처리해주는 방식.
• CSR과 비교하면,
  • 1) SEO 측면에서 유리
    • 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 보여주는 방식이기 때문에 CSR의 단점인 "첫 페이지 깡통" 상태를 극복할 수 있음.
  • 2) UX 측면에서 유리
    • CSR에 비해 페이지를 구성하는 속도는 늦어지지만, 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라진다.
  • 주의) 페이지를 잘못 구성할 경우 CSR에 비해 서버 부하가 커지거나 / 첫 로딩이 매우 느려질 수 있음

 

SPA for SSR

 

• 그렇다면 SSR과 CSR을 섞어 쓸 수는 없나요?
• 사용할 수 있다! ⇒ 생산성을 위해 Next.js가 주로 채택됨
  • SSR의 CRA, 간단히 구성 가능
• Next.js by Vercel - The React Framework

Next.js by Vercel - The React Framework