brunch

You can make anything
by writing

C.S.Lewis

by 이종우 Peter Lee Dec 19. 2019

[번역] 2020년에 봐야하는 6가지 웹성능 기술

원본 URL : https://simonhearne.com/2019/2020-predictions/?fbclid=IwAR3G6uZPfWpaF8vU-NH72WPcu--bcxGpMvMJfoxNrbapUVflfC58d-Ptps4



사이먼 하른 (웹성능 컨설턴트)                                                     게시 2019 년 11 월 25 일


5G와 HTTP / 3에 더 빠르게 투자하지 말고 2020 년에 웹 성능에 더 큰 영향을 줄 것으로 예상되는 6 가지 기술이 있습니다.


소개


기술 언론을 읽으면 2020 년이 웹 성능에있어 좋은 해가 될 것이라는 생각에 용서받을 것입니다. HTTP / 3가 가져올 근본적인 개선점과 새로운 노트북이 프리미엄 랩탑보다 더 빠를 것입니다.


이러한 전망으로 인해 성능에 대한 비 수용성이 부족해질 수 있습니다. 5G는 2025 년까지 가입자의 20 %까지 도달하지 않을 것으로 예상되며, HTTP / 3는 빛의 속도 나 JavaScript 번들의 크기를 변경하지 않으며 초고속 장치는 부유 한 소수의 손에 도달 할 것입니다. 이 기사에서는 2020 년에 웹 성능에 큰 영향을 줄 수 있다고 생각되는 기술 중 일부를 살펴 보겠습니다.


다음 섹션으로 바로 이동할 수 있습니다.

잼 스택 (JAMstack)

웹 어셈블리(Web Assembly)

에지 컴퓨팅 (Edge Compute)

관찰성능 (Obserablilty)

브라우저 플랫폼 개선 (Browser Platform Improvements)

웹 수익 창출 (Web Monetisation) 

존경 할만한 언급 (Honourable Mentions) 


2020 년에 빠른 웹을 원한다면 지금 조치를 취해야합니다.


5G 채택률 예측



5G는 느리게 배포되며 4G를 절대 대체하지는 않을 것입니다. 우리는 모바일 연결보다 5G 홈 광대역으로 더 나은 견인력을 볼 것이라고 믿습니다. 초당 20 기가비트의 데이터를 처리하면 2020의 기술보다 배터리에서 더 많은 주스를 추출 할 수 있기 때문입니다.


HTTP / 3는 HTTP / 2에서 스트림 우선 순위 의 결함있는 구현 을 희망적으로 수정합니다 . 프로토콜의 구현은 기본적으로 H / 2 (및 H / 1.x)와 다르지만 여전히 동일한 제약 조건 내에서 작동합니다. TCP의 혼잡 제어 구현에 의존하지는 않지만 여전히 제어하므로 응용 프로그램 계층에서 처리됩니다. H / 2는 광범위하게 출시 될 때까지 H / 1에 비해 획기적인 성과로 호평을 받았습니다. 많은 사이트에서 별다른 차이가 없었으며, 일부 사이트에서는 긍정적 인 개선이 이루어졌으며 일부 사이트에서는 상황이 악화되었습니다. H / 3는 개별 사이트의 아키텍처에 의해 정의 된 실제 이득과 유사한 결과를 보여줄 것입니다.


이 5G 및 H / 3 기술은 모두 네트워크 수준에 있습니다. 파이프가 어떻게 구축되고 정보를 가장 잘 얻는 방법입니다. 그러나 2019 년 JavaScript는 사용자 경험에 가장 큰 영향을 미칩니다. 1MB JS 응용 프로그램 번들을 500ms 더 빠른 중급 Android 전화로 배송하면 코드 처리에 걸리는 시간이 거의 없습니다. 미드 레인지 안드로이드 폰은 웹 사용자가 가지고있는 중간 장치이기 때문에 2019 년 1 분기 Apple의 시장 점유율 은 39 %, 삼성은 28 % 이고 나머지는 안드로이드 장치의 범위입니다. 500 달러에서 50 달러 사이에 판매합니다.

연령별 디지털 플랫폼 사용-젊은이는 앱에서 72 %의 시간을 소비합니다.


