모바일 성능을 최적화하는 방법

최고의 디자인은 처음부터 모바일을 염두에 두고 작업하여 미학과 성능의 균형을 유지합니다. 엄격한 성능 예산 설정에서 클라이언트 및 서버 측 최적화 기술 구현에 이르기까지 Cyber-Duck 에서 사용하는 현재 모바일 성능 최적화 프로세스를 공유하겠습니다.

모바일 마인드가 되십시오

성능은 사용자 경험의 핵심 부분이므로 개발 프로세스가 끝날 때 고려할 사항이 아닙니다. 디자이너와 개발자가 처음부터 협업 하는 모바일 중심 구조를 통해 프로젝트를 관리하는 것이 좋습니다.

공동 검토

각 프로젝트에 대해 내부 팀과 함께 설계 및 개발 범위를 검토하고 핵심 성과 지표(KPI) 목표를 정의합니다. 비즈니스 목표를 기반으로 프로젝트 성공을 나타내는 이정표 메트릭입니다. 중요성을 감안할 때 성과 관련 목표가 여기에 나타나야 합니다.

전체 내부 팀이 결과물을 검토할 때까지 이해 관계자와 중요한 프로젝트 이정표(예: 아트 디렉션 및 와이어프레임)를 승인하지 마십시오. 그렇지 않으면 개발자가 구현 중에 페이지 크기를 줄이기 위해 디자인 조정을 요청할 수 있습니다. 디자인이 이미 승인된 상태에서 이 단계에서 변경하면 복잡성이 발생하여 클라이언트 승인이 추가로 열릴 수 있습니다. 개발자가 처음부터 참여하면 인터페이스에 필요한 크기와 프로그래밍 능력을 예측하고 이를 방지할 수 있습니다.

실적 예산

모바일 사고방식을 취하는 가장 좋은 방법 은 엄격한 성능 예산을 설정하고 준수하는 것입니다. 즉, 최종 웹사이트의 속도와 크기에 대한 목표를 설정하는 것입니다. 팀이 명확한 고성능 목표를 위해 작업할 때 캐러셀과 같은 값비싼 기능을 구현할지 여부를 선택해야 합니다.

구체적인 비즈니스 목표와 사용자 요구 사항에 따라 수치 기반 성과 예산을 설정할지 여부가 결정됩니다. 예를 들어, 웹사이트 개편은 여러 기기에서 로드 시간을 획기적으로 개선하고 모바일 전환을 유도하는 것을 목표로 했습니다. 우리는 40개의 HTTP 요청 또는 500KB의 모바일 데이터에 대한 엄격한 제한을 설정했습니다. 과거 상호 작용이 대상 고객의 행동을 나타내므로 Google Analytics 데이터는 개선 중에 선택할 목표를 알려줄 수 있습니다.

일반적으로 모바일 홈페이지의 경우 500KB 제한으로 페이지 크기에 대한 목표를 정의합니다. 서버 요청은 예측하기가 더 어렵기 때문에 정확한 수치를 설정할 가능성이 적습니다. 이 대략적인 지침은 클라이언트 프로젝트에 대한 우리의 요구에 적합합니다. 그러나 Daniel Mall에는 HTML 및 CSS에 대한 가중치 할당부터 JavaScript, 이미지 및 웹 글꼴에 이르기까지 예산에 세부 사항을 추가하기 위한 훌륭한 실용적인 가이드가 있습니다.

최적화 기법

모바일에서 웹사이트 로딩 속도는 클라이언트 측과 서버 측 요인에 의해 좌우됩니다. 이 두 가지 요소를 모두 해결하는 대상 최적화 기술을 사용하면 프로젝트에 설정된 성능 예산을 충족하는 데 도움이 될 수 있습니다.

클라이언트 측 최적화

다양한 모바일 환경(2014년에 5,000개 이상의 고유한 스마트폰 장치)으로 인해 개발자는 서버 측 요인보다 개별 장치 성능을 훨씬 덜 제어할 수 있습니다. 따라서 클라이언트 측 최적화가 중요합니다. 다음 기술은 모바일 장치에서 웹사이트를 로드하는 데 필요한 처리 시간과 전력을 줄이는 것을 목표로 합니다.

코드 최적화

