TOAST UI

Gatsby와 Next.js로 똑같은 앱을 만들었을 때 더 나은 성능을 가진 Gatsby를 발견했다.

웹 기술이 발전하고 변화하면서 웹 페이지에서 중요하게 여기는 기준들 또한 필연적으로 변하게 된다. 성능을 측정하는 기준, 즉 성능 지표는 웹 페이지의 성능을 합리적으로 나타낼 수 있어야 한다. 라이트하우스는 그동안 다양한 지표들을 개발하고 가이드를 제시해왔다.

브라우저는 웹 페이지의 메모리를 자동으로 관리한다. 웹 페이지가 객체(object)를 만들 때마다, 브라우저는 객체를 저장하기 위해 "내부적으로" 메모리 청크(chunk)를 할당한다. 메모리는 한정된 자원이기 때문에, 브라우저는 가비지 컬랙션으로 더는 객체가 필요하지 않은 시점을 감지하고 메모리 청크를 해제한다.

코드 스플리팅은 코드를 다양한 청크(chunk)로 나눌 수 있으며 필요에 따라 로드할 수 있다. 페이지 렌더링에 필요한 초기 응답 크기를 줄이는데 도움이 된다. 글에서는 Vue 프로젝트에서 적절한 예시를 통해 코드 스플리팅을 알아본다.

라이트하우스 버전 6에서는 새로운 지표인 Largest Contentful Paint (LCP)와 Total Blocking Time (TBT)가 First CPU Idle (FCI) and First Meaningful Paint (FMP)를 대체하고 있다. 5가지 지표의 각 가중치는 로드와 상호작용 측정의 다른 위상을 더 균형있게 맞추기 위해 조정될 것이다.

TOAST UI Grid는 자체적인 반응형 시스템을 구축하여 데이터의 상태 관리를 하고 있다. 데이터가 변경되면 반응형 시스템이 변경을 감지하고 있는 다른 데이터 속성들도 자동으로 갱신해주기 때문에 데이터의 변경 관리를 편리하게 할 수 있었고, 간결하면서도 선언적인 코드를 사용할 수 있어 불필요한 코드도 줄일 수 있었다. 하지만 대용량 데이터를 반응형 데이터로 변경할 때 치명적인 성능 문제가 있었고, 그리드의 초기 렌더링 속도 저하를 유발했다

유저들은 반응이 빠른 UI를 선호한다. 100ms 미만의 UI 응답 지연은 유저들이 즉시 느낄 수 있고, 100ms에서 300ms가 지연되면 이미 유저들은 상당한 지연으로 느낀다. UI 성능을 증가시키기 위해, React는 고차 컴퍼넌트(Higher Order Component, HOC) `React.memo()`를 제공한다. 렌더링 결과를 메모이징(Memoizing)함으로써, 불필요한 리렌더링을 건너뛴다.

React.memo, PureComponent 또는 shouldComponentUpdate 를 사용하지 않고 최적화하는 방법. 필자는 리액트의 리렌더링과 관련된 주제로 블로그 글을 준비하다가 당신이 감사할만한 이 작은 보석같은 리액트 지식을 발견했다. 이 글을 읽고 난 후, Brooks Lybrand는 이 트릭을 적용하였고 아래와 같은 결과를 얻었다. 흥미롭지 않은가? 그럼 인위적으로 작성한 간단한 예제를 보고 실제 앱에서 어떻게 적용할 수 있을지 이야기 해보자.

성능이 매우 중요한 코드를 작성할 때는 알고리즘 복잡도를 생각하는 것이 좋다. 알고리즘 복잡도는 대개 Big-O 노테이션으로 표현된다. Big-O는 데이터가 많아질수록 코드가 얼마나 느려지는가의 척도가 된다. 예를 들어, 정렬 알고리즘의 복잡도가 O(n²)이라고 할 때, 50배 많은 개수의 아이템을 정렬하면 대략 50² 즉, 2,500배 느려지게 된다. Big-O는 정확한 수치를 나타내지 않는 대신, 알고리즘의 규모를 이해하는 데 도움을 준다. 아래처럼 Big-O 표현을 보면 얼마나 복잡한 알고리즘인지 알 수 있다.

자바스크립트의 객체와 함수가 참조형이라는 개념은 React의 성능에 직접적인 영향을 끼침에도 불구하고 많이 다뤄지지 않고 있다. 예를들어, 내용이 완전히 같은 함수를 두 개 만들더라도 두 함수는 절대 같지 않다. 다음과 같이 작성해보자. 다른 언어들을 사용해본 경험이 있다면 포인터라는 개념이 친숙할 것이다. 객체를 만들거나 기기의 메모리에 무언가를 할당할 때 마다 어떤 일이 일어나는 것일까?