2016년 11월 9일 수요일
프로그레시브 웹 앱(PWA)은 웹에서 가장 눈길을 끄는 새로운 아이디어 중 하나로, 새로운 기술의 장점을 사용해 사용자가 모바일 사이트와 기본 앱을 최대한으로 활용할 수 있게 해줍니다. 하지만 PWA가 진정으로 영향력을 가지려면 색인 생성 및 연결이 가능해야 합니다. 이 문서에서 제시하는 모든 권장사항은 프로그레시브 웹 앱을 만드는지, 아니면 간단한 정적 웹사이트를 만드는지와 관계가 없으며, 색인 생성에 관한 기존의 권장사항입니다. 하지만 웹마스터 여러분께 체크리스트를 제공하기 위해 이러한 권장사항을 모아 보았습니다.
콘텐츠를 크롤링 가능하게 만들기
이유가 무엇인가요? 과거, 웹사이트에서는 항상 서버에서 HTML을 생성하거나 렌더링하곤 했으며 이것이 콘텐츠를 직접 연결할 수 있는 가장 간단한 방법이었습니다. 웹 애플리케이션이 등장하면서 클라이언트 측 렌더링이라는 개념이 일반화되었습니다. 이를 통해 사용자가 페이지를 탐색하고 있는 동안에도 페이지를 다시 로드할 필요 없이 콘텐츠가 페이지에서 동적으로 업로드되는 것이 가능해졌습니다.
보다 현대적인 접근방식이 하이브리드 렌더링입니다. 사용자가 URL로 직접 이동할 때는 서버 측 렌더링을 사용하고, 후속 탐색 및 비동기 요청을 위해 최초로 페이지를 로드하고 난 이후에는 클라이언트 측 렌더링을 사용하는 것입니다.
서버측 PWA 샘플은 순수한 서버 측 렌더링을 보여주며, 하이브리드 PWA 샘플은 두 가지가 결합된 모습을 보여줍니다.
서버 측 렌더링 및 클라이언트 측 렌더링이라는 용어에 익숙하지 않다면 클라이언트 측 렌더링과 서버 측 렌더링 및 반응 및 node.js에서의 서버 측 렌더링에서 도움말을 확인하세요.
권장사항:
사용자가 웹 요청의 최초 페이로드를 통해 콘텐츠를 수신할 수 있도록 서버 측 또는 하이브리드 렌더링을 사용합니다.
항상 URL에 독립적으로 액세스할 수 있는지 확인합니다.
https://www.example.com/product/25/
위의 URL은 해당하는 특정 리소스에 딥 링크되어야 합니다.
프로그레시브 웹 앱에 서버 측 또는 하이브리드 렌더링을 지원할 수 없고 클라이언트 측 렌더링을 사용하기로 결정한 경우 Google Search Console의 'Fetch as Google 도구'를 사용하여 콘텐츠가 Google 검색 크롤러에 의해 렌더링되는지 확인하는 것이 좋습니다.
웹 앱 홈페이지로 다시 연결되는 딥 링크에 액세스하도록 사용자를 리디렉션하지 마세요.
또한 사용자를 대상으로 딥 링크 대신 오류 페이지를 게재하는 것도 피해야 할 사항입니다.
깔끔한 URL 제공하기
이유가 무엇인가요? 프래그먼트 식별자(#user/24601/ 또는 #!user/24601/)는 브라우저에서 페이지를 다시 로드하지 않고도 서버에 있는 새로운 콘텐츠에 AJAX를 적용할 수 있게 만든 효과적인 해결책이었습니다.
이러한 설계를 클라이언트 측 렌더링이라고 합니다.
하지만 프래그먼트 식별자 구문은 일부 웹 도구, 프레임워크 및 Facebook의 Open Graph 프로토콜과 같은 프로토콜과 호환되지 않습니다.
History API를 사용하면 프래그먼트 식별자 없이도 URL을 업데이트할 수 있을 뿐 아니라 비동기식으로 리소스를 가져옴으로써 페이지 리로드를 피할 수 있습니다. 즉, 두 가지 방식의 장점을 모두 취할 수 있는 것입니다. AJAX 크롤링 기법(#!/이스케이프 처리된 프래그먼트 URL 포함)은 당시에는 적절했지만 이제는 더 이상 권장되지 않습니다.
하이브리드 PWA 및 클라이언트 측 PWA 샘플은 History API를 보여줍니다.
권장사항:
다음과 같이 프래그먼트 식별자(# 또는 #!)가 없는 안전한 URL을 제공합니다.
https://www.example.com/product/25/
클라이언트 측 렌더링이나 하이브리드 렌더링을 사용하는 경우 History API를 통해 브라우저 탐색을 지원하시기 바랍니다.
피해야 할 사항
#! URL 구조를 사용하여 고유한 URL을 구동하는 방식은 권장되지 않습니다.
https://www.example.com/#!product/25/
이는 History API가 등장하기 전에 해결책으로 제시됐던 방법이며, 순수한 # URL 구조와는 별개의 패턴으로 간주됩니다.
! 기호 없이 # URL 구조를 사용하는 방식은 지원되지 않습니다.
https://www.example.com/#product/25/
이 URL 구조는 이미 웹상에 있는 개념으로서 특정 페이지에 있는 콘텐츠와의 딥 링크와 연결되어 있습니다.
표준 URL 지정하기
이유가 무엇인가요? 여러 개의 URL(동일하거나 다른 도메인에서)에서 동일한 콘텐츠를 제공할 때 색인 생성의 혼동을 막는 가장 좋은 방법은 그중 한 페이지를 표준으로 표시하고 해당 콘텐츠가 중복된 다른 모든 페이지에서 표준 페이지를 참조하게 하는 것입니다.
권장사항:
특정 콘텐츠를 미러링하는 모든 페이지에 다음 태그를 포함합니다.
<link rel="canonical" href="https://www.example.com/your-url/" />
Accelerated Mobile Pages를 지원하는 경우 이에 해당하는 rel="amphtml" 명령을 올바르게 사용하시기 바랍니다.
피해야 할 사항
의도적으로 여러 URL에서 중복되는 콘텐츠를 사용하면서 rel="canonical" 링크 요소를 사용하지 않는 것은 피해야 합니다.
예를 들어 rel="canonical" 링크 요소를 사용하면 추적 매개변수가 있는 URL의 모호성을 줄일 수 있습니다.
여러 페이지 간에 상충되는 표준 참조를 만들어서는 안됩니다.
여러 기기를 위한 디자인
이유가 무엇인가요? 어떤 기기를 사용하건 웹사이트를 보는 모든 사용자가 최고의 경험을 하는 것이 중요합니다.
사이트에서 반응 속도가 우수한 디자인을 사용하시기 바랍니다. 화면 해상도와 기기 표시 영역에 따라 글꼴, 여백, 패딩, 버튼 및 사이트의 일반적인 디자인이 동적으로 확장될 수 있어야 합니다.
작은 이미지를 데스크톱이나 태블릿 기기에서 확대하게 되면 보기에 좋지 않습니다. 반대로 해상도가 매우 높은 이미지를 휴대전화에서 다운로드하려면 시간이 오래 걸리며 화면 스크롤 성능에 영향을 줄 수 있습니다.
PWA를 위한 UX에 관해 자세히 알아보기
권장사항:
기기 화면에 표시할 수 있는 것보다 더 큰 이미지를 다운로드하지 않으려면 srcset 속성을 사용하여 밀도가 서로 다른 여러 화면에 적합하도록 다양한 해상도 이미지를 가져옵니다.
기기 크기와 상관없이 텍스트를 읽을 수 있도록 글꼴 크기와 행 간격을 넓힙니다. 마찬가지로 요소의 패딩과 여백도 합리적인 크기로 조정합니다.
Chrome 개발자 도구의 기기 모드 기능과 모바일 친화성 테스트 도구를 사용해 여러 화면 해상도를 확인하세요.
사용자에게 Google에 표시되는 것과 다른 콘텐츠를 표시하지 않습니다. 다양한 기기에 맞춰 리디렉션 또는 사용자 에이전트 감지(일명 브라우저 스니핑 또는 동적 게재)를 사용해 사이트 디자인을 변경하더라도 콘텐츠 자체는 동일하게 유지되어야 합니다
Search Console의 'Fetch as Google' 도구를 사용하여 Google이 가져온 콘텐츠가 사용자에게 표시되는 콘텐츠와 일치하는지 확인하세요.
사용 편의성을 확보할 수 있도록 크기가 고정된 글꼴은 사용하지 마세요.
반복적으로 개발하기
이유가 무엇인가요? 웹 애플리케이션에 기능을 추가할 때 가장 안전한 방법 중 하나는 반복적으로 변경하는 것입니다. 한 번에 하나씩 기능을 추가하면 각 변경사항이 어떤 영향을 주는지 관찰할 수 있습니다.
상당수의 개발자들이 프로그레시브 웹 애플리케이션에 대해 한 번에 모바일 사이트를 뜯어고칠 기회라고 생각하는 경향이 있습니다. 그래서 고립된 환경에서 새로운 웹 앱을 개발한 뒤 준비가 되면 기존의 모바일 사이트와 교체해 버립니다.
기능을 반복적으로 개발할 때는 변경사항을 따로 따로 분리하여 시도해보시기 바랍니다. 예를 들어 서버 측 렌더링을 사용하다가 하이브리드 렌더링으로 바꾸려고 하는 경우 이 과정을 다른 기능과 묶어서 생각하기보다는 별도의 반복 과정으로 처리하세요.
두 가지 방법 모두 각각 장단점이 있습니다. 반복을 사용하면 전환이 연속적으로 이뤄지기 때문에 검색의 색인 생성 가능 여부를 처리하기가 덜 복잡해집니다. 하지만 개발이 백지 상태에서 시작되지 않는 경우라면 반복을 사용하는 것 때문에 개발 과정이 느려지고 사이트를 정비하는 과정에서 혁신성이 떨어질 수 있습니다.
어떤 상황에서건 가장 민감하게 주시해야 할 부분은 표준 URL 및 사이트의 robots.txt 구성입니다.
권장사항:
새로운 기능을 한 부분씩 추가함으로써 웹사이트에서 점진적으로 과정을 반복합니다.
예를 들어 아직 HTTPS를 지원하지 않는 경우 보안 사이트로 이전하는 것부터 시작합니다.
피해야 할 사항
고립된 환경에서 프로그레시브 웹 앱을 개발한 경우 rel-canonical 링크 및 robots.txt가 적절하게 설정되었는지 확인하지 않은 상태로 프로그레시브 웹 앱을 실행하지 마시기 바랍니다.
rel-canonical 링크가 실제 사이트를 가리키는지, robots.txt 구성에서 크롤러가 새로운 사이트를 크롤링할 수 있도록 허용하는지 확인하세요.
출시하기 전 아직 개발 단계에 있는 사이트에 대해 크롤러가 색인을 생성하지 못하게 막는 것은 당연합니다. 하지만 사이트를 출시한 후에는 크롤러가 새로운 사이트에 액세스할 수 있도록 차단을 해제하시기 바랍니다.
점진적 개선 사용하기
이유가 무엇인가요? 가능하면 브라우저의 기능을 사용하기 전에 미리 감지하는 것이 중요합니다. 특정 기능을 지원한다고 생각하는 브라우저에서 테스트하기보다는 기능을 감지하는 것이 더 좋습니다.
사용자가 어떤 브라우저를 갖고 있는지 테스트하여 기능을 사용하거나 사용 중지하는 것은 좋지 않은 관행이지만 예전에는 일반적으로 이뤄졌습니다. 하지만 브라우저는 여러 기능과 더불어 지속적으로 진화하고 있으므로 이 방법을 사용하는 것은 바람직하지 않습니다.
Service Worker는 비교적 새로운 기술이며 발전을 위해서는 호환성을 이어가는 것이 중요합니다. Service Worker야말로 점진적 개선 방식을 사용하기에 완벽한 사례입니다.
권장사항:
Service Worker에 등록하기 전에 Service Worker API를 사용할 수 있는지 확인합니다.
if ('serviceWorker' in navigator) {
...
모든 웹사이트의 기능에 맞는 API 감지 방법에 따라 사용합니다.
웹 앱에서 기능을 사용하거나 사용 중지하기 위해 브라우저의 사용자 에이전트를 사용하지 마세요. 언제나 해당 기능의 API를 사용할 수 있는지 확인하고 사용할 수 없는 경우 단계적으로 성능을 저하시키세요.
여러 브라우저에서 테스트하지 않은 상태에서 사이트를 업데이트하거나 출시하지 마시기 바랍니다. 사이트 분석을 확인하여 어떤 브라우저가 사용자에게 가장 인기 있는지 알아보세요.
Search Console을 사용해 테스트하기
이유가 무엇인가요? Google 검색에서 사이트의 콘텐츠를 어떻게 인식하는지 이해하는 것이 중요합니다. Search Console을 사용하여 사이트에서 개별 URL을 가져올 수 있으며 'Crawl > Fetch as Google' 기능을 사용하여 Google 검색에서 이러한 URL을 어떻게 인식하는지 확인할 수 있습니다. 이 옵션이 선택되면 Search Console에서는 자바스크립트를 처리하고 페이지를 렌더링합니다. 그렇지 않은 경우 원시 HTML 응답만 표시합니다.
또한 Google Search Console은 구조화된 데이터, 리치 카드, 사이트링크, AMP의 존재를 감지하는 등 다양한 방법으로 페이지에 있는 콘텐츠를 분석합니다.
권장사항:
Search Console을 사용하여 사이트를 모니터링하고 'Fetch as Google' 등의 기능을 살펴봅니다.
Search Console의 Crawl > Sitemaps를 사용하여 사이트맵을 제공합니다. 이는 Google 검색이 사이트의 모든 페이지를 인식할 수 있게 하는 효과적인 방법입니다.
Schema.org 구조화된 데이터를 사용하여 주석 달기
이유가 무엇인가요? 구조화된 Schema.org 데이터는 페이지에 있는 가장 중요한 부분을 기계에서 처리할 수 있는 데이터로 요약하는 유연한 어휘입니다. 어떤 페이지에 대해 NewsArticle이라고 아주 개략적으로 표현할 수도 있고, 투어 중인 밴드의 위치, 밴드 이름, 장소, 티켓 공급업체 등을 알리거나 어떤 레시피에 사용되는 재료와 요리 단계를 요약하는 것처럼 상당히 구체적일 수도 있습니다.
이러한 메타데이터가 웹 애플리케이션의 모든 페이지에 적용 가능한 것은 아니지만 사용하는 편이 합리적이라면 사용하는 것이 좋습니다. Google은 페이지가 렌더링된 후 추출합니다.
데이터에는 NewsArticle, Recipe, Product 등 다양한 유형이 있습니다. 여기에서 지원되는 데이터 유형을 모두 살펴보세요.
페이지의 실제 콘텐츠와 일치하지 않는 데이터 형식을 사용하지 마세요. 예를 들어 내가 티셔츠를 판매한다면 Recipe 대신 Product를 사용하세요.
Open Graph 및 Twitter 카드를 사용하여 주석 달기
이유가 무엇인가요? Schema.org 메타데이터와 더불어 Facebook의 Open Graph 프로토콜과 Twitter 리치 카드 지원을 추가하는 것도 도움이 됩니다.
이러한 메타데이터 형식은 소셜 네트워크에 콘텐츠를 공유하는 상황에서 사용자 경험을 개선합니다.
기존 사이트나 웹 애플리케이션에서 이러한 형식을 사용하는 경우 프로그레시브 웹 애플리케이션에 포함되도록 하는 것이 화제성을 높이는 데에도 도움이 됩니다.
기존 사이트에서 이러한 형식을 지원한다면 사이트에 꼭 포함시키세요.
여러 브라우저에서 테스트하기
이유가 무엇인가요? 사용자 입장에서는 웹사이트가 모든 브라우저에서 동일하게 동작하는 것이 중요합니다. 서로 다른 화면 크기에 따라 사용 환경은 달라질 수 있지만, iPhone이건 Android 휴대전화이건 크기가 비슷한 기기에서는 모바일 사이트가 동일하게 작동할 것이라고 기대하게 마련입니다.
세계적으로 다양한 브라우저가 사용되고 있기 때문에 웹이 분할된 공간처럼 인식될 수도 있지만, 이러한 다양성 및 경쟁이야말로 웹이 혁신적인 플랫폼이 될 수 있는 이유이기도 합니다. 다행히도 지금의 웹 표준은 그 어느 때보다도 발전된 상태이며, 개발자는 최신의 도구를 활용하여 다양한 브라우저를 상호 지원하는 웹사이트를 마음 편히 개발할 수 있습니다.
권장사항:
BrowserStack.com, Browserling.com 또는 BrowserShots.org와 같은 교차 브라우저 테스트 도구를 사용하여 PWA가 브라우저 간에 호환되는지 확인합니다.
페이지 로드 성능 측정하기
이유가 무엇인가요? 사용자에게 웹사이트가 빠르게 로드될수록 사용자 경험은 개선됩니다. 페이지 속도를 최적화하는 것은 웹 개발에 있어서 이미 잘 알려진 중요 포인트지만, 사이트의 새로운 버전을 개발하는 과정에서 이처럼 필수적인 최적화 요소가 우선순위에서 밀리는 경우도 있습니다.
프로그레시브 웹 애플리케이션을 개발할 때는 페이지 로드 속도 성능을 측정하고, 최고의 결과를 얻기 위해 사이트 출시 전에 최적화하는 것을 권장합니다.
권장사항:
Page Speed Insights와 웹페이지 테스트 등의 도구를 사용하여 사이트의 페이지 로드 성능을 측정합니다. Googlebot은 렌더링 과정을 좀 더 여유있게 기다리지만 연구에 따르면 사용자 중 40%가 페이지를 로드하는 데 3초가 넘게 걸리면 페이지를 떠납니다.
Google의 웹페이지 성능 권장사항과 중요한 렌더링 경로를 여기에서 자세히 알아보세요.
최적화를 출시 이후 단계로 미루지 마세요. 새로운 프로그레시브 웹 애플리케이션으로 이전하기 전에 웹사이트 콘텐츠가 빠르게 로드되고 있었다면 최적화로 인해 이러한 성능이 저하되지 않도록 하는 것이 중요합니다.
위의 체크리스트가 색인 생성 가능성을 염두에 두고 프로그레시브 웹 애플리케이션을 개발하는 데 있어 유용하고 올바른 가이드가 되길 바랍니다.
시작할 때 클라이언트측, 서버측, 하이브리드 렌더링을 보여주는 프로그레시브 웹 앱 색인 생성 여부 샘플을 확인하시기 바랍니다. 늘 그렇듯이 궁금한 점이 있으면 웹마스터 포럼에 문의해 주세요.