많은 개발자들이 웹사이트를 강화하기 위해 jQuery로 작성하는 함정에 빠집니다. 그러나 그런 것은 없습니다. 사실, 유용한 단축키 및 기능 라이브러리를 사용하면서 JavaScript로 작성하고 있습니다. 이렇게 하면 개발 속도가 빨라지지만 제품을 빠르게 시장에 출시해야 할 때 유용하지만 성능 비용이 발생할 수 있습니다. jQuery 라이브러리는 무게를 추가하고 플러그인(및 기능)의 유연성은 종종 부풀려질 수 있음을 의미합니다.

다음은 동일한 기능에 JavaScript와 jQuery를 사용한 예입니다. 일반 JavaScript로 작성하면 다른 외부 라이브러리를 애플리케이션으로 가져오는 것을 방지하고 또 다른 귀중한 HTTP 요청을 저장할 수 있습니다.

 // jQuery var con = $('#my_container'); con.css('width','75%'); // Plain JavaScript var con = document.getElementById('my_container'); el.style.width = '75%';

Grunt 또는 Gulp와 같은 시스템을 사용하거나 Prepos, Codekit 또는 Hammer와 같은 프런트 엔드 컴파일러 앱을 사용하여 CSS 및 JS 파일을 추가로 최적화할 수 있습니다. 이는 파일 연결, Sass, Less 또는 CoffeeScript 컴파일, Uglify JS(JavaScript 압축), 프로덕션용 파일 축소/압축 등 다양한 작업을 수행하여 HTTP 요청 및 파일 크기를 줄입니다.

스크롤 없이 볼 수 있는 부분에 우선 순위 지정

Google Pagespeed Insights(및 유사 도구)는 스크롤 없이 볼 수 있는 부분보다 로딩 크기와 콘텐츠 속도를 우선시할 것을 권장합니다. 페이지의 보이는 부분(접은 부분 위)을 먼저 렌더링하는 데 사용되는 CSS를 분리합니다. 페이지가 렌더링된 후 로드할 나머지 스타일을 연기합니다.

페이지 헤더에 직접 최상위 CSS를 추가하면 됩니다. 그러나 이것은 CSS 파일의 나머지 부분처럼 캐시되지 않으므로 주요 내용으로 제한되어야 함을 명심하십시오. Scott Jehl의 Critical CSS 및 Paul Kinlam의 Bookmarklet 도구를 포함하여 다양한 도구를 사용하여 분리할 CSS를 결정할 수 있습니다.

이미지 최적화

리치 디자인에 대한 현재 선호도를 고려할 때 이미지가 페이지 크기의 원인이 되는 경우가 많다는 것은 유감스러운 일입니다. 그러나 올바른 형식으로 내보내기 전후에 각각을 최적화하고 압축하면 이미지 주도 디자인이 여전히 가능합니다. 항상 적절한 이미지 유형을 사용하고 있는지 확인하십시오. 진한 색상의 사진은 JPEG 파일로 더 잘 작동하는 반면 평면 색상 그래픽은 PNG8에 있어야 합니다. 그라디언트 및 더 복잡한 아이콘은 알파 투명도가 있는 PNG24/32 또는 SVG로 가장 잘 작동합니다.

Photoshop과 Fireworks를 사용하면 이미지의 다양한 영역에서 최적화 수준을 사용자 정의할 수 있습니다. 즉, 주요 피사체는 고품질로 유지되고 나머지는 성능 향상을 위해 최적화됩니다. ImageOptim 및 TinyPNG와 같은 무손실 이미지 압축 도구는 이미지 품질을 잃지 않고 파일 크기를 최대한 활용할 수 있습니다.

새로운 HTML5 <picture> 요소와 이미지에 대한 srcset 및 size 속성을 사용할 수도 있습니다. 언어에 대한 이 두 가지 추가 기능은 HTML에서 직접 반응형 이미지를 정의하는 데 도움이 되므로 브라우저는 주어진 조건과 일치하는 이미지만 다운로드합니다.

 <picture> <source media="(min-width: 960px)"> <source media="(min-width: 465px)"> <img src="images/picture.png" alt="Picture alt"> </picture>

