TIL 2022-11-13 Island Architecture

SPA의 단점은 대량의 자바스크립트 번들을 한번에 가져오기 때문에 자바스크립트 번들을 가져오기 전까지의 딜레이가 컸다는 것이다.

 

이를 보완하기 위해 SSR에서는 정적으로 생성된 HTML을 먼저 보여주고, 이를 자바스크립트 코드로 hydrate시키는 과정을 통해 이를 해결하려 했음.

 

Rehydration은 비용이 들고, hydrate하기 전까지 아무 반응도 없는 HTM 쪼가리이기 때문에, 이를 최적화하려는 시도를 많이 했음.

 

Partial hydration, Streaming 등

 

그러나 이들의 단점은 결국에 최종적으로 hydrate하는 자바스크립트의 총량은 동일하다는 거임.

 

Island 구조에서는 Interaction이 아예 없는 정적 island와 hydration이 필요한 동적 island의 조합으로 봄.

 

정적 Island = Rehydration이 필요없는 non-interative HTML 덩어리

동적 Island = HTML + 렌더링 이후 스스로 hydration할 스크립트

 

Progressive hydration에서는 탑다운 방식으로 페이지가 어떤거 먼저 hydrate할지 등을 조절하는 방식이었다면, Island 구조에서는 각각의 동적 Island 요소가 비동기적으로 hydrate하며, 서로가 영향을 끼치지 않음.

 

 

Island를 구현하려면

 

- 서버측의 자바스크립트를 하나도 사용하지 않고 정적 렌더링이 가능해야함

- 정적 콘텐츠 사이에 placeholder를 사용해서 동적 컴포넌트를 넣을수 있어야하며, 메인 쓰레드가 비었으면 requestIdleCallback()을 통해 스스로 hydrate해줄수 있어야함

- 서버 - 클라이언트 양 끝단에서 동일한 요소란걸 인식할수 있도록 Isomorphic rendering 지원해야함

 

 

 

장점

 

성능

- Hydrate하지 않아도 되는 정적 Island가 있다는건 가져와야하는 자바스크립트 양이 줄었다는 것이고 First page load, time to interative 둘다 빠를수 밖에 없음..

- SEO : 정적 컨텐츠들은 서버에서 렌더링되므로 SEO Friendly함

- 정적 컨텐츠들은 대체로 블로그 글, 같은 주요 내용인데, 이것들은 바로 유저에게 제공됨

- 접근성: HashBang 같은고 안쓰는 근본 HTML Links이기 떄문에 접근성이 좋음

 

단점

Static Island가 적은, Interaction이 많은 페이지에서는 적합하지 않음.