안녕하세요:)
저번 글들에서는 '웹 서비스를 안정적으로 운영하기 위한 다양한 전략들'에 대해 알아보았습니다. 무중단 배포, 장애 대응 그리고 GSLB CDN 등 다양한 주제를 다루며, 안정적이고 끊기지 않는 웹 서비스를 제공하기 위한 핵심 기술들에 대해 살펴보았죠.
이번 글에서는 웹 페이지가 어떻게 화면에 표시되는지를 이해하기 위해 '렌더링'이라는 개념에 대해 다뤄보려 합니다. 여러분이 브라우저에 URL을 입력하고, 웹 페이지가 눈 앞에 펼쳐지기까지의 과정에서 어떤 일이 일어나는지 궁금하지 않으셨나요? 사실 1장에서 렌더링이라는 단어를 사용하기는 했지만 자세히 다루지는 않았었습니다. 렌더링은 웹 페이지가 로드되는 과정의 핵심을 이루는 기술로, 웹 페이지의 UX를 좌우하는 중요한 요소입니다.
렌더링 과정을 이해하면, 웹 페이지의 성능을 최적화하는 방법을 보다 명확하게 파악할 수 있습니다. 또한, 이 과정에서 CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)에 대해서도 언급할 예정입니다.
그럼, 이제 렌더링 개념부터 시작하도록 하겠습니다!
1. 렌더링(Rendering)이란?
렌더링은 웹 페이지가 사용자 브라우저에 표시되는 과정을 말합니다. 좀 더 자세히 말하자면, 서버로부터 받은 HTML, CSS, JavaScript와 같은 리소스를 브라우저가 해석하고, 이를 바탕으로 사용자가 볼 수 있는 온전한 화면을 구성하는 과정입니다.
렌더링이 이루어질 때 브라우저는 단순히 텍스트를 나열하는 것 이상을 수행합니다. 브라우저는 HTML 문서의 구조를 이해하고, CSS 스타일 규칙을 적용하며, JS 코드를 실행하여 동적인 요소를 추가함으로써 우리가 흔히 보는 웹 페이지가 만들어집니다.
또한, 렌더링이라는 건 웹 페이지의 성능과 UX에 큰 영향을 미칩니다. 페이지 로딩 속도와 인터랙티브 요소의 반응성이 렌더링 과정의 효율성에 따라 달라지기 때문입니다. 그으래서 만약 본인이 웹 개발자라면 렌더링 과정을 이해하고, 이를 최적화하여 더 나은 UX를 제공하는 것이 중요합니다.
그렇다면 렌더링은 어떻게 이루어질까요? 지금부터 렌더링이 어떠한 과정을 통해 진행되는지에 대해 알아보도록 하겠습니다.
2. 렌더링 과정
렌더링은 사용자가 웹 페이지를 요청한 순간부터 화면에 페이지가 표시되기까지의 모든 단계를 포함하는 절차입니다. 렌더링 절차는 크게 5단계로 나눌 수 있습니다. DOM 트리 생성 -> CSSOM 생성 -> Render 트리 구성 -> 레이아웃 계산 -> Painting 단계입니다. 차례대로 하나씩 살펴보도록 하겠습니다.
1. DOM(Document Object Model) 생성
첫 번째 단계는 DOM을 생성하는 과정입니다. 브라우저가 서버로부터 받은 HTML 문서를 파싱하여 DOM 트리를 만들게 됩니다. DOM이란 HTML문서의 구조를 반영한 트리로, 각 HTML 태그는 트리의 노드가 됩니다. 예를 들어, <body>태그가 하나의 노드가 되고, 그 안에 포함된 <div>, <p> 등의 태그들도 각각의 노드로 자리잡아 트리를 이루게 됩니다. DOM은 전체적인 웹 페이지의 구조를 정의하며 JS와의 상호작용을 가능하게 합니다.
2. CSSOM(CSS Object Model) 생성
HTML문서가 파싱되면서 동시에 브라우저는 CSS 파일도 파싱하여 CSSOM을 만듭니다. 이건 CSS규칙이 웹 페이지의 어떤 요소에 어떻게 적용될지를 정의하는 또 다른 트리구조인데, 이 과정에서 브라우저는 각 요소에 어떤 스타일이 적용되는지를 계산하게 됩니다. DOM과 CSSOM은 이후 단계에서 결합되어 화면에 표시될 최종 구조를 결정하게 됩니다.
3. Render Tree 구성
DOM과 CSSOM이 만들어지면 이 둘이 결합을 하는데, 이렇게 만들어지는 게 바로 렌더 트리 입니다. 렌더 트리는 화면에 실제로 표시될 요소들만 포함하여 만들어집니다. HTML 코드를 작성할 때 'display: none' 과 같이 화면에 보이지 않는 요소들은 제외되고 만들어집니다. 이 트리에서 각 노드는 화면에 어떻게 그려질지를 나타내며, 스타일 정보와 DOM 요소를 결합하여 표시될 콘텐츠의 레이아웃을 정하게 됩니다.
4. Layout 계산
렌더 트리까지 구성이 됐으면 레이아웃을 계산해야 하는데, 여기서 레이아웃이란, 웹 페이지의 각 요소들이 화면에 어떻게 배치될지를 정의하는 과정입니다. 브라우저가 렌더 트리를 구성한 후, 각 요소의 크기와 위치를 계산하여 페이지에서 정확한 위치에 표시되도록 하는 것을 말합니다. 즉, 레이아웃은 웹 페이지가 브라우저 창에 어떻게 보일지에 대해 결정하는 단계이기 때문에 매우매우 중요한 단계라고 볼 수 있습니다.
이이서 레이아웃 과정을 말해보자면, 화면의 크기, 해상도, 요소들 사이의 관계, 요소의 스타일 속성(width, height, margin, padding 등)등을 고려하여 요소들을 적절하게 배치합니다. 예를 들어, div 가 포함되어 있을 때는 이 div들이 화면에서 정확히 어디에 위치할지를 계산하게 됩니다.
이 과정에서 중요한 개념이 나오는데 Reflow라는 개념입니다. 리플로우는 웹 페이지의 레이아웃이 재계산되는 과정으로, 요소의 크기나 위치가 변경되면 다른 요소들에게 영향을 미칠 수 있습니다. 예를 들어, 하나의 div의 크기를 변경하면, 그 주변의 다른 요소들의 위치나 크기 또한 다시 계산되어야 하기 때문입니다. 이런 경우 리플로우가 리소스를 많이 잡아먹는 작업이 될 수 있음을 의미하며, 특히 대규모 페이지에서는 성능 저하까지 이어질 수 있습니다.
이렇게 레이아웃 과정을 통해 요소들의 위치를 계산했다면 이제 계산된 위치에 요소들을 표시하는 작업만 남게 됩니다.
5. Painting
페인팅 단계에 브라우저는 계산된 레이아웃을 실제 픽셀로 변환해서 화면에 그리게 됩니다. 여기서 각 요소의 색상, 텍스처, 그림자, 테두리 등의 스타일이 적용되고, 렌더 트리에 따라 순차적으로 화면에 그려집니다. 즉, 웹 페이지의 최종적인 시각적 요소가 이 단계에서 완성됩니다. 페인팅 단계는 브라우저 성능에 큰 영향을 미치고, 최적화되지 않은 페인팅은 로딩 속도를 크게 저하시킬 수 있습니다.
그렇다면 페인팅 단계는 왜 로딩 속도를 저하시키게 되고 브라우저에 큰 영향을 미칠까요?
이는 페인팅 단계가 리플로우와 연관되어 있기 때문입니다. 리플로우는 레이아웃이 변경될 때마다 발생하는데, 이때 브라우저는 해당 요소뿐만 아니라 관련된 다른 요소들의 레이아웃도 다시 계산해야 하기 때문에, 리플로우가 발생하면 새로운 레이아웃을 기반으로 다시 페인팅이 이루어져야 하며, 이 과정이 반복되면 브라우저의 리소스 사용량이 급증하게 되어 성능 저하로 이어질 수 있습니다.
특히, 페인팅 과정에서는 각 요소의 스타일이 적용되는데, 스타일이 복잡할수록 페인팅에 걸리는 시간이 길어집니다. 예를 들어, 그림자가 많거나 복잡한 텍스처가 사용된 경우, 이를 그리는 데 더 많은 시간이 소요됩니다. 이러한 요소들이 리플로우로 인해 빈번하게 변경될 경우, 페인팅 과정에서도 반복적인 작업이 필요하게 되어 성능에 부정적인 영향을 미칠 수 있습니다.
이로 인해, 페이지를 스크롤하거나 상호작용할 때 페이지가 느려지거나, 화면이 끊기는 현상이 생기게 됩니다. 실제로 다들 한 번 씩은 경험한 적이 있으실 거 같습니다. 이러한 문제를 방지하기 위해서는 CSS와 JavaScript를 최적화하여 불필요한 리플로우를 최소화하고, 복잡한 스타일을 사용하는 경우 성능에 미치는 영향을 최소화하도록 설계하는 것이 중요합니다. 결국, 리플로우와 페인팅의 반복은 웹 페이지의 로딩 속도를 저하시킬 수 있으며, 최적화를 통해 이러한 성능 저하를 예방하는 것이 필요합니다.
3. 렌더링 최적화 방법
웹 페이지의 성능 향상을 위해서도 렌더링 최적화는 반드시 필요한 과정이지만, 최적화 방법은 기술 스택에 따라 조금씩 다르게 접근해야 합니다. 여기서는 JavaScript와 TypeScript를 사용하는 경우, 그리고 React와 Next.js같은 프레임워크를 사용하는 경우 최적화 방법에 대해 알아보도록 하겠습니다.
1. JS와 TS에서의 차이
JavaScript와 TypeScript 모두 효율적인 코드 작성이 중요하긴 합니다. 효율적이게 작성하기 위해서는 복잡한 연산이나 불필요한 DOM 조작을 최소화하고, 중복된 코드를 제거하는 것이 필요하죠. JS는 동적인 특정 때문에, 변수 타입과 관련한 오류가 런타임에 발생할 수 있어 이러한 점을 사전에 예방하기가 어렵습니다. 반면 TS는 정적 타입 시스템을 활용하여 코드 작성 시점에서 오류를 잡아내고, 코드의 안정성을 높일 수 있습니다. 이러한 점은 프로젝트의 규모가 커질수록 더욱 중요해지겠죠?
비동기 처리라고 알고 계신가요?
비동기 처리란, 코드의 실행이 특정 작업이 끝날 때까지 기다리지 않고 계속 진행될 수 있게 하는 방식입니다. 비동기를 통해 긴 작업이나 I/O 작업이 진행되는 동안 페이지가 멈추지 않고 다른 작업을 수행할 수 있고, 비동기 작업이 많을 경우, Promise나 async/await를 활용하여 이벤트 루프의 블로킹을 최소화하고, 페이지의 응답 속도를 개선시킬 수 있습니다. 비동기 방식은 보통 이미지를 로드하거나 데이터를 가져올 때, 이를 활용하여 렌더링 성능을 최적화할 수 있습니다.
2. React에서의 렌더링 최적화
리액트에서는 컴포넌트가 동일한 props로 여러 번 불필요하게 리렌더링되는 것을 최소화해야 합니다. 이를 최소화하기 위해 사용하는 것이 'React.Memo', 'useMemo', 'useCallback'과 같은 기법을 사용해 컴포넌트의 렌더링을 제어하고, Virtual DOM을 활용하여 효율적으로 업데이트를 관리할 수 있습니다.
3. Next.js에서의 렌더링 최적화
Next.js는 React를 기반으로 한 프레임워크로, 웹 페이지의 효율적인 성능을 위한 여러가지 최적화 방법을 제공해줍니다. 핵심 기능 중 하나는 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)인데, 이 두 가지 기능은 초기 로딩 시간을 단축하고, 빠르고 원활한 UX를 제공하는 데 중요한 역할을 하게 됩니다.
그렇다면 SSR과 SSG는 어떻게 웹 페이지의 성능을 향상시키고 UX를 개선할 수 있을까요?
SSR은 페이지를 서버에서 렌더링한 후, 완성된 HTML을 클라이언트로 전달하는 방식입니다. 이 접근 방식은 초기 로딩 시점에 페이지가 완전히 렌더링되어 제공되므로, 사용자 입장에서는 더 빠르게 콘텐츠를 확인할 수 있게 되는데, 데이터가 자주 변경이 되거나, 사용자 맞춤형 콘텐츠가 많은 웹사이트에서 유용하게 쓰입니다. 단, 항상 좋은 건 아니니 상황에 따라 알맞게 사용해야 합니다!
SSG는 빌드 시점에 페이지를 미리 생성하여, 사용자가 요청할 때마다 서버에서 새로 렌더링하는 대신 사전 생성된 HTML 파일을 바로 제공하는 방식입니다. 이렇게 하게 되면, 서버 부하를 줄일 수 있으며, 정적 콘텐츠가 많은 웹사이트에서 성능을 크게 개선할 수 있습니다. 또한, 사용자는 서버 응답 지연 없이 즉시 콘텐츠를 볼 수 있게 됩니다.
Next.js는 SSR과 SSG 방식 외에도 코드 스플리팅이라는 기능도 자동으로 지원하여, 각 페이지에 필요한 코드만 로드 되도록 합니다. 해당 기능을 통해 로딩 시간을 단축하고, 불필요한 코드 로드를 방지할 수 있는데, 페이지 크기가 크면 클수록 중요도가 올라가는 기능입니다.
4. 공통적인 최적화 기법
위에서 React, Next.js와 같은 프레임워크에서의 최적화 방식에 대해 알아보았는데, 기술 스택에 상관없이 모든 웹 애플리케이션에서 공통적으로 적용할 수 있는 최적화 기법들이 있습니다.
먼저 소개할 첫 번째 기법은 '리소스 최적화'입니다.
웹 페이지가 로드될 때 필요한 이미지, 글꼴, 스크립트 등의 리소스를 최적화하는 것이 매우 중요한데, 예를 들어, 이미지의 포맷을 최적화하거나, 불필요한 리소스는 사용자가 실제로 필요할 때까지 로드하지 않는 '자연 로딩(lazy loading)'을 적용할 수 있습니다. 이렇게 하면 초기 로딩 시간을 단축할 수 있게 되며, 페이지가 더 빠르게 표시되도록 도울 수 있습니다.
두 번째로, '파일 크기 줄이기'입니다. JS 파일의 크기를 줄이는 것은 웹 페이지 성능에 아주 큰 영향일 미칩니다. 웹팩(Webpack)과 같은 번들러를 활용하여 코드의 중복을 제거하고, '코드 압축'을 통해 전송되는 파일 크기를 최소화할 수 있습니다. 이렇게 하면, 결과적으로 네트워크 트래픽이 줄어들고, 페이지 로딩 시간이 단축되어 UX가 상당히 개선됩니다.
세 번째는 '캐싱'입니다. 캐싱을 통해 브라우저와 서버 모두 성능측면에서 최적화를 시킬 수 있습니다. 브라우저는 이전에 가져온 리소르르 캐시에 저장하여 다음 페이지 로드 시 서버로부터 새로운 리소스를 가져오는 대신 캐시된 리소스를 사용할 수 있습니다. 이렇게 되면 서버 부하도 줄일 수 있고, 페이지 로드 시간을 더욱 단축시킬 수 있습니다.
4. 브라우저별 렌더링 차이
혹시 브라우저마다 렌더링 방식이 조금씩 다르다는 거 알고 계셨나요?
브라우저마다 렌더링 엔진이 다르기 때문에, 웹 페이지를 렌더링하는 방식에도 차이가 발생할 수 있습니다. 예를 들어, Google의 Chrome과 Microsoft Edge는 Blink라는 렌더링 엔진을 사용하고, Firefox는 Gecko, 그리고 애플의 Safari는 WebKit을 사용합니다.
이 차이는 주로 CSS의 해석, 자바스크립트의 실행, 그리고 레이아웃과 페인팅 과정에서 발생할 수 있으며, 브라우저의 엔진은 각기 다른 방식으로 최적화나 렌더링을 수행하기 때문에, 웹 개발자는 이를 고려해 웹 페이지를 설계하는 편이 좋습니다.
또한, 브라우저별 렌더링 차이는 글꼴 및 텍스트의 렌더링 방식에서도 드러납니다. 각 브라우저는 글꼴을 처리하고 화면에 표시하는 방식이 다를 수 있어, 텍스트의 두께, 자간, 선명도 등에 차이가 발생할 수 있습니다. 이러한 차이는 디자인이 중요한 웹 사이트에서 UX에 영향을 미칠 수 있겠죠?
위와 같은 차이로 인해 웹을 개발하는 개발자라면 크로스 브라우저 테스트를 통해 다양한 브라우저에서 웹 페이지가 일관된 모습과 성능을 제공할 수 있도록 최적화를 하도록 노력해야합니다.
5. 렌더링 속도가 기업에 미치는 영향
마지막으로 알아볼 내용은 렌더링 속도가 비즈니스에 얼마나 영향을 미치는가? 입니다.
렌더링 속도는 단순히 사용자가 페이지를 볼 수 있게 하는 시간을 의미하는 것이 아닙니다. 렌더링은 UX, 검색 엔진 최적화(Search Engine Optimization, SEO), 그리고 궁극적으로는 기업의 매출과도 연관이 되어 있습니다. 여러 대형 기업들의 사례를 통해 렌더링 속도가 비즈니스에 어떤 영향을 미치는가! 알아보도록 하겠습니다.
Amazon: 페이지 로딩 속도와 매출의 상관관계
아마존은 그 누구보다도 페이지 로딩 속도의 중요성을 잘 알고 있는 기업입니다. 진행된 연구 결과에 따르면, 페이지 로딩 속도가 단 100밀리초만 느려져도 매출이 1%나 감소한다는 사실이 밝혀졌습니다. 1%가 별거 아닌 거 같지만, 아마존처럼 거대한 기업에게 이 1%가 연간 수십억 달러의 손실로 이어질 수 있습니다. 이만큼 사용자 경험이 중요하다는 사실을 잊지 말아야겠죠?
https://www.conductor.com/academy/page-speed-resources/faq/amazon-page-speed-study/
Google: 로딩 속도와 검색 순위의 연관성
구글도 로딩 속도에 예민한 기업 중 하나입니다. 구글은 페이지 로딩 속도가 검색 결과 순위에 영향을 미친다는 것을 알고 있습니다. 구글의 연구에 따르면, 모바일 페이지 로딩 속도가 1초에서 3초로 늘어나는 것만으로도 이탈률이 32%나 증가할 수 있다고 합니다. 사용자가 페이지가 열릴 때까지 기다리다가 결국 포기하고 다른 곳으로 떠나버리는 사태가 발생합니다. 그래서 구글은 페이지 속도를 겁색 순위에 반영하기도 했습니다.
https://www.weetechsolution.com/blog/how-page-speed-affects-seo-and-google-rankings
https://support.google.com/webmasters/thread/239991563/doed-page-speed-affect-ranking?hl=en
https://www.searchenginejournal.com/ranking-factors/page-speed/
BBC: 로딩 속도가 사용자 이탈에 미치는 영향
마지막으로 BBC의 기사를 보도록 하겠습니다. BBC는 페이지 로딩 속도가 1초만 늘어나도 사용자 이탈률이 10%나 증가한다는 연구 결과를 내놓았습니다. 뉴스나 콘텐츠 제공 사이트에서는 특히 이탈률이 더 문제가 될 수 있는데, 사용자가 다른 사이트로 쉽게 옮겨갈 수 있기 때문입니다.
https://www.bbc.com/news/business-37100091
끝내는 말
이번 글에서는 렌더링이 무엇인지, 렌더링 최적화의 다양한 방법들, 그리고 렌더링이 비즈니스에 어떤 영향을 주는지에 대해 알아보았습니다. 도움이 되셨을까요? 저도 쓰면서 한 번 더 읽게 되니 도움이 많이 됩니다 ㅎㅎ
웹 사이트의 로딩 속도와 렌더링 최적화는 UX에 직접적인 영향을 미치고, 더해서 비즈니스의 성과 및 매출에도 영향이 갑니다. 특히, 로딩 속도가 조금만 느려져도 사용자 이탈률이 증가할 수 있다는 점은 모든 웹 개발자가 염두에 두어야 할 사항이라고 생각합니다.
다음 글에서는 SSR(서버 사이드 렌더링)과 CSR(클라이언트 사이드 렌더링)에 대해 더 깊게 알아보도록 하겠습니다..!!
읽어주셔서 감사합니다:)
'웹 인프라' 카테고리의 다른 글
| 대용량 데이터 처리, 어떻게 하는 걸까? (0) | 2024.10.20 |
|---|---|
| SSR vs CSR, 어느 쪽을 선택할까? (0) | 2024.08.27 |
| 장애 대응: 안정적인 웹 서비스를 위한 필수 전략 2 (1) | 2024.08.19 |
| 무중단 배포: 안정적인 웹 서비스를 위한 필수 전략 1 (0) | 2024.08.17 |
| GSLB와 CDN을 활용한 웹 서비스 최적화 (3) | 2024.08.16 |
