프론트엔드 퍼포먼스 챌린지: 승자와 결과

몇 주 전에 우리는 독자와 커뮤니티에 웹사이트와 프로젝트가 매우 빠르게 수행되도록 할 수 있는 모든 것을 사용할 것을 요청했습니다. 오늘, 우리는 이 도전의 결과를 보여주고 정말 엄청난 상품을 받게 될 우승자를 발표하게 되어 기쁩니다!

어떤 상을 물으십니까? 우승자는 런던행 왕복 항공편, 멋진 호텔의 전체 숙박, SmashingConf London 2018 입장권, 그리고 마지막으로 중요한 것은 그들이 선택한 Smashing 워크샵을 제공합니다.

도전? 어떤 도전?

글쎄, 작업은 들리는 것처럼 간단하지 않았습니다. 참가자들은 전후의 최종 시각적 모양을 동일하게 유지하면서 웹사이트의 성능을 향상시키도록 요청받았습니다. 글꼴 로딩은 다를 수 있었고 최소한으로 유지되는 한 리플로우는 허용되었습니다.

행운의 당첨자를 선택하는 동안 우리는 Lighthouse와 WebPageTest가 제시한 결과와 참가자들이 작업한 웹사이트의 복잡성을 살펴보았습니다. 첫 번째 의미 있는 페인트 와 상호 작용 시간 이 가장 중요한 지표였습니다.

그러나 지금으로서는 충분히 어려운 사실입니다. 우리는 당신이 이미 호기심을 갖고 있다는 것을 알고 있으며 더 이상 당신을 불안하게 만들고 싶지 않습니다. 자, 여기 수상한 프로젝트가 있습니다.

그리고 승자는…

레오나르도 로소비즈

Leonardo가 제출한 최적화 기술은 모두 DIY이며 처음부터 설계 및 구현되었습니다. 그는 웹 사이트를 구축하기 위한 오픈 소스 프레임워크인 PoP에 모든 최적화를 추가하고 Agenda Urbana를 사용하여 실제 프로젝트의 성능 향상을 테스트했습니다.

우리는 이 제출이 단일 웹사이트의 성능을 개선할 뿐만 아니라 여러 웹사이트에서 사용되는 프레임워크를 개선하려는 시도를 통해 도전 정신에 실제로 들어왔다고 느꼈습니다. PoP가 WordPress에 의해 지원된다는 사실은 Leonardo가 JavaScript 프레임워크에서 사용할 수 있는 일부 작업을 수행할 수 없는 많은 사람들과 비슷한 상황에 있다는 것을 의미했습니다. 그가 지적했듯이:

PoP는 WordPress를 기반으로 합니다. 즉, Webpack을 사용한 코드 분할 또는 sw-precache를 통한 서비스 워커와 같이 Javascript 프레임워크에 사용할 수 있는 많은 혁신적인 최적화 기술이 도달할 수 없음을 의미합니다(적어도 큰 해결 방법 없이는 가능). 따라서 아래에 설명된 모든 최적화 기술은 처음부터 설계 및 구현된 모두 DIY입니다.

그의 제출물에 대한 모든 핵심적인 세부 사항을 파헤치는 데 관심이 있다면 언제든지 그렇게 하십시오. 우리 모두는 Leonardo의 최적화에 대한 세부 사항을 읽는 것을 즐겼고 이 항목에 들어간 엄청난 양의 작업으로 인해 그가 가치 있는 승자라고 느꼈습니다.

모든 제출물

우리는 우리가 받은 제출물의 품질에 매우 만족했고 솔직히 우승자를 선택하는 것은 쉽지 않았습니다. 제출해 주신 모든 분들께 감사드립니다. 계속해서 멋진 작업을 하세요!

요르겐 베르바이

Jorgen Verweij는 회사 웹사이트 Perplex Internetmarketing BV의 최적화된 버전을 발표했습니다. UX'er, 프론트엔드 및 백엔드 개발자로 구성된 팀과 시스템 관리자와 함께 그는 성능 작업에 착수했습니다.

결과는 전반적으로 우수한 성능 결과를 제공하는 탁월한 구현입니다. SpeedIndex는 설정된 목표 1250보다 훨씬 낮고, 로드 시간은 1초 미만이며, 0.5초 만에 렌더링 시작, ¹⁰⁰ ⁄ ₁₀₀ PageSpeedscore 및 거의 완벽한 Lighthouse 감사 . 이전 상황과 비교하여 로드 시간이 거의 8배 더 빠릅니다. 명성! Jorgen이 작성한 이 종합적인 글에서 프로세스에 대한 자세한 내용을 읽을 수 있습니다.

