1. 목차
- PWA
- SPA
- SEO
- AMP
- Babel
- TypeScript
- JavaScript Framework
- Angular
- React
- Vue
2. PWA
PWA란?
프로그레시브 웹앱(Progressive Web Apps)은 Google I/O 2016에서 소개된 미래의 웹 기술이며, PWA라고 줄여서 부르기도 합니다. PWA는 최고의 웹과 최고의 앱을 결합한 경험을 일컫습니다. 쉽게 말하자면, PWA는 모바일 앱과 웹 기술의 장점을 결합한 것입니다.
왜 PWA를 도입해야 하는가? - Native 앱의 낮은 접근성
위 통계치에서 보듯이 모바일 사용자는 웹 보다 네이티브 앱을 더 많이 이용합니다. 문제는 대부분의 사용자는 새로운 앱을 거의 설치하지 않으며 자신이 사용하던 앱만 사용한다는 것입니다. 그에 반해 사용자들은 월평균 100개 이상의 새로운 사이트를 방문한다고 합니다.
결론은 바로 이것입니다. 네이티브 앱의 장점인 수용력과 웹의 장점인 접근성을 동시에 추구하는 것이 바로 PWA입니다.
PWA: 웹 앱을 구축하는 새로운 철학.
PWA는 브라우저를 통해 처음 방문한 사용자에게 유용하며, 설치가 필요하지 않습니다. PWA는 사용자가 관계를 점진적으로 형성할수록 성능이 더욱 강력해질 것입니다. 느린 네트워크에서도 빠르게 로드되고, 관련된 푸시 알림을 전송할 수 있습니다. 모바일 앱처럼 전체 화면으로 로드되고, 홈 화면에 아이콘이 표시됩니다.
( HTTPS, WebApp Manifest, Service Worker ) -> PWA
PWA를 위해선 다음과 같은 요소가 반드시 필요합니다.
- HTTPS를 운영해야 합니다.
- 웹 앱 매니페스트(Web App Manifest)가 있어야 합니다.
- 서비스 워커를 사용해야 압니다.
PWA는 운영체제의 여러 특별한 권한을 부여받기 때문에, 웹 서버와의 보안 연결(HTTPS)은 필수입니다. 웹 앱 매니페스트라는 이름만 보고 겁낼 필요는 없습니다. 단지 사이트와 관련된 정보를 담는 JSON 파일일 뿐입니다.
서비스 워커
서비스 워커는 브라우저가 백그라운드에서 실행하는 스크립트로, 웹페이지와는 별개로 작동하고 클라이언트에 설치되는 프록시입니다. 브라우저 백그라운드에서 네트워크를 가로채는 Thread Thread라고 이해하시면 됩니다.
서비스 워커는 오프라인 환경을 완벽히 통제할 수 있는 권한을 개발자에게 부여하여 오프라인 환경을 지원할 수 있도록 해주기 때문에 PWA에서 반드시 필요합니다.
단, 서비스 워커가 동작하는 브라우저를 미리 확인해야 하며 레거시 브라우저 (예를 들면 IE)에서는 동작하지 않을 수 있습니다.
2. SPA
SPA란?
단일 페이지 애플리케이션(Single Page Application, SPA)은 모던 웹의 패러다임입니다. SPA는 기본적으로 웹 애플리케이션에 필요한 모든 정적 리소스를 최초에 한번 다운로드합니다. 이후 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만을 전달받아 페이지를 갱신하므로 전체적인 트래픽을 감소시킬 수 있습니다. 또한 전체 페이지를 다시 렌더링 하지 않고 변경되는 부분만을 갱신하므로 새로고침이 발생하지 않아 네이티브 앱과 유사한 사용자 경험을 제공할 수 있습니다.
실제로 전통적인 MPA방식에서는 서버에서 렌더링 작업을 수행한 후 HTML을 클라이언트에 리턴하며 이 HTML의 내용대로 페이지를 새로고침 하게 됩니다.
그러나 SPA 방식에서는 서버에서 렌더링 작업을 수행하지 않으며 요청한 데이터 파일만 클라이언트로 리턴합니다. 이후 클라이언트에서는 이 데이터 파일을 토대로 다시 렌더링이 필요한 부분만 변경하여 새로고침 과정을 생략합니다.
Progressive Single Page Application
결국 SPA가 추구하는 핵심적인 가치는 웹의 UX 및 속도를 향상함으로써 사용성을 극대화하는 것이라 할 수 있습니다. 특히 모바일 환경에서는 트래픽 최소화와 속도 및 반응성, 사용성 등이 보다 중요한 이슈이므로 SPA 구조는 모바일 퍼스트(Mobile First) 전략에서는 거의 모범사례에 가까운 모델이라 할 수 있습니다.
앞서 설명한 PWA 역시 모바일 환경에서의 웹의 사용성을 향상하는 일환으로 대두되고 있습니다. PWA가 SPA를 직접적으로 포함하는 개념은 아니지만 SPA 구조는 PWA와 궁합이 잘 맞는 선택이며 PWA 방식으로 만들어진 웹은 대부분 SPA입니다.
모든 게 완벽한 실버 불릿일까?
SPA를 도입하면 다음과 같은 장점이 있습니다.
- 자연스러운 UX
- 필요한 리소스만 부분적으로 로딩하여 성능 향상.
- 서버의 탬플릿 연산을 클라이언트로 분산 가능.
- 컴포넌트 기반 개발에 용이함.
- 모바일에서 동일한 API를 사용하도록 설계 가능.
빠른 반응성과 화면 전환 애니메이션, 그리고 새로고침이 없는 자연스러운 UX, 모든 페이지를 로딩하지 않고 필요한 부분만 업데이트를 수행해 성능이 개선되며 모듈화 및 컴포넌트화를 통해 유지보수가 쉽고 개발이 편합니다.
그러나 실버 불릿은 없다 라는 말 대로 SPA는 장점만 존재하는 기술은 아닙니다. SPA를 도입하면 다음과 같은 문제점을 맞닥뜨리게 될 수 있습니다.
- 상대적으로 느린 초기 구동 속도.
- 어려운 검색엔진 최적화
- 보안 이슈
- 구형 브라우저 미지원
이러한 문제를 해결하기 위해선 추가적인 노력이 필요합니다.
상대적으로 느린 초기 구동 속도는 Lazy Loading을 사용해 필요한 데이터를 필요할 때 청크 단위로 받도록 함으로써 로딩 속도를 많이 개선할 수 있습니다.
대부분의 크롤러는 브라우저가 아니므로 렌더링 한 결과 페이지를 획득할 수 없습니다. 따라서 빈 페이지를 받게 되어 SPA는 검색 결과에 노출되지 않을 수 있습니다. 검색엔진 최적화는 별도로 설명하겠습니다.
SPA에서 보안 이슈의 핵심은 비즈니스 로직이 JS로 구현되어 있다는 점입니다. 이로 인해 클라이언트단에서 로직이 노출될 수 있으며 압축 및 난독화로 해결될 문제가 아니므로 설계상에서부터 고민해야 할 문제가 됩니다. 이 경우 핵심 로직은 서버에서 수행하도록 구현해야 합니다. 또한 당연한 말이지만 중요한 데이터의 경우 유효성 검사를 양측 모두에서 수행해야 합니다.
구형 브라우저 미지원 문제는 마땅한 방법이 없습니다. 초기 SPA 도입 시 꼭 IE를 사용해야 하는지 고민후 작업에 착수해야 합니다.
3. SEO
SEO란?
SEO란 Search Engine Optimization, 검색 엔진 최적화의 약자입니다. 대부분의 사이트는 검색엔진에 잘 노출될수록 좋습니다. 이는 당연히 마케팅에도 긍정적인 효과를 발휘합니다. 아무리 PWA와 SPA를 이용해 UX를 극대화시킨 사이트를 만들어 놓았더라도 실제 사용자가 검색할 수 없다면 무슨 소용일까요?
SPA... Empty page?
위에서 잠깐 설명했지만 크롤러는 브라우저가 아닙니다. 크롤러가 SPA로 만들어진 사이트를 방문하면 다음과 같은 페이지를 획득할 것입니다.
크롤러는 내용이 전혀 없는 빈 페이지로 인식할 것입니다. 이렇게 되면 검색되어도 내용이 없는 페이지로 보이거나 심지어 검색이 되지 않을 수도 있습니다.
SEO에는 여러 다양한 기법이 있습니다만 이번에는 SPA로 인해 발생한 문제를 해결하기 위한 SEO방법에 대해서만 알아보도록 합니다.
메타 태그만 넣어주기.
클라이언트 측에 렌더링 하지는 않고, 서버 쪽에서 라우트에 따라 필요한 메타태그만 넣어주는 방법입니다. SNS 공유를 할 때 내용이 잘 전달되게 할 때 매우 적합한 방식입니다. 이러면 크롤러에선 해당 페이지에 대한 기본 정보는 얻어 갈 수 있게 됩니다.
실제로 facebook을 비롯한 SNS에서 신경 써줘야 할 부분은 내가 서비스하고 있는 URL의 링크와 미리 보기 같은 기능이 정상적으로 작동하는가입니다.
Prerender 사용하기.
Prerender는 아예 자바스크립트 렌더링 엔진을 갖고 있습니다. 따라서 코드를 문자열 형태로 변환을 하는 게 아니라 자바스크립트 코드를 실행시켜 뷰를 렌더링 한 결괏값을 반환합니다. 렌더링 속도는 그렇게 빠르지 않기 때문에 이 서비스는 오직 검색엔진 최적화를 위해서만 사용됩니다. 크롤러 봇이 해당 페이지에 들어온 경우에만 대신 렌더링을 해줘서 반환을 해주는 것이죠.
Prerender는 상용 서비스입니다. 미리 렌더링 해야 할 페이지의 수와 캐싱 주기에 따라 가격이 달라집니다.
자세한 내용은 공식 홈페이지를 참조해 주시기 바랍니다.
SSR
전통적인 MPA에서는 SEO 관련 이슈가 적었습니다. 전통적인 MPA의 경우 브라우저에서 JavaScript 코드가 동작하기 전에도 완성된 형태의 탬플릿(HTML에 데이터가 삽입된 상태)을 서버로부터 전달받습니다. 이 때문에 JavaScript 를 구동하지 않는 모르는 검색 로봇이 페이지를 크롤링하기에 매우 매우 적합합니다.
문제는 이런 방식으로 렌더링을 하다 보면 SPA를 도입한 장점을 포기해야 한다는 점입니다. 이러한 문제를 해결하기 위해서 구글에서는 "Dynamic Rendering"이라는 개념을 발표했습니다.
Dynamic Rendering
"현재는 자바 스크립트를 처리하기가 어렵고 모든 검색 엔진 크롤러가 자바 스크립트를 성공적으로 또는 즉시 처리할 수 있는 것은 아닙니다. 앞으로는 이 문제를 해결할 수 있기를 희망하지만 그동안 이 문제에 대한 해결 방법으로 동적 렌더링을 권장합니다. 동적 렌더링은 특정 사용자 에이전트에 대해 클라이언트 측 렌더링 콘텐츠와 사전 렌더링 된 콘텐츠 간 전환을 의미합니다."
동적 렌더링을 위해서는 웹 서버가 사용자 에이전트 확인 등의 방법으로 크롤러를 감지해야 합니다. 크롤러의 요청은 렌더러로 라우팅 되고 사용자의 요청은 정상적으로 제공됩니다. 필요한 경우 동적 렌더러는 크롤러에 적합한 콘텐츠 버전을 제공합니다. 예를 들어 정적 HTML 버전을 제공할 수 있습니다. 모든 페이지 또는 페이지마다 동적 렌더러를 사용하도록 선택할 수 있습니다.
동적 렌더링을 사용하면 사이트의 구조를 변경할 필요가 없습니다. 크고 빠르게 변하는 사이트에 적합할 수 있습니다만 별도의 렌더링 서버를 운영해야 할 수도 있습니다.
Hybrid Rendering
하이브리드 렌더링은 사실 새로운 개념이 아닙니다. 이것은 크롤러와 사용자 모두에게 정적 HTML을 제공하는 것을 의미합니다. 그런 후 나머지 항목을 표시하기 위해 JS를 실행하는 개념입니다.
* FCP: First Contentful Paint. 요청된 콘텐츠가 표시되는 시간.
* TTI: Time To Interactive. 요청된 페이지를 사용할 수 있을 때까지 걸리는 시간.
크롤러와 사용자 모두 정적 HTML을 전달받으므로 SEO를 해결할 수 있으며 빠른 페이지 로딩이 가능합니다. 문제는 가능한 모든 URL에 대해 개별 HTML 파일을 생성해야 한다는 것입니다. URL을 미리 예측할 수 없거나 고유 한 페이지가 많은 사이트의 경우 예측하기 어려울 수 있습니다.
References.
'Programming' 카테고리의 다른 글
2020년에 프론트 엔드 개발자가 배워야 할 10가지 (1) | 2019.12.16 |
---|---|
Front-end: Tech Trends (2) - AMP, Babel, TypeScript (0) | 2019.12.10 |
VisualStudio와 GitHub 연동하기 (0) | 2019.10.28 |
[SPA] SPA에서 SEO 문제 해결 (2) | 2019.10.04 |
[SPA] Single Page Application (0) | 2019.10.04 |