그러나 이 기술은 주의해서 사용해야 합니다. 소수의 브라우저만 지원합니다. 일부 최신 브라우저(예: Safari), Android 브라우저 및 IE10/11(및 이전 버전)은 지원하지 않습니다. Polyfill 대안을 사용하면 이 방법을 이전 브라우저에서 작동할 수 있지만 이들은 별도로 로드해야 하는 외부 JavaScript 라이브러리이며 다른 기술을 사용할 수 있다는 점을 감안할 때 가치가 없을 수 있습니다. 폴리필의 추가 가중치가 필요한지 확인하기 위해 대상 고객과 그들이 사용할 기술을 고려하는 것이 좋습니다.

데이터 URL은 최종 옵션입니다. 외부 이미지 파일에 연결하는 대신 이미지 데이터를 base64(또는 ASCII) 인코딩 문자열로 변환하고 CSS 또는 HTML 파일에 직접 포함할 수 있습니다. 간단한 온라인 변환 도구를 사용할 수 있습니다. 데이터 URL은 HTTP 요청을 저장하고 작은 파일을 더 빠르게 전송할 수 있으므로 유용합니다. 그러나 아래에 설명된 것처럼 포함된 코드 크기는 외부 이미지에 연결하는 것보다 큽니다. 추가된 길이로 인해 HTML 및 CSS 문서를 유지 관리하기가 더 어려워지고 이미지 변경 사항은 매번 다시 인코딩되고 포함되어야 합니다.

 <img width="32" height="32" alt="Camera" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAYZJREFUeNrsVsttwzAMtYUAvfrck0fIBukIyQAF5AkaTxB0gowQAR3AWcEbdASfeva1p5YEmIAgZEmWZKeHEhD8k2Ty8fFRZZFg3x/PL3DpYFSOac3T65eZ+qiKNLt4fo52Bker7A7AphoudcBU/PlxCQROM+a+TaGgFo7ei4JaIXonCmqF6J0oqJWiv6MgX5QU1R7LJTKyGBtgtKAP15J+3hWPsYOiyB9lZ7Ui7DarN5aXnzDeGeG2nk1GGKj1Pd3fGL+DoX1SjRz4kXlBcjByuvhhiEzjRMlWlGI9tcEmAT5nl0MjxxpwpKfGFYRASAoMbN7MFLCLDQkbAlsP7BhVKzaXOnKvczYN1+wlJ2KU0PCcM57wasL7jr7xdJgcUtzLWnbVuWdtlAOjYLlLR+qptbmOZMkW40Al8jp4mo51bYoDO/HcOua2nrVRDmh+sqFSO4hoB66ojC9BOhCSAmR3I5y4+jpfrhTcUNAzj3E6VIpniVJqM0p1YJF2/Od14N+BrPYrwAAH54zsDNHtwgAAAABJRU5ErkJggg==" />

CMS 미디어 최적화 자동화

이전 섹션의 자산 최적화 기술을 적용한다는 것은 BAM에 대한 고전적인 이미지 주도 디자인을 선택하여 새로운 건설 프로젝트 사진을 선보일 수 있다는 것을 의미했습니다.

그러나 우리는 또한 BAM이 각 이미지를 최적화할 필요 없이 콘텐츠를 업데이트할 수 있는 자유를 제공해야 했습니다. 물론 수동 최적화만큼 효과적인 솔루션은 없지만 합리적인 수준의 자동화 최적화를 달성했습니다. 유연성을 높이기 위해 기존 Sitefinity CMS를 재구성했습니다. 표준 옵션을 사용하여 각 웹 페이지의 컨텍스트에 맞게 이미지 크기를 자동으로 조정(및 최적화)했습니다.

 <thumbnailResizeSettings compositingQuality="HighQuality" interpolationMode="HighQualityBicubic" smoothingMode="HighQuality"> </thumbnailResizeSettings>

Sitefinity는 또한 URL 매개변수를 사용하여 URL에서 이미지의 크기를 조정할 수 있으며 다음 옵션을 사용하여 크기가 조정된 이미지를 캐싱하여 더 빠른 렌더링을 달성할 수 있습니다.

 /images/image-opt.jpg?size=480 

대부분의 CMS 시스템은 어느 정도의 미디어 최적화를 허용합니다. 예를 들어, 미래의 사용자가 웹사이트 템플릿에 맞는 이미지만 추가하도록 미디어 설정을 정의할 수 있습니다. 다음은 WordPress의 빠른 예입니다.

 // Wordpress example <div class="avatar"> <?php the_thumbnail( 'thumbnail' ); ?> </div>