마르코 헹스텐버그

Marco Hengstenberg는 관광청 웹사이트 Land in Sicht 의 최적화된 버전을 제출했습니다. 성능을 향상시키기 위해 Marco는 아주 작은 트릭과 기술을 많이 사용했습니다. 기본 스타일시트를 미리 로드하는 것과 지원하는 브라우저에서 미리 로드하여 중요한 글꼴을 로드하는 것은 그 중 두 가지에 불과합니다. 그는 또한 HTML을 가능한 한 단순하고 의미론적이며 액세스 가능하도록 재구성했으며 처음 방문 시 데스크톱에서 거의 3MB에서 1.3MB로 전송되는 데이터의 양을 줄였습니다(영웅 이미지에 반응형 이미지를 사용했기 때문에 좁은 화면보다 훨씬 적음).

사이트를 더욱 간소화하기 위해 Marco는 Bootstrap, jQuery 및 Modernizr을 제거하고 Grunt로 빌드 프로세스를 설정했으며 사이트를 오프라인에서도 사용할 수 있도록 하는 ServiceWorker를 도입했습니다. 노력은 그만한 가치가 있었습니다. 그 결과 TTL이 32초에서 2초로 줄어들었고 HTTP 요청 및 전송된 바이트 수가 거의 50% 감소했습니다(Lighthouse 보고서, ZIP 251KB 참조). 사전 로드 및 빠른 초기 렌더링 모두 인식된 로드 시간에 도움이 됩니다. 훌륭한 일!

가브리엘 마리아니

San Diego Christian College 웹사이트는 Gabriel Mariani가 그의 공연 기술을 적용한 웹사이트였습니다. 그는 최적화 프로세스를 4단계로 나누었습니다. 먼저 그는 모든 이미지를 실제로 필요한 최대 크기로 자르고 모바일 크기의 버전을 만들었습니다. 그런 다음 그는 모든 이미지를 지연 로드했습니다. 두 번째 단계는 JavaScript에 초점을 맞추고 WordPress 사이트와 타사 테마 및 플러그인과 함께 제공되는 모든 인라인 스크립트를 제거했습니다. 그런 다음 그는 가능한 한 많은 스크립트를 대기열에 넣어 Autoptimize가 스크립트를 선택하고 단일 파일로 축소/결합할 수 있도록 했습니다.

Gabriel은 또한 사용되는 글꼴 수를 줄이고 중요한 경로 CSS가 먼저 로드되도록 Google 글꼴이 async 으로 로드되도록 설정했습니다. 마지막으로 그는 WordPress 플러그인 사용자 지정과 같은 다른 작은 문제를 해결하여 PHP 대신 ajax에 의존합니다. 이를 통해 그는 페이지 캐싱을 활성화하고 결국 사이트에 대한 CDN을 활성화할 수 있었습니다. HTTP/2 및 HTTPS로의 전환이 마지막 단계였습니다. 전체 결과는 WebPageTest를 참조하십시오. 멋진!

알렉산더 자르게스

Alexander Zarges는 YouTube 및 SoundCloud 앱을 검색하고 재생할 수 있는 Angular 4를 기반으로 하는 단일 페이지 웹 애플리케이션인 Cloud Player를 개발했습니다. 업그레이드된 버전은 Angular Ahead-of-Time 컴파일러를 사용하여 약 2.9초의 초기화 시간을 달성합니다(Just-in-Time 컴파일러 사용 시 5.2초). 코드에 대해 더 자세히 알아보려면 함께 제공되는 GitHub 리포지토리를 확인하세요.

브래들리 도발

Bradley Taunt는 자신의 개인 사이트를 실험할 기회로 우리의 도전을 받아들였습니다. 최적화 작업의 기초로 그는 자신의 홈페이지와 이미지가 많은 기사를 사용했습니다. 기사의 로딩 시간을 4.2초로 줄이기 위해 Bradley는 무엇보다도 웹 글꼴을 사용하는 대신 기본적으로 사용자의 OS 시스템 글꼴을 사용합니다.

