PWA

0. 앞선 글.

 

많은 이들이 모던 웹 개발하면 PWA와 SPA를 손꼽습니다. 실제로 제 글에서도 그렇게 소개를 했고요. 그렇게 알고 넘어갔는데 웹을 돌아다니던 중 다음과 같은 글을 발견했습니다.

 

https://itnext.io/the-state-of-progressive-web-apps-adoption-by-developers-8b119783d3b9

 

The State Of Progressive Web Apps Adoption By Developers

Are PWA preached or adopted by developers? Do they use these despite the lack of support on iOS? Here are some hints I gathered with polls…

itnext.io

 

눈이 갈 수밖에 없는 글이었습니다. PWA가 좋다곤 하는데 과연 얼마나 많은 개발자들이 PWA를 구현해서 사용하고 있을까요? 실제로 궁금하여 글을 읽고 내용을 공유하기 위해 한글 번역글을 남깁니다.

 

 

 

1. 프로그레시브 웹 앱의 채택 상태.

 

PWA가 개발자에 의해 전파되거나 선택되었나요? 그들은 iOS에서의 지원이 부족함에도 불구하고 PWA를 하나요? 지난 며칠간의 조사에서 수집한 몇 가지 힌트가 여기 있습니다.

 

Photo by YTCount on Unsplash

 

이번 주 "Apple vs Hey"이야기에 이어서 이러한 이슈에 대한 해결책으로 볼 수 있는 PWA가 대부분 개발자들에게 전파되었거나 실제로 이미 채택되었는지가 궁금했습니다. 

 

이런 나의 질문에 답하기 위해 트위터에서 설문조사를 실시하였고 이 새 블로그 게시물에 여러분과 공유하고 싶은 몇 가지 흥미로운 사실을 알게 되었습니다.

 

 

 

2. 한계점.

 

전 통계의 전문가도 아니고 조사 결과를 해석하는 전문가도 아닙니다. 또한 이 조사는 트위터에서 이루어졌으며 SNS를 통해 답변을 받았으므로 아마 충분하지 않을 수도 있습니다.

 

그러므로 이 글에서 읽은 내용을 당연하다고 생각하지는 말아주세요. 이글의 수치와 의견들을 더도 말고 덜도 말고 그저 힌트로만 봐주시기 바랍니다.

 

또한 저는 PWA의 열렬한 애호가입니다. 공정성을 유지하기 위해 노력할 수 있지만 동등한 경우에는 아마 PWA에 대해 부정적이기보단 긍정적일 겁니다.

 

 

 

3. 47%의 개발자는 PWA를 사용하지 않습니다.

 

나는 DEV.to의 PWA를 거의 매일 이용하고 있으며 트위터도 그러려고 하고 있습니다. 그러나 난 내가 내 핸드폰에서 매주 다른 것을 사용하고 있다고 생각하지 않았습니다. 그것이 처음 이 질문에 관심을 갖고 선택한 이유입니다.

 

놀랍게도 개발자의 47% 는 홈 화면에 설치된 PWA를 사용하고 있지 않습니다.

 

많은 개발자가 브라우저와 함께 PWA를 사용하고 있기 때문에 실제로는 숫자가 낮아야 한다고 생각하는 경향이 있지만 이 숫자는 꽤나 중요합니다.

 

물론 다음 장에서 볼 수 있듯이 이러한 낮은 비율의 주된 이유는 iOS에서 PWA에 대한 적절한 지원이 없기 때문입니다.

 

그럼에도 불구하고 이건 여전히 두 명의 개발자 중 거의 한 명이 PWA를 사용하지 않는다는 것을 의미하며 이는 개인적으로 모바일 기기에서 기술의 미래에 대해 약간의 걱정을 갖게 만듭니다. 응용프로그램을 프로그래밍하는 개발자가 응용프로그램을 사용하지 않거나 사용할 수 없다면 많은 사람들이 어떻게 받아들일까요?

 

반면에 긍정적인 점은 유리잔의 반은 비어있다기 보단 차 있다는 것입니다. 개발자 중 3명 중 1명꼴인 29% 는 매주 두 개 이상의 PWA를 사용합니다. 

 

https://bit.ly/3gbFUOI

 

 

또 흥미로운 점은 일부 개발자들은 PWA를 홈 화면에 고정해 두지 않을 채 데스크톱에서 여러 PWA를 사용하고 있다는 것입니다.

 

이것은 다음과 같은 생각으로 이어졌습니다: PWA의 미래가 실제로 모바일 폰이 첫 번째 장소가 아니라 데스크톱이었다면 어떨까요? 실제로 데스크톱이 모바일보다 먼저 인기를 얻으려면 어떻게 해야 할까요? 만약 이런 가정이 사실이면 구글의 크롬북은 적절했을까요? 아니면 구글은 크롬북을 믿고 PWA를 추진했을까요?

 

아마 너무 과한 해석과 과장이지만 난 정말로 이런 식으로 발전할지 안 할지를 알고 싶어 미래를 기다리고 있습니다. 

 

 

 

4. PWA를 사용하지 않는 사람들의 63%는 iOS를 사용합니다.

 