우리는 평균 미국인이 32 개월마다 휴대 전화를 바꾸고 있으며 전 세계적으로 프리미엄 브랜드 인 애플과 삼성의 시장 점유율은 33 %에 불과 하다는 것을 알고 있습니다 . 전 세계 사용자의 대다수가 중저가 Android 폰을 사용하고 있으며, 이러한 소비자는 성능 및 데이터 사용 제한이 인식되는 기본 앱으로 모바일 웹과 모바일 앱을 비교할 가능성이 훨씬 높습니다. 웹은 사람들이 기본 앱만 사용해야하는 개방적이고 민주적 인 장소입니다. 웹 경험에 대한 제한된 창과 그에 대한 지식이 있습니다.

다음 10 억 명의 사용자 중 절반에 대한 예측 된 인구 소스.



웹에서 지난 반년 동안 씩 서버와 씬 클라이언트에서 씬 서버와 씬 클라이언트로 근본적인 변화가있었습니다. Angular, React, Vue 및 많은 사촌과 같은 프레임 워크의 무한한 증가는 브라우저에서 상태를 관리하는 것이 서버에 대한 요청보다 빠르다는 가정에 의해 이루어졌습니다. 이 가정은 주력 모바일 장치를 가지고 있거나 주로 데스크탑 장치에서 작업하는 개발자가 만든 것으로 가정합니다. 우리는 이제 모든 웹 사이트가 SEO 측 크롤러를 달래기 위해 서버 측 렌더링 및 클라이언트 측 재수 화와 같은 해킹과 함께 전체 응용 프로그램 프레임 워크를 제공 할 수있는 위치에 있습니다. 이러한 추세는 2020 년에 코스를 변경하지는 않지만 더 나은 웹 플랫폼 기능을 고려할 수 있습니다.


2020 년에 웹 성능에 긍정적 인 변화가 될 것으로 생각되는 몇 가지 흥미로운 기술이 있습니다.


1-JAMstack


JAM (JavaScript API Markup) 스택은 정적 사이트 생성기를 사용하여 빠른 사이트를 제공하기 위한 아키텍처 입니다. Jekyll , Hugo 및 11ty와 같은 SSG 는 쾌적한 개발자 경험과 빠른 반복을 허용하지만 웹의 기본 언어 인 HTML로 컴파일합니다. 이 생성기는 현재 작은 설치 공간으로 인해 개인 블로그 또는 소규모 회사 사이트에 널리 사용됩니다. 대한 이동 헤드리스 CMS의 솔루션, 클라이언트 측 지불 API를 클라우드 배치를 효과적으로 성능에 중요한 요인으로 서버 처리 시간을 제거하고 배포하는 과정을 단순화, 뉴스 웹 사이트에서 전자 상거래 사이트에 아무것도 SSGs이 가능한 만들 수 있습니다.


Netlify 는 JAMstack의 워크 플로우에서 시장 리더로 부상했습니다. Netlify는 개발에서 CDN 배포에 이르는 전체 워크 플로를 관리하고 다양한 동적 기능으로 정적 사이트를 보강합니다. ID 관리, 양식 및 에지 기능과 같은 이러한 기능은 JAMstack의 가능성을 넓 힙니다. 테스트를 위해 고유 한 URL에 지점을 배포하는 것과 같이 개발자에게 친숙한 기능도 있으므로 준비 네트워크가 더 이상 필요하지 않습니다. Netlify는 2019 년이 분야에서 확실한 리더이지만 2020 년에 여러 솔루션이 등장하여 엔터프라이즈 JAMstack 배포를위한 경쟁력있는 시장을 구축 할 것으로 기대합니다. 이로 인해 현재 웹의 34 %를 차지하는 Wordpress 마켓 플레이스가 크게 침식 될 수 있습니다 !


팔로우 대상 : @PhilHawksworth & @shortdiv .


2-WASM (웹 어셈블리)

  WebAssembly는 모든 주요 브라우저에 제공되었습니다.


WASM은 작년에 먼 길을 갔으며 2020 년에는 더 폭넓게 채택 될 것으로 보입니다. WASM 은 JavaScript보다 20 배 빠른 브라우저를 컴파일하며 WASM 스크립트는 곧 JS 프로젝트에 모듈로 가져올 수 있습니다. 여기서 흥미로운 가능성은 React의 Virtual DOM과 같이 널리 사용되는 프레임 워크의 프로세서를 많이 사용하는 모듈을 Rust와 같은 고성능 언어로 다시 작성하고 WASM으로 컴파일 할 수 있다는 것입니다. 이 예에서 단일 React 릴리스는 모든 React 기반 웹 사이트의 웹 성능을 향상시킬 수 있습니다. 그 때까지 WASM은 JavaScript보다 훨씬 더 성능이 우수한 언어로 계산 집약적 인 작업을 구현하는 방법을 제공합니다 ( 해당 작업의 경우 ).