추가 향상을 위해 최적화된 버전은 중요한 CSS를 인라인하고 반응형 이미지를 제공하며 CDN 캐싱을 활용합니다. Bradley가 도전 과제를 해결한 방법에 대해 쓴 블로그 게시물에서 더 자세한 비하인드 스토리를 볼 수 있습니다.

존 빌레스

John Beales는 4RoadService.com의 성능 향상에 도전했습니다. 그가 시작했을 때 이미 몇 가지 최적화가 이루어졌습니다. 정적 이미지는 ImageOptim을 통해 실행되었습니다. 예를 들어 CSS와 JS는 축소되었고 CloudFlare를 통해 CDN을 실행했으며 사이트는 이미 단일 페이지 앱 스타일 로더를 사용하므로 XHR에서 항상 새 콘텐츠를 가져오고 페이지는 완전히 다시 그린 적이 없습니다.

이 챌린지를 위해 John은 Cloudflare에서 이미지 최적화 및 WebP 압축을 켭니다. 업데이트된 사이트는 이제 HTTP/2 서버 푸시를 사용하여 초기 페이지 로드와 함께 기본 CSS 및 JS 파일을 보내고 JPEG 압축을 위해 Guetzli에 의존합니다. 캐싱을 최적화하기 위해 그는 자산이 변경될 때마다 URL이 변경되도록 모든 정적 자산의 URL을 업데이트한 다음 모든 정적 자산을 1년 동안 캐시하도록 설정했습니다. 이미지 캐싱을 개선하기 위해 John은 동적으로 크기가 조정된 이미지의 URL도 업데이트하여 CloudFlare가 이미지를 정적 이미지 파일로 인식하도록 했습니다.

결과: 첫 번째 의미 있는 페인트는 2,220ms에서 1,290ms로, First Interactive는 5,480ms에서 3,040ms로 떨어졌습니다. 여기에서 전체 라이트박스 및 웹페이지 테스트 결과를 볼 수 있습니다.

숀 오코넬

Shaun O'Connel의 출품작은 그가 kiwi.ruby.nz에서 한 작업이었습니다. 목표는 컨퍼런스 참석자가 오프라인에서 이벤트와 관련된 모든 정보를 검색할 수 있도록 컨퍼런스 웹사이트를 PWA로 전환하는 것이었습니다. 그가 한 일 중 일부: 일반적인 Google Maps iframe을 Google Static Maps로 교체, 자체 호스팅 하위 집합 글꼴, 첫 번째 요청을 14KB 미만으로 유지하기 위해 CSS 인라인으로 이동, 종속성 제거, 사전 캐시 서비스 작업자 추가, snappy용 Turbolink 추가 페이지 전환. 이를 통해 초기 렌더링 시간이 3.9초에서 0.3초로 단축되었습니다.

자세한 내용은 WebPageTests를 확인하십시오.

루슬란 줄바리소프

Ruslan Julbarissow는 개인 웹사이트 zerofy.de를 제출했습니다. 콘테스트가 게시되기 직전에 최적화 작업을 완료했기 때문에 불행히도 이전 결과에 대한 자세한 내용은 없지만 Ruslan은 자신의 조정으로 인해 페이지 크기가 1.6KB이고 TTFB가 197ms가 된 방법을 잘 기록했습니다. 캐싱, 축소, GZIP 및 jQuery 조정 외에도 그는 렌더링 차단을 피하기 위해 나중에 글꼴을 로드하고 FontAwesome을 10개의 아이콘으로 구성된 맞춤형 IcoMoon 세트로 교체하여 추가로 130KB를 절약했습니다.

속도 지수 점수를 높이고 가능한 가장 빠른 경험을 얻기 위해 그는 스크롤 없이 볼 수 있는 보기에 영향을 미치는 모든 CSS 스타일이 포함된 별도의 PHP 파일도 만들었습니다. 좋은 세부 사항: 작은 스크립트 Barba.js를 사용하면 전체 사이트를 다시 로드하지 않고도 페이지 전환을 만들 수 있습니다.

참여해주신 모든 분들께 감사드립니다

휴! 이제 그것은 참으로 상당한 도전이었습니다! 이런 좋은 도전과 간간이 뇌를 간지럽히는 당신을 위해 다음 도전을 지켜봐주십시오. 우리는 곧 다른 것을 생각해 낼 것입니다. 그것은 확실합니다!