위에서 말했듯이 iOS의 부분적인 지원은 개발자가 PWA를 사용하지 않는 주된 이유입니다. PWA를 사용하지 않는 이들 중 63 %는 iPhone을 가지고 있습니다. 이는 모든 개발자의 30 %가 단순히 Apple에서 만든 전화를 가지고 있기 때문에 PWA를 사용하지 않는 것을 의미합니다.

 

https://bit.ly/31ufIuM

 

부분적인 지원보다 제가 받은 의견에 따르면 개발자들은 애플이 자동으로 "홈 화면에 추가하기"를 보여주지 않기 때문에 iOS에서 PWA 사용을 포기하는 것 같습니다. 애플은 Apple은 다른 브라우저를 통해 이러한 기능을 애플 기기에 구현하지 못하게 했습니다. 

 

나는 그것을 시도했고 맞았습니다. UX는 약간 실망스럽지만 iOS 홈 화면에 PWA를 설치할 수 있습니다. 관심이 있으시면 다음 트윗대로 진행하세요.

 

https://bit.ly/2VvkT9L

 

홈 화면에 웹 사이트를 추가할 수 있지만 적절한 PWA인 웹 사이트만 독립 실행형 앱으로 작동합니다. 정확한 피드백에 대해 Julio에게 감사드립니다.

 

나는 안드로이드에서 Firefox 모바일의 "홈 화면에 추가"UX를 시도해 보았습니다. 믿거나 말거나 그것이 실제로 최고라고 생각합니다. 크롬은 훌륭하지만 파이어 폭스는 나의 손을 이끌리게 했으며 "이봐 David 내가 여기 PWA를 네 폰에 올바르게 추가하는 방법을 보여줄게"라고 말하는듯한 느낌이 들었습니다.

 

파이어폭스의 디자이너가 이 글을 읽게 될지 모르겠지만 축하합니다. 대단한 일입니다!

 

https://bit.ly/2Vzl4Bc

 

5. 개발자의 8%가 Google Play의 앱을 좋아합니다.

 

모든 개발자의 30%가 iPhone으로 인해 PWA를 사용하지 않는다 하더라도 PWA 친화적인 안드로이드 폰을 소유하고 있는 17%의 개발자들 역시 PWA를 사용하지 않습니다. 이것이 마지막 설문조사를 실시한 이유입니다. 왜일까요?

 

가능한 해결책에 대해 생각하는데 시간이 걸렸으며 내 제안으로 설문 조사를 너무 편향적으로 만들지 않을까 걱정했습니다. 아마 오픈된 질문을 하는 게 더 나을 겁니다.

 

안드로이드에서 PWA를 사용하지 않는 전체의 7%에서 대부분의 개발자인 44%는 스토어나 Google Play의 UX나 디자인이 좋다고 느끼기 때문에 PWA를 사용하지 않습니다. 

 

솔직히 말해서 나는 이러한 사실을 해석하는 방법을 모르겠습니다. 내게도 같은 이유로 나쁜 기본 앱만큼 못생기고 성능이 좋지 않은 웹 애플리케이션이 있을 수도 있습니다. 나는 그게 개념과 실행에 관한 것이라고 생각합니다. 기술에 관계없이 나쁘게 구현되거나 디자인된 경우 결국에는 놀랍지 않을 것입니다.

 

https://bit.ly/2ZqJDRI

 

주목할만한 점: PWA가 저가형 장치에 가장 적합하다고 언급한 피드백에 따라 KaiOS가 PWA를 지원하는지 궁금합니다. 맞춰볼까요? KaiOS은 PWA를 지원할 뿐만 아니라 이를 스토어에 게시할 수도 있습니다.

 

 

 

6. 결론

 

PWA의 미래는 데스크톱일까요? 아니면 KaiOS 매장과 Google Play에 모두 게시할 수 있는 모바일 기기가 미래가 될까요? 아니면 언젠가 EU가 애플을 PWA 친화적으로 만들까요? 그 누가 알겠습니까...

 

그러나 확실히 나는 몇 가지 흥미로운 힌트를 배웠으며 앞으로도 PWA를 믿습니다.

 

또한, 저는 2021년 6월 달력에 이런 조사를 다시 실시하기 위해 미리 알림을 추가했습니다. 내년에는 이 주제가 어떻게 진화했는지 살펴보겠습니다.

 

당신의 의견과 피드백을 기다리겠습니다. 

 

David

 

 

 

7. 맺음글

 

글이 오롯이 PWA의 채택률에 집중되어 있지 않다는 생각이 들긴 하지만 설문으로 얻어진 수치만을 보더라도 충분의 의미가 있다고 생각합니다.

 

모두가 모던 웹의 SPA와 PWA를 말하고 있지만 실제로 아직 많은 사람이 쓰고 있진 않단 걸 알 수 있는 글이었습니다. 

 

David의 말대로 내년에도 이와 같은 조사가 수행된다면 어떻게 바뀔지 궁금합니다. 

 

 

 

 

 

PWA, SEO, spa

 

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를 위해선 다음과 같은 요소가 반드시 필요합니다.

  1. HTTPS를 운영해야 합니다. 
  2. 웹 앱 매니페스트(Web App Manifest)가 있어야 합니다.
  3. 서비스 워커를 사용해야 압니다.

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 역시 모바일 환경에서의 웹의 사용성을 향상하는 일환으로 대두되고 있습니다. PWASPA를 직접적으로 포함하는 개념은 아니지만 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.

 

+ Recent posts