팔로우 대상 : @PatrickHamann & @_JayPhelps .


3-Edge Compute


CDN 수준에서 코드를 실행하면 클라이언트와 서버에서 CDN 플랫폼으로 처리를 오프로드 할 수 있습니다. WASM (또는 적어도 유사한)의 기존 구현은 Fastly의 엣지 컴퓨팅 플랫폼 에서 사용할 수 있습니다. 모든 주요 CDN은 이제 어떤 형태의 엣지 컴퓨팅 서비스 ( AWS Maida , CloudFlare Workers , Akamai EdgeWorkers 참조 )를 시작했습니다. 흥미롭게도 모두 완전히 다르게 구축되었습니다! 에지에서의 컴퓨팅을 통해 클라이언트와 서버에서 로직을 오프로드하여 레거시 서버 로직을 사용자에게 더 가깝게, 집중적 인 로직을보다 제어 된 컴퓨팅 리소스로 이동할 수 있습니다. 이것의 훌륭한 응용 프로그램은 개인화 및 이미지 조작입니다. 둘 다 클라이언트에서 구현하기가 어렵지만 서버 환경에서는 잘 작동합니다.


4-Observability


"측정 할 수 없으면 관리 할 수 없습니다"라는 말이 있습니다. 2019 년에는 관찰 성이 크게 개선되었습니다. 현재 페이지로드 시간과 같은 객관적인 측정 방식에서 벗어 났지만 올해에는 브라우저가 컨텐츠를 처리하고 렌더링하는 방법에 대한 가시성이 높아졌습니다. 누적 레이아웃 이동 , 총 차단 시간 및 최대 콘텐츠 페인트 와 같은 메트릭 은 사용자 경험 측정에 더 가까이 다가가는 것을 목표로합니다. 이를 통해 속도 측정 프로세스가 간소화되고 개발자의 응용 프로그램 계측에 대한 의존도가 줄어 듭니다. HTTP Archive 및 Chome CRUX (실제 사용자 경험 보고서)는 모두 성능 통계의 비교 데이터베이스를 제공합니다.Lighthouse CI 는이 모든 데이터를 가져오고 프로세스를 구축하기 위해 우수한 성능 테스트를 추가 할 수있는 통합 지점을 제공합니다.


Google  웹 사이트 검색 결과에 "느린"배지를 제안 했습니다. 명시된 목표는 "더 빠른 웹으로 이동"하는 고귀한 것이지만, '성능 경찰'접근 방식이 의미있는 변화에 영향을 미치지 않는다는 것을 몇 번이고 알았습니다. 해결 방법 기술이 무엇인지 아는 사람 : 1999와 같은 화면로드, 백그라운드에서 페이지가로드되는 동안 렌더링 된 스크린 샷, UA는 Googlebot에 더 빠른 경험을 제공하기 위해 스니핑합니다.

Chrome에서 제안한 '느린'배지


이 진술에 대한 결론으로, 구글 이 모바일 검색 결과에서 페이지 속도를 순위 요소로 포함 했을 때 가장 느린 트래픽의 1/3에 대한 성능 메트릭이 최대 20 %까지 향상 되었습니다 . 따라서 기술적 SEO가 웹 성능보다 예산을 더 많이 확보하기 때문에 이러한 불이익을당하는 것이 효과가있는 것 같습니다.


트래픽의 1/3이 가장 느리면 2018 년에 사용자 중심 성능 지표가 15 %에서 20 % 향상되었습니다. 비교하면 2017 년에는 개선이 없었습니다.



 Google Analytics에서 성능 관찰 가능성에 큰 구멍이 있다고 생각합니다. GA는 지구상 에서 가장 널리 사용되는 타사 태그로, 웹을 방문하는 대부분의 사이트에서 데이터를 수집합니다. GA는 'Site Speed'보고서를 제공하지만 좋은 결과를 제공하지만 즉시 사용 가능한 가장 기본적인 레거시 성능 측정 만 지원합니다. 실적은 비즈니스 성과와 상관 관계가없는 페이지 뷰의 1 %에서 임의로 샘플링됩니다. 설상가상으로, 이용 가능한 유일한 집계 통계는 산술 평균이며, 이는 웹 성능 측정에 거의 쓸모없는 것으로 알려져 있습니다 .

