티스토리 뷰
44. Server Side Rendering, Client Side Rendering, Static Site Generation 의 장단점을 설명해주실 수 있을까요?
SSR은 서버에서 뷰 구성에 필요한 전체 HTML을 요청을 받은 즉시 생성해서 반환합니다. 초기에 모든 페이지를 완성해서 보내기 때문에 검색엔진 최적화(SEO)에 유리합니다. 초기 페이지 로드 시간이 빠릅니다. 그러나 페이지 이동시마다 서버에서 페이지를 생성하는데 시간이 걸리기 때문에 TTFB(Time To FIrst Byte)가 느립니다. CSR은 서버가 아닌 클라이언트 브라우저에서 어플리케이션을 렌더링합니다. 후속페이지의 로드 시간이 더 빠르지만 초기 페이지로드 시간이 SSR에 비해 느립니다. 또한 SSR과 달리 클라이언트 단에서 렌더링 되기 때문에 검색엔진 최적화(SEO)에 불리합니다. SSG는 SSR처럼 서버로부터 완성된 HTML을 받아오지만 다른점은 HTML 파일의 생성시점이 빌드타임인 것입니다. 빌드타임에 HTML파일이 생성되기 때문에 빠른 속도를 제공하지만 모든 URL에서 개별 HTML파일을 생성해야 하므로 URL을 예측하기 어렵다면 적용하기 어렵습니다.
+ CSR : 유저가 요청한 페이지를 브라우져에서 동적으로 생성하는 방식입니다. 장점은 첫 로딩 이후 속도가 빠르고 화면 깜박임이 없어 ux가 개선됩니다. 단점은 앱의 규모가 커질수록 첫로딩 시간이 지연될 수 있고, 오직 CSR로만 구현된 앱의 경우 seo에 불리할 수 있습니다. SSR : 유저의 요청에 따라 HTML파일을 만들어 응답합니다. 장점은 첫 로딩속도가 빠르고 seo에 대해 적절한 대응이 가능합니다. 단점은 페이지 이동 시마다 서버가 페이지를 생성하는 작업을 하게 되는데, 페이지가 너무 커서 느려지거나 한번에 많은 요청으로 서버에 부하가 많이 걸릴 수 있습니다. SSG : 서버에서 빌드 시점에 HTML파일을 미리 만들어두고, 요청이 들어오는 경우 해당 파일로 바로 응답합니다. 장점은 페이지가 이미 생성되어있기 때문에 첫로딩 속도가 SSR보다도 빠르고 seo에 적절한 대응이 가능합니다. 단점은 만들어진 HTML파일이 최신이 아니므로 적절한 방식으로 갱신을 시켜줘야 합니다.
45. Event bubbling 과 capturing 을 비교하여 설명해주실 수 있을까요?
이벤트 버블링과 캡처링은 돔 트리상에 존재하는 모든 돔 요소 노드에서 발생한 이벤트가 돔트리를 통해 전파되는 이벤트 전파 방식중에 하나입니다. 전파되는 방향에 따라 캡처링, 타깃, 버블링 3단계로 구분됩니다. 특정 타깃에서 이벤트가 발생하게 되면, 최상위 노드(root)에서 부터 캡처링이 일어나서 타깃 요소까지 이벤트가 전해져 내려옵니다. 이벤트는 타깃요소에서 부터 다시 최상위 노드(root)까지 버블링이 일어나서 이벤트가 전달됩니다. 우리는 일반적으로 버블링 현상을 캐치하여사용합니다. 이벤트를 상위 노드에 위임하여 하위 노드의 이벤트를 조작하는 것이 그 예시입니다. 이벤트 리스너의 세번째 인자값값인 capture 옵션(boolean)을 true로 선언하면 캡쳐링 단계의 이벤트도 캐치할 수 있습니다.
+ 웹페이지의 특정 DOM에서 이벤트가 발생하면 해당 DOM에서만 발생하는 것이 아니라 먼저 DOM트리의 최상단부터 해당 DOM까지 순차적으로 eventcapturing이 발생합니다. 이후 반대방향으로 eventbubbling이 발생하게됩니다. javascript에서는 addEventlistener 의 세번째 인자를 true로 설정하게되면 capturing이 될때 해당 handler가 작동하게되고, 입력하지 않거나 false로 입력하면 bubbling이 될때 handler가 작동하게 됩니다. react에서는 onClickCapture 와 onClick 으로 구분하여 사용하게 됩니다.
https://ko.javascript.info/bubbling-and-capturing
47. https://naver.com을 주소창에 입력했을 때 일어나는 과정에 대해 아는 만큼 설명해주실 수 있을까요?
입력한 URL주소 중 도메인 네임 부분을 DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL정보와 함께 전달합니다. 페이지 URL과 전달받은 IP주소는 HTTP 프로토콜을 사용하여 HTTP요청 메시지를 생성하고 이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP주소의 컴퓨터로 전송됩니다. 이렇게 도착한 HTTP요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환되어 웹페이지 URL정보에 해당하는 데이터를 검색합니다. 검색된 웹페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성하고 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송됩니다. 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환되어 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됩니다.
48. 상태관리의 대표적인 도구 하나와 그것의 원리에 대해 구체적으로 설명해주실 수 있을까요? 예를 들어 리덕스라면 리덕스가 무엇이고 어떻게 활용이 되는지, 어떤 흐름으로 데이터가 들어왔다가 나가는지, 데이터 흐름은 양방향인지 단방향인지, 어떤 함수가 데이터를 가져오게 해주는지 등을 언급해주시면 좋습니다.
대표적인 상태관리 도구로 리덕스를 생각해 볼수 있습니다. react팀은 기존의 mvc 모델이 데이터를 양방향으로 주고 받으면서 예측하지 못한 문제를 발생시키는 문제를 해결하고자 flux 라는 단방향 데이터 흐름 모델을 제시했습니다. redux는 해당 flux모델을 전역 state에 대해서 적절하게 구현한 라이브러리라고 할 수 있습니다. view에서 유저가 action creator 작동 시키면 dispatcher가 적절한 reducer에 action 과 payload를 전달하게 되고 reducer는 이전 상태값과 전달받은 action, payload를 참조하여 상태 값을 갱신하게 됩니다. 결과적으로 이렇게 갱신된 상태가 화면에 반영됩니다.
+리액트를 사용하면서, 상태 관리를 하는 것은 매우 중요한 요소 중 하나입니다. 리액트로 만들 수 있는 단일 페이지 애플리케이션(SPA, Single Page Application)는 data 혹은 UI의 변화가 복잡, 다양해지는 경우가 많아집니다. 그에 따라 단일 페이지를 이루는 컴포넌트들의 데이터 교류 또한 복잡해지기 때문에 이를 효율적으로 관리할 방법이 필요합니다. 리덕스는 이러한 복잡한 상태 관리를 효율적으로 할 수 있게 도와주는 도구입니다.
49. 브라우저 렌더링 과정에 대해 아는 만큼 설명해주실 수 있을까요? 예를 들어 화면에서 DOM이 어떻게 결정되고, CSS는 어떻게 입혀지는지 등을 언급해주시면 좋습니다.
브라우저 렌더링은 웹 페이지가 화면에 그려지는 과정을 의미합니다. 이 과정은 다음과 같은 순서로 진행됩니다. 1. HTML 소스 코드를 읽기 - 브라우저는 HTML 소스 코드를 읽고 구조화합니다. 2. CSS 적용 - CSS는 웹 페이지의 스타일을 정의합니다. 웹 브라우저는 HTML 소스 코드에 있는 CSS 정보를 읽고, DOM 객체들에 적용합니다. 3. 렌더링 트리 생성 - 브라우저는 DOM 객체들과 적용된 CSS 정보를 이용하여, 웹 페이지가 어떻게 그려져야 하는지를 정의한 렌더링 트리를 생성합니다. 4. 렌더링 - 브라우저는 생성된 렌더링 트리를 이용하여, 실제로 웹 페이지를 그립니다. 5. 자바스크립트 실행 - 브라우저가 HTML 소스 코드를 읽고 구조화하면서, 자바스크립트 코드도 같이 검색합니다. 6. 그리기 - 브라우저는 최종적으로 웹 페이지를 화면에 그리게 됩니다.
https://tecoble.techcourse.co.kr/post/2021-10-24-browser-rendering/
50. Web Vital을 개선할 수 있는 방안에 대해 설명해주실 수 있을까요? 예를 들어 LCP, CLS, FID 각각의 개념, 진단법, 각 지표 개선에 효과적인 조치 방안을 언급해주시면 좋습니다.
LCP는 시각적으로 큰 콘텐츠가 표시되기까지 걸리는 시간을 나타내는 지표입니다. 이 지표에 대한 개선방안으로는 렌더링을 빠르게하거나, 서버 응답시간을 향상시키거나, 파일 사이즈를 단축하면 됩니다. CLS는 레이아웃 쉬프트(페이지 렌더링 과정에서 기존 요소들이 밀려나는 것 의미)의 빈도를 정량화하여 시각적 안정성을 측정하는 지표로 사용자 입력 0.5초(500ms)이내에 발생하지 않는 레이아웃 이동에 대한 점수를 합산하여 콘텐츠의 불안정성을 측정합니다. 개선 방법으로는 콘텐츠의 높이(height)를 미리 지정하여 확보해두는 것이 포인트입니다. FID는 사용자가 최초 입력이 가능하기까지 걸린 시간을 의미합니다. 이벤트 처리에서 "지연" 부분만 측정하며 이벤트 처리 시간 자체나 브라우저에서 이벤트 핸들러를 실행한 후 UI를 업데이트하는 데 걸리는 시간은 측정하지 않습니다. 처리시간이 긴 JS (Long task) 개선이 포인트입니다.
+ Web Vitals는 웹에서 우수한 사용자 경험을 제공하는 데 필수적인 품질 신호에 대한 통합 지침을 제공하기 위한 Google의 이니셔티브
https://developers-kr.googleblog.com/2020/05/Introducing-Web-Vitals.html
https://blog.outsider.ne.kr/1548
'CS_study' 카테고리의 다른 글
Hoisting, parameter vs argument (0) | 2023.02.22 |
---|---|
렌더링, RestAPI (0) | 2023.02.21 |
[기술 면접 준비] Mockterview_React_50제_27~43번 (1) | 2023.02.16 |
[기술 면접 준비] Mockterview_React_50제_17~26번 (0) | 2023.02.15 |
[기술 면접 준비] Mockterview_React_50제_11~16번 (0) | 2023.02.14 |