💡브라우저 렌더링 과정을 설명하시오
브라우저가 렌더링하는 과정에는 총 5가지 과정이 있습니다.
첫 번째로 Parsing 즉, 해석하는 단계인데요, 브라우저는 가장 먼저 HTML 파일을 가져와 해석합니다. 그 과정에서 CSS 코드가 있다면 DOM Tree와 함께 CSSOM Tree도 생성합니다.
두 번째로 Style 즉, 실제 화면에 그려질 Tree를 생성하는 단계입니다. DOM Tree와 CSSOM Tree를 매칭시켜 Render Tree를 구성합니다.
세 번째로 Layout 즉, style 과정에서 생성된 Render Tree를 화면에 어떻게 배치할지 노드의 정확한 위치와 크기를 계산합니다. 또는 요소에 %를 주었다면 여기서 실제화면의 px로 변환합니다.
네 번째로 Paint 즉, Layout 과정에서 계산된 값을 Render Tree의 각 노드를 화면 실제 픽셀로 변환하며 여러개의 레이어로 구성됩니다.
마지막으로 Composite 과정에서는 paint 단계에서 생성된 레이어를 결합하는 과정으로 실제 화면에 나타냅니다.
💡브라우저는 어떻게 동작하나요?
브라우저는 사용자가 요청하는 자원을 서버에 요청하여 응답으로 받아온 결과를 화면에 나타냅니다.
즉 웹 페이지를 찾아주는 역할을 합니다. 보통 HTML 문서가 자원이고 자원으리 주소를 URI라고 합니다.
💡webpack, babel, polyfill에 대해 설명하세요
webpack은 소스코드를 사용자에게 간단하게 전달하기 위해 번들 단위로 묶어 사용자에게 전달하며 그 과정에서 변수 이름을 암호화하여 보안을 높여줍니다.
Babel은 개발자들이 최신 JS언어를 작성하면 그 언어를 옛 버전의 언어로 변환하여 오래된 버전의 브라우저에서도 사용될 수 있도록 합니다. tx와 jsx를 js로 변환하는 역할도 합니다.
💡CSR과 SSR의 차이점?
먼저 SSR은 server side rendering의 약자로 user가 인터넷에서 서버에 요청을 하면 서버는 페이지를 만들어서 응답합니다. 서버는 이때 HTML을 응답하여 응답결과를 브라우저가 렌더링 하는 방식인데 이때 서버에서 User에게 렌더링이 완료된 HTML을 응답합니다.
CSR은 서버에서 HTML을 보내는 것이 아니라 서버에서 JSON 파일을 응답하면 클라이언트에서 렌더링을 합니다. 바로 SPA의 시초가 될 수 있는데요 리액트, 앵귤러, 뷰 등 서버에서 받은 응답을 토대로 virtual-dom을 통해 사용자에게 SPA를 렌더링하는 역할을 합니다.
두 렌더링의 차이점은 크게 속도와 검색엔진 최적화 여부입니다.
CSR의 장점인 빠른 렌더링은 사실 초기 렌더링을 제외한 렌더링입니다. 모든 JS파일을 한 번에 다 받아와야 하기 때문이죠. 하지만 초기 로딩 이후에는 SPA의 역할을 톡톡히 하듯 빠른 속도로 사용자의 interaction을 읽어내고 응답합니다.
반면 SSR은 초기에 이미 완성된, 렌더링이 완료된 HTML을 응답하기 떄문에 초기 로딩이 짧지만 그 이후로 이벤트가 발생시 화면이 새로고침되며 사용자 친화적이기 않습니다.
검색엔진 최적화는 SSR에 더 적합합니다. 브라우저는 사용자의 검색 결과에 따라 정보를 수집합니다. 서비스가 자전거에 관련되어 있다면 렌더링이 왼료된 HTML을 응답하는 SSR에는 이미 HTML 파일에 자전거 관련 정보가 포함되어 있습니다. 브라우저는 이를 읽고 검색 결과를 나타내죠.
하지만 CSR은 초기에 서버에서 응답받는 HTML이 빈 내용입니다. 클라이언트 사이드에서 그 내용을 채웁니다. 따라서 검색 엔진은 아무런 내용이 없는 HTML을 보고 어떤 검색 결과 나타내야할지 모르게 되는 겁니다.
이 처럼 CSR, SSR의 장단점이 각각 있습니다. 이 두 렌더링 방식의 장점만 뽑아서 사용할 수 있는 isomorphic 방식을 채택한 Next.js를 사용할 수 잇습니다. 하지만 가장 중요한 요소는 서비스의 성격이빈다. 서비스의 성격에 따라 채택하면 됩니다.
💡CORS는 무엇이며 처리해본 경험이 있는지?
CORS는 cross origin resource sharing의 약자로 다른 출처에서 리소스를 공유하는 것을 말하며 이를 규정하는 정책이 있습니다. 개발자는 보안을 위해 CORS 정책을 지킨 리소스 요청을 해야합니다.
처리해본 경험은 없지만 추후 CORS를 처리하는 상황이 발생했을 때를 대비하여 숙지하도록 하겠습니다.
💡웹 표준을 지키면서 개발하나요?
초기에는 웹 표준에 크게 신경 쓰지 않고 개발했습니다. 하지만 프로젝트 진행 중 input 창의 border 및 background-color를 transparent 또는 display: none으로 지정하려 했더니 동료 개발자가 웹 표준 접근성 정책을 참고하라고 했습니다. 웹 표준을 지키지 않으면 서비스 이용에 불편감을 느끼는 사용자가 있겠구나를 느끼며 그때를 계기로 항상 모든 사용자에게 서비스 이용에 있어 불편감이 없도록 사용자 입장에서 코드를 써내려 가도록 노력중입니다.
💡이벤트 루프와 태스크 큐에 대해 설명하시오
자바스크립트는 싱글 스레드 입니다. 즉 한번에 하나의 일만 처리할 수 있다는 뜻이죠. 하지만 논블로킹입니다. 이말은 한번에 하나의 일만 처리할 수 있지만 다른일이 실행되는 것을 막지는 않습니다.
따라서 싱글 스레드 이지만 여러 작업을 동시에 처리할 수 있습니다. 이때 이벤트 루프와 태스크 큐가 실행됩니다.
함수를 호출하면 먼저 callstack에 처리할 함수가 들어가게 됩니다. first in last out 구조로 함수가 실행됩니다. 여기서 call은 함수 및 함수 호출을 뜻하고 stack은 쌓이는 구조를 말합니다.
하지만 비동기적으로 실행되는 대표적인 AJAX, setTimeout 함수들은 어떻게 처리될까요?
예를 들어 setTimeout 함수가 callstack에 쌓이면 자동으로 web API에서 timer 함수를 호출합니다. timer 함수는 setTimeout의 콜백함수를 등록하게 됩니다. setTimeout 함수는 이렇게 실행되었기 때문에 callstack을 빠져나가게 되고 setTimeout함수의 다음 함수가 다시 callstack에 쌓이면서 실행됩니다. 그리고 다음 함수도 callstack에서 빠져 나가게 되면 setTimeout에서 넘겨주 callback 함수가 타이머 시간이 지난 후 태스크 큐에 담기게 됩니다.
이때 이벤트 루프는 항상 callstack와 task queu를 바라보고 있습니다. 만약 callstack이 비워지만 이벤트 루프는 task queu에 가장 앞에 있는 callback 함수를 callstack에 전달합니다.
따라서 setTimeout의 callback 함수가 task queu에 있다가 callstack이 비워지면 callstack에 채워지게 됩니다. 그리고 setTimeout의 callback 함수가 실행되고 callstack에서 빠져나가게 됩니다.