글꼴 및 아이콘 간소화

글꼴은 웹 사이트 또는 애플리케이션의 사용자 경험 및 브랜딩의 중요한 부분이지만 사용자에게 최우선 순위는 아닐 수 있습니다. 이러한 이유로 웹 글꼴은 최적화의 또 다른 요소가 될 수 있습니다.

글꼴 로드를 연기하면 브라우저는 처음부터 사용할 수 있는 글꼴로 사본을 표시합니다. 즉, 사용자는 항상 콘텐츠를 먼저 받습니다. 글꼴 로드를 연기하려면 글꼴 파일에 연결되는 CSS 부분을 분리하고 페이지의 나머지 부분이 렌더링된 후에 로드하면 됩니다. 그러나 웹 글꼴이 로드될 때 변경하기 위해 텍스트가 잠시 깜박일 수 있습니다.

마찬가지로 아이콘은 자주 로드해야 하는 작은 파일이므로 최적화해야 하는 또 다른 영역입니다. 아이콘에 글꼴 파일을 사용하는 것도 고려할 수 있습니다. Fontello와 같은 서비스를 사용하여 다양한 아이콘을 선택하고 선택한 항목으로 제한된 글꼴 파일을 생성합니다. 이 기술은 성능에 약간의 영향을 미치면서 모든 화면 해상도에 대해 고품질 벡터 아이콘을 생성할 수 있습니다.

또는 이미지 스프라이트가 잘 알려진 옵션입니다. 이미지를 하나의 파일로 결합하고(하나의 로드 요청만 사용) 배경 위치를 사용하여 디자인에 필요한 부분만 표시합니다. Paul Stamatiou는 이것이 어떻게 수행되는지 설명하고 몇 가지 제한 사항을 설명합니다.

로딩 기술

다음 기술은 웹사이트의 전체 콘텐츠를 모바일 브라우저로 보내는 것을 방지합니다. 대신 각 중단점에 대해 최적화하여 필요한 정확한 데이터만 다운로드 합니다. 모바일 로딩 속도는 트레일러 기술을 제공하는 Velocity Drive 웹사이트의 핵심 고려 사항이었습니다. JavaScript 라이브러리는 브라우저 기능을 테스트하고 결함을 피하기 위해 모든 중단점에서 로드해야 합니다. 그러나 각 중단점에 대해 자산을 신중하게 최적화했습니다. 홈페이지 로드 크기는 모바일에서 323KB에 불과하고 대형 데스크톱에서는 828KB로 증가합니다.

인지된 페이지 속도를 높이기 위해 조건부 지연 로딩 기술 을 사용하여 이것을 더 발전시키십시오. 그들은 스크롤 없이 볼 수 있는 부분 위에 주요 콘텐츠가 있는 가시적인 섹션을 단계적으로 로드합니다. 사용자가 콘텐츠를 스크롤하도록 선택하지 않는 한 페이지 끝에서 찾은 값비싼 항목(예: 이미지)은 로드되지 않습니다. 이 기술은 IT 혁신을 다루는 Niu Solutions 웹사이트의 '통찰' 섹션의 핵심이었습니다. 사용자가 아래로 스크롤할 때 추가 기사를 로드하기 위해 jScroll이라는 작은 jQuery 플러그인을 사용했습니다. 다음은 더 많은 콘텐츠에 대한 링크가 필요한 이 플러그인을 설정하는 방법의 샘플입니다.

 <a href="articles.php" class="more">Load more</a>

 // Insights javascript $('.insights-container).jscroll({ nextSelector: '.more', loadingHtml: '<p>Loading...</p>' });

사전 로딩 기술은 더 많은 기회를 제공합니다. 그들은 더 빠른 경험을 제공하기 위해 사용자가 다음에 볼 가능성이 높은 페이지를 로드하여 사용자의 다음 움직임을 예상하고 준비할 수 있습니다. 그러나 Google Analytics에서 행동 흐름 퍼널을 연구할 수 있으므로 기존 웹사이트를 개조할 때 일반적인 트래픽 구조를 발견하는 것이 더 쉽습니다.

핵심 경험에서 향상

BBC의 반응형 뉴스(Responsive News)는 사용자가 요청한 핵심 경험을 제공한 다음 사용자 환경을 평가하고 그에 따라 경험을 향상시킨다는 아이디어를 나타냅니다. 이에 대한 간단한 예는 초기에 저해상도 이미지를 로드한 다음 사용자의 대역폭에 따라 고해상도를 표시하는 것입니다.

이 아이디어는 웹 기술이 여러 환경에서 최고의 경험을 제공하기 위해 계층화되는 점진적 향상의 일부입니다. 점진적인 향상은 다양한 요인을 기반으로 할 수 있습니다. 여기에는 브라우저, 운영 체제 및 환경(예: 인터넷 속도)과 같이 사용자가 액세스할 수 있는 기술이 포함됩니다. 여기에서 가장 성능이 낮은 브라우저에서 작동해야 하는 기본 기능 세트를 정의하고 브라우저가 처리할 수 있는지 여부를 테스트한 후에만 복잡성을 추가합니다.

브라우저가 HTML5 및 CSS 기능을 지원할 수 있는지 여부를 감지하면 지원되는 경우 기능을 향상 및 추가하는 동시에 지원하지 않는 장치 및 브라우저에 대해 안전하고 단순하게 유지하는 등 모든 상황을 처리하는 조건부 코드를 작성하는 데 도움이 됩니다.

기능 테스트 줄이기

Modernizr 또는 has.js와 같은 기능 테스트 라이브러리를 통합하는 것이 일반적이고 권장되는 방법입니다. 그러나 너무 많은 개발자가 전체 라이브러리를 구현합니다. 기능을 추가할지 여부를 결정하는 데 필요한 결과는 소수에 불과하지만 모든 기능에 대해 테스트합니다.

Tim Kadlec은 다양한 장치에서 동일한 라이브러리(최소화된 jQuery 2.1.1)의 구문 분석 및 실행 시간을 보고합니다. 이는 데스크톱과 비교하여 이러한 라이브러리를 구현하는 데 모바일 성능 비용이 더 많이 드는 경우가 종종 있음을 보여줍니다(이전 장치와 새 장치 간에도). 우리는 라이브러리를 맞춤화하는 경향이 있으며 관련 웹사이트 기능만 테스트합니다 . 이것은 시간과 귀중한 모바일 처리 능력을 절약할 것입니다.

서버 측 최적화

서버 응답 시간은 웹사이트 속도의 핵심 요소입니다. 많은 사람들이 200ms 미만을 목표로 합니다. 그러나 네트워크 대기 시간(데이터가 서버와 장치 사이에서 이동함에 따른 지연)은 모바일 성능의 실제 병목 현상이며 모바일 사용자는 더 느린 경험을 하게 됩니다.

이것은 네트워크 속도의 영향을 받습니다. Ofcom에 따르면 인기 있는 3G 및 4G 네트워크의 평균 다운로드 속도는 영국에서 6.1Mbps와 15.1Mbps였습니다. 일부에서는 이를 최대 웹사이트 크기에 대한 명확한 제한으로 해석합니다. 그러나 속도는 적용 범위와 환경적 맥락에 따라 달라지므로 현실은 더 복잡합니다. 사용자는 범위를 벗어날 때 느린 Edge(E) 및 GPRS에 연결하는 경우가 많습니다.

서버 측 웹 사이트 성능을 향상시키는 데 사용할 수 있는 다양한 기술이 있습니다.

캐싱, 사전 렌더링 및 정적 콘텐츠

동적 웹 페이지에는 여러 데이터베이스 쿼리가 필요하므로 출력을 처리하고 데이터 형식을 지정한 다음 브라우저에서 읽을 수 있는 HTML로 렌더링하는 데 귀중한 시간이 걸립니다. 해당 장치에 대해 이전에 렌더링된 콘텐츠를 캐시하는 것이 좋습니다. 재방문자의 경우 처음부터 처리하는 대신 캐시를 확인하고 업데이트만 보냅니다.

또한 많은 사람들이 웹 콘텐츠를 처리하기 위해 Handlebars 및 Mustache와 같은 JavaScript 템플릿 라이브러리를 선택합니다. 그러나 JavaScript를 구문 분석하고 실행하는 것은 전력과 시간이 많이 소요됩니다. 모바일 장치는 이러한 템플릿 라이브러리를 데스크톱 컴퓨터만큼 빠르게 처리할 수 없으며 처리 리소스를 소모합니다. 서버에서 페이지를 완전히 렌더링하는 것이 훨씬 빠릅니다. Twitter는 이미 2012년에 이 접근 방식을 선택했으며 블로그에서 그 가치를 설명했습니다.

최근에 우리의 선임 프론트 엔드 개발자는 개인 포트폴리오를 위해 이 기술의 한계를 뛰어 넘었습니다. html_cache 지원이 추가된 파일 기반 Statamic CMS로 구축되었습니다. 구현 시 이 기능은 모든 페이지의 평균 로드 시간을 약 1.8초에서 225밀리초로 줄였습니다.

브라우저 캐싱

세분화된 최적화는 자주 업데이트되지 않는 파일의 정기적인 전송을 방지하여 웹사이트 로딩을 간소화할 수 있습니다. .htaccess 파일과 같은 서버 핸들러를 사용하여 저장할 콘텐츠 유형과 복사본을 보관해야 하는 기간을 브라우저에 지시합니다 . Apache 서버에서 브라우저 캐싱을 구현하는 방법은 다음과 같습니다.

 <IfModule mod_expires.c> ExpiresActive on ExpiresDefault "access plus 1 month" # CSS ExpiresByType text/css "access plus 1 year" # Data interchange ExpiresByType application/json "access plus 0 seconds" ExpiresByType application/ld+json "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType text/xml "access plus 0 seconds" # Favicon and cursor images ExpiresByType image/x-icon "access plus 1 week" # HTML components (HTCs) ExpiresByType text/x-component "access plus 1 month" # HTML ExpiresByType text/html "access plus 0 seconds" # JavaScript ExpiresByType application/javascript "access plus 1 year" # Manifest files ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds" ExpiresByType text/cache-manifest "access plus 0 seconds" # Media ExpiresByType audio/ogg "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/ogg "access plus 1 month" ExpiresByType video/webm "access plus 1 month" # Web feeds ExpiresByType application/atom+xml "access plus 1 hour" ExpiresByType application/rss+xml "access plus 1 hour" # Web fonts ExpiresByType application/font-woff "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" ExpiresByType application/x-font-ttf "access plus 1 month" ExpiresByType font/opentype "access plus 1 month" ExpiresByType image/svg+xml "access plus 1 month" </IfModule>

콘텐츠 전송 네트워크(CDN)

일반적인 호스팅 서비스와 함께 CloudFlare와 같은 CDN을 사용하여 자산 로딩을 개선할 수 있습니다. 여기에서 이미지, 글꼴 및 CSS와 같은 정적 콘텐츠는 글로벌 서버 네트워크에 저장됩니다. 사용자가 이 콘텐츠를 요청할 때마다 CDN은 위치를 감지하고 가장 가까운 서버에서 자산을 전달하여 대기 시간을 줄입니다. 메인 서버가 정적 파일을 제공하는 대신 애플리케이션 제공에 집중할 수 있도록 하여 속도를 높입니다.

비용이 추가되지만 전용 CDN을 사용하여 자산이 많은 웹사이트의 로딩 속도를 개선하십시오 . 초기 설정을 제외하고 CloudFlare는 수동 구성이 필요하지 않습니다. 캐시는 과거 트래픽과 제공하기에 가장 적합한 자산을 기반으로 구축 및 업데이트됩니다. 그러나 미래의 독립적인 콘텐츠 관리를 염두에 두고 이를 구현하십시오. CMS에서 업로드된 모든 자산도 CDN을 통해 투명하게 제공되도록 해야 합니다.

CDN은 Eurofighter Typhoon 웹사이트를 위한 최선의 선택이었습니다. 국방 항공기의 뛰어난 고해상도 사진은 그들의 능력을 보여주는 중요한 기능이었기 때문입니다. 지난 30일 동안 보고서에 따르면 CloudFlare는 요청의 76%와 대역폭의 48%를 절약하여 이미지가 많은 웹 사이트의 속도를 높였습니다.

테스트

생산 전반에 걸쳐 테스트를 대체할 수 없습니다. 다양한 도구를 사용하여 모바일 경험을 시뮬레이션하고 잠재적인 성능 문제를 진단하여 진행 중인 작업을 테스트하는 것을 목표로 합니다.

제작이 진행됨에 따라 디자인 자산이 올바르게 생성되고 내보내졌는지 확인하는 것부터 브라우저의 개발자 도구를 통해 HTTP 요청의 양과 페이지 파일 크기를 확인하는 것까지 숫자를 항상 주시하십시오. 여기에서 네트워크 탭은 로드된 리소스, 총 파일 크기 및 렌더링 시간에 대한 전체 개요를 제공합니다.

위의 Chrome Inspector에서 타임라인 오른쪽에 있는 파란색 및 빨간색 수직선을 확인하세요. 이들은 각각 DOM 준비 및 페이지 로드 이벤트를 나타냅니다. 창 하단에는 현재 중단점에서 로드된 HTTP 요청의 양과 총 파일 크기가 표시됩니다.

기타 도구에는 다음이 포함됩니다.

• WebPagetest는 라이브 URL을 테스트하기 위한 다양한 옵션을 제공합니다. 전 세계의 모든 위치를 선택하는 것부터 특정 3G 및 4G 연결 속도와 대기 시간을 결정하는 것까지. 필름 스트립 보기 및 비디오를 통해 이러한 사용자를 위해 웹 사이트가 로드되는 방식을 경험할 수도 있습니다.
• Google의 Pagespeed Insights는 페이지 속도를 분석하기 위한 보다 시각적인 입문 도구입니다. 결과를 데스크톱 또는 모바일로 분할하고 사이트의 대상 영역을 개선하기 위한 기술을 제안합니다. 캐시할 리소스 또는 최적화할 이미지를 나타냅니다.

실제 장치에서 테스트

그러나 시뮬레이터에만 의존하지 마십시오. 또한 다양한 실제 모바일 장치에서 프로덕션 전반에 걸쳐 프로젝트를 테스트합니다.

자신의 장치 랩을 만들거나 OpenDeviceLabs를 사용하십시오. 이상적으로는 강력한 사무실 Wi-Fi를 피하여 실제 사용자 경험을 느끼십시오. 사무실 네트워크 외부에서 액세스할 수 있는 웹 서버(이상적으로는 라이브 서버와 동일)에 테스트 사이트를 만듭니다. 그런 다음 이동 중에 네트워크 연결을 통해 혼잡한 커피숍이나 호텔과 같은 일반적인 환경에서 테스트합니다.

모바일 성능 요약

무엇보다 모바일에서 미학과 성능이 균형을 이룰 수 있는 웹사이트를 만들고 실제 전환 지표를 달성하는 것을 목표로 합니다. 협업적이고 반복적인 성능 최적화 프로세스가 이를 달성하는 데 도움이 될 것입니다.

프로젝트 초기부터 엄격한 성능 예산을 설정 하여 내부 팀이 모바일 마인드로 함께 작업하도록 권장합니다. 모바일에서 웹사이트 성능을 결정하는 클라이언트 및 서버 측 요인에 대한 이해를 구축합니다. 그런 다음 내가 설명한 대상 최적화 기술을 혼합하여 구현하여 설정된 목표를 달성할 수 있습니다. 물론 경우에 따라 눈에 띄는 디자인, 고성능 및 보안 사이에는 여전히 절충점이 있습니다. 협업 설계 및 개발 팀은 관련 프로젝트 관리자 및 이해 관계자와 확인하여 비즈니스에 가장 적합한 것이 무엇인지 결정할 수 있습니다.

글로벌 기술 컨설팅을 위한 최적화 프로젝트는 이러한 기술을 결합하여 로딩 속도와 크기를 크게 향상시키는 방법을 보여줍니다. 이 프로젝트에는 템플릿 및 페이지 캐싱, 자산 및 글꼴 최적화, 기능 테스트 감소 등의 기술이 포함되었습니다. 지금까지 테스트 결과 렌더링 및 총 로드 시간이 작업을 시작하기 거의 4초 전에서 1.4초 미만으로 단축되었음을 보여줍니다. 마찬가지로 파일 크기도 3MB 이상에서 1MB로 줄었습니다.

SmashingMag에 대한 추가 정보:

• 2017년 프런트 엔드 성능 체크리스트
• HTTP/2 준비
• AMP에 대해 알아야 할 모든 것
• 모바일 브라우저의 (그렇지 않은) 비밀 능력