Google 웹 로그 분석 기본 타이머는 매우 제한적입니다



관측 성을 개선하기 위해 갈 길이 멀다. 업계 에서는 Google 웹 로그 분석에 표시되는 기본 성능 데이터를 개선하여 3 천만 개 이상의 웹 사이트에 대한 관찰 성을 즉시 개선 할 수 있었습니다 .


실제 사용자 측정 솔루션을 사용하여 사이트 속도를 측정하는 것이 중요 합니다. 그렇지 않으면 사용자가 응용 프로그램의 성능을 인식하는 방식 (또는 잘못된 방향을 가리키는 메트릭)에 대한 가시성이 전혀 없습니다. 가장 간단한 설정은 SpeedCurve Lux 로 이동하십시오 . 유연성과 엔터프라이즈 솔루션을 최대한 활용하려면 Akamai mPulse를 방문하십시오 . 이미 APM (Application Performance Measurement) 솔루션이있는 경우 Dynatrace UEM 및 New Relic Browser 와 같은 실제 사용자 성능을 측정하기위한 플러그인이있을 수 있습니다 . 어떤 솔루션을 선택하든 사용자와 제품에 중요한 것을 측정하고 비즈니스 성공과 속도를 연관시킬 수 있는지 확인하십시오.


메트릭이 향상되고 RUM이 널리 보급되고 성능 통계가 경영 보고서의 일부가되어 웹이 더 빨라지기를 바랄뿐입니다. 느린 사이트는 비용이 많이 들고, 관찰 가능성은 성능 향상을 위해 자금을 할당하는 데 도움이됩니다.


팔로우 대상 : @anniesullie & @eanakashima .


5-Browser Platform Improvements


Chrome과 같은 브라우저에서 많은 개선이 이루어지고 있습니다. 2013 년부터 데이터 세이버 모드 를 제공 하여 저가형 장치의 옵트 인 속도가 매우 높습니다. 대부분의 경우이 모드는 웹 서버에 힌트를 제공하여 더 가벼운 페이지 (가장자리에서 처리하여 빠르고 가벼운 경험을 제공 할 수 있음)를 제공합니다. Chrome은 2019 년에 리소스의 로딩 우선 순위에 대한 힌트 인 속성을 출시 했습니다 

loading

.


이 두 가지를 결합하면 Chrome은 기본적으로 느린 오프로드 이미지를 로드합니다.

연결 상태가 좋지 않거나 데이터 세이버가 활성화 된 사용자 웹 플랫폼에 대한 이러한 간단한 변경은 웹 개발자의 개입없이 웹 성능에 큰 영향을 미칩니다.


이것이 방해가 될 수 있지만 브라우저는 개인 정보 보호를 위해 오랫동안 특정 정책을 시행해 왔습니다.


이러한 결정에 신호로 성능을 추가한다는 것은 모든 사용자에게보다 평등 한 웹을 의미해야합니다.  로딩 속성 지원은 Chromium 기반 브라우저로 제한됩니다.


Chrome 팀이 주도하는 이러한 변경 사항이 표준화되어 다른 브라우저로 변경되기를 바랍니다. 이 간단한 변경은 최악의 네트워크 연결 및 제한되거나 계량 된 데이터 연결을 가진 사용자의 사용자 경험에 큰 영향을 줄 수 있습니다.


따라야 할 사람 : @KatieHempenius & @AddyOsmani .


6-Web Monetisation


웹 의 속도 저하 의 대부분은 방문자에게 수익을 창출하려는 시도에서 비롯됩니다. 광고 및 추적에서 개인화 및 라이브 채팅에 이르기까지 이러한 기술은 모두 수익을 창출하기 위해 사용자 경험을 방해합니다. 웹의 비즈니스 모델은 번화가 나 신문 판매원 에서처럼 명확하지 않지만, 우리는 여전히 자유롭고 개방 된 웹에 대한 사용자의 기대와 수익을 창출하기위한 비즈니스 요구 사항을 조정하는 데 어려움을 겪고 있습니다.


Payment Request API , Web Monetization API 및 Brave Rewards 와 같은 내장 API를 사용하여 웹을 통한 수익 창출을 개선하면 제 3 자 컨텐츠를 방해하지 않고도 컨텐츠를 쉽게 수익화할 수 있습니다. 이러한 변화는 2020 년의 웹 사용자, 특히 뉴스 및 잡지 웹 사이트의 경험이 크게 향상되는 것을 볼 수 있습니다.


사람들 은 빠른 웹 사이트에 더 많은 시간을 투자 하므로 웹 개발의 어려운 승자가 될 수 있습니다.


팔로우 대상 : @Coil & @Interledger .


7-Honourable Mentions 


구글의 AMP , 페이스 북 인스턴트 기사 , 서비스 워커 , 웹 워커 , 프로그레시브 웹 앱 , 웹 가상 현실 및 AI 는 이러한 예측에서 의도적으로 누락되었습니다 . 나는 이러한 기술들이 다양한 정치적, 기술적 이유로 중간 인의 웹 경험에 바늘을 옮기는 데 중요하다고 생각하지 않는다. 목록에서 가장 가까운 것은 Progressive Web Apps입니다. 웹과 기본 앱 사이의 간격을 좁히는 열쇠 일 수 있습니다. 삼성은 최근 미국 App Store에 PWA를 포함시키는 것에 대한 지원 을 발표 했지만 URL을 이메일로 보내고 추가 라이센스에 서명해야합니다. Google은 이상한 해결 방법이 있습니다웹 사이트를 Play 스토어에서 앱으로 제공 할 수 있지만이 과정은 간단하지 않습니다. Safari는 의심 할 여지없이 Safari가 일부 중요한 기능을 지원 하지만 아이디어를 거의 접대하지 않고 App Store 매출 ( 기기 판매 수익보다 큰 )을 꾸준히 보호하고 있습니다 . 불행히도 우리는 2020 년에 이와 관련하여 시장이 바뀌지 않을 것이라고 생각합니다.


그러나 EU의 웹 UX가 크게 개선 될 수있는 변경 사항이 있습니다. 유럽 연합 규제 당국은 기존 GDPR 규정으로 인해 종종 무시되는 (또는 무시할 수없는) GDPR 통지와 함께 웹 경험이 생겼음을 인정한 것 같습니다. 이것들은 웹에서 역겨워지고 사용자를 보호하는 데 거의 도움이되지 않습니다. 평균 동의 양식은 필수 쿠키가 아닌 쿠키를 선택 해제하는 데 42 초가 걸립니다. 이 동의 관리가 브라우저로 이동하면 사용자가 동의를 관리하기위한 단일 기본 UI 만 웹 환경뿐만 아니라 기본 보안 상태를 개선 할 수 있습니다. 이것은 ePrivacy 에 고려되는 옵션 중 하나입니다-EU의 더 나은 규정에 대한 제안. 그러나 정부의 속도에 따라, 우리는 2020 년에 공식적으로 변화가 채택되고 규제되는 것 외에는 변화가 공식화 될 것으로 확신하지 않습니다.


인터넷 사용자에 대한 동의 요청의 과부하를 초래 한 쿠키 제공이 간소화됩니다. 브라우저 설정을 통해 쿠키 및 기타 식별자 추적을 쉽게 허용하거나 거부 할 수 있으므로 새로운 규칙이보다 사용자 친화적입니다. 또한이 제안은 인터넷 경험을 향상시키는 비 개인 정보 보호 쿠키 (장바구니 기록 기억 등) 나 웹 사이트에서 방문자 수를 계산하는 데 사용하는 쿠키에 대해서는 동의가 필요하지 않음을 명시합니다.


브라우저에서 명시 적 옵트 아웃 또는 환경 설정을 관리하면 많은 사이트의 성능이 크게 향상 될 수 있습니다. Hello 매거진은 11MB 이상의 컨텐츠가 모바일 첫 번째보기에로드되는 예이며, 그 중 상당수가 타사입니다. 이에 대한 옵트 인은 "이 사이트를 탐색하면 이에 동의합니다"라는 명시 적이며, 사이트와 상호 작용 한 후에는 기본 설정을 관리하는 링크에 액세스 할 수 없습니다.

Hello 매거진에는 명시 적 옵트 인 기능이 있으며 페이지를 스크롤하면 옵트 아웃 할 수 없습니다.


웹 성능의 미래를보고 있다면, 가장 중요한 것은 지금 경험을 빠르게하는 것입니다. 미래에는은 총알이 나오지 않으므로 사용자 경험을 측정하고 최적화하는 것이 그 어느 때보 다 중요합니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari