Magento 2 속도 최적화: 연구에 따르면 기본 기능으로 충분함

소개

Statista에 따르면 2019년에는 전 세계 휴대전화 사용자 수가 50억 명을 넘어설 것으로 예상됩니다. 그런 점에서 Google은 모바일 기기의 사이트 로딩 속도를 가장 중요하게 생각합니다. 이 매개변수는 의심할 여지 없이 검색 결과 순위에 영향을 미칩니다. 또한 사이트가 입원 환자를 잃지 않도록 하기 위해 빠른 웹사이트 로드 시간은 전환율을 높입니다.

이 기사의 첫 번째 부분에서는 표준 수단을 사용하여 Magento 2 페이지 로드 시간을 단축할 수 있는지 여부를 파악하고 보여주고 가장 중요한 것은 이러한 수단이 얼마나 효과적인지 정의합니다.

두 번째 파트에서는 ​​타사 솔루션 및 접근 방식의 효율성에 대한 통찰력을 제공합니다.

테스트 환경

모든 측정은 Chrome Audit 에서 'For mobile device with simulation Fast 3G' 제한으로 이루어집니다.

리뷰에서는 Docker 컨테이너에 펼쳐진 Magento 2.3.1을 사용합니다. 이렇게 하면 리소스를 격리할 수 있습니다.

완전히 활성화된 내장 캐시를 사용하여 프로덕션 모드에서 성능을 측정합니다.

테스트는 메인, 제품 및 카테고리 페이지의 세 가지 사이트 페이지에서 수행됩니다. 이 페이지마다 감사 확인을 세 번 실행합니다. 평균 테스트 결과가 선택됩니다.

우리는 부하 테스트를 실행하지 않을 것이기 때문에(브라우저에서 클라이언트 측의 페이지 로드 시간은 이 기사에서 주로 다루겠지만) MySQL과 PHP 버전은 지정하지 않을 것입니다. 절대적인 결과가 아니라 다양한 구성 간의 성능 차이가 우리에게 가장 중요한 관심사가 될 것입니다.

표준 Magento 및 서버 수단을 사용하여 페이지 로드 시간을 어떻게 단축할 수 있습니까?

무엇보다 전송 데이터의 크기나 요청 수를 줄여서 이를 달성할 수 있습니다. 더 자세한 통찰력을 읽으십시오.

1장. Magento 설정 및 서버 구성

Gzip

아래 표에서 볼 수 있듯이 가장 먼저 해야 할 가장 중요한 일은 - 맞습니다. Magento 설정과 관련이 없습니다 - 서버에서 압축을 활성화하는 것입니다. 데이터 볼륨은 느린 모바일 네트워크에서 로딩 속도를 결정하는 핵심 요소입니다. 압축이 활성화되면 사이트가 훨씬 빨리 표시 됩니다. 피할 수 없는 단점은 서버 측에서 압축을 푼 결과로 First CPU Idle 매개변수가 증가한다는 것입니다.

Gzip 없이:

Gzip이 활성화된 경우:

Js 및 CSS 축소

전송되는 데이터의 크기를 더 줄이려고 하면 어떻게 될까요? 먼저 Minify Js와 Minify CSS를 활성화합시다. 그런 다음 비교하십시오.

모든 최적화 관련 구성은 Stores -> Configuration -> Developer에서 찾을 수 있습니다.

이 탭은 개발자 모드 에서만 사용할 수 있습니다. 프로덕션 모드 에 있는 동안 다음 명령을 사용하여 먼저 개발자 모드로 전환해야 합니다.

 > bin/magento deploy:mode:set developer

그런 다음 개발자 섹션을 보고 필요한 구성을 변경하고 캐시를 지우고 다시 프로덕션 모드로 전환할 수 있습니다.

 > bin/magento deploy:mode:set production

그러면 정적 콘텐츠 배포가 수행됩니다.

접미사 min이 js/css 파일에 추가됩니다.

데이터 볼륨이 실제로 감소했습니다! 홈 페이지의 경우 1.3Mb 대신 1Mb가 전송되었습니다.

이것이 매개변수를 3분의 ​​1 향상시켰다고 생각한다면 오산입니다. 상황은 나아졌지만 크게 나아지지 않았습니다.

우리는 그것을 반복해서 실행했지만 결과는 안정적이었습니다. 즉, 특정 개선 사항이 있음에도 불구하고 전송되는 데이터 볼륨의 감소에 비례하지 않았습니다.

Js 병합 및 CSS 병합

이제 추가 개선 사항은 데이터 볼륨보다는 요청 수의 감소와 관련되어야 한다고 가정하는 것이 논리적입니다.

Merge Js 및 Merge CSS 구성을 사용하도록 설정해 보겠습니다.

Magento 자체에서 이 기능을 오래된 기능으로 설명합니다.

'JS 및 CSS 파일 병합과 같은 더 이상 사용되지 않는 설정은 페이지의 HEAD 섹션에서 동기적으로 로드된 JS용으로만 설계되었으므로 사용하지 않는 것이 좋습니다. 이 기술을 사용하면 번들링 및 requireJS 로직이 제대로 작동하지 않을 수 있습니다.'

그럼에도 불구하고 시도해 봅시다.

요청 수의 변화가 인상적이지 않습니까?

'첫 번째 콘텐츠가 있는 페인트' 및 '첫 번째 의미 있는 페인트'와 같은 매개변수가 개선되었지만 개선의 여지가 분명히 있습니다.

JS 번들

js 파일을 고정된 크기로 묶는 JS Bundle 기술을 사용해 봅시다. 이를 통해 전체 데이터 볼륨이 변경되지 않은 상태에서 요청 수를 관리할 수 있습니다.

결과는 실망스럽습니다. 문제는 내장된 Magento 메커니즘이 모든 사이트에 대한 js 번들을 수집한다는 것입니다. 즉, 거의 모든 js가 모든 페이지에서 수집됩니다. 이것은 페이지 볼륨의 급격한 증가로 이어질 것입니다.

예, 번들에서 특정 js 파일을 제외할 수 있습니다(일부는 기본적으로 제외됨). 그러나 특정 페이지에 대해서는 그렇게 할 수 없습니다.

Magento는 또한 프로덕션 모드에서 Bundle JS를 활성화하지 않는 것이 좋습니다. 사용 가능한 두 번째 옵션인 것 같지만 실제로는 그렇지 않습니다.

고급 JS 번들

Magento는 Bundles JS의 어려움을 인식하지만 스스로 해결하지 않도록 제안합니다. 공식 가이드에서 현재 페이지에 필요한 js 파일만 번들로 묶는 방법에 대한 예를 찾을 수 있습니다. 예, 이것은 구성에서 매개변수를 변경하는 것보다 조금 더 어렵습니다. 고급 번들의 경우 Nodejs, Require JS, Phantom JS를 사용해야 합니다. 물론 이것은 기성품이 아닙니다. 그러나 제공된 메커니즘을 테스트한 후 이론적 관점에서 Advanced Bundle이 페이지 로드 시간을 어떻게 단축할 수 있는지에 대한 아이디어를 얻게 될 것입니다.

제안된 메커니즘은 수동 모드에서 작동하며 프레임워크 내부가 아니라 외부 에서 작동합니다. 특수 도구는 페이지에 로드된 js 파일을 분석하고 페이지 TYPE 번들에 대해 일반 또는 특정 번들로 수집합니다.

궁극적으로 수집된 번들은 require js로 작성되고 페이지에 로드됩니다.

각 페이지 유형(당연히 번들이 수집됨)에서 특정 번들이 로드됩니다. 다음은 홈페이지의 예입니다.

요청 수를 줄인 후에는 추가 데이터가 로드되지 않고 성능이 크게 향상되어야 하는 것처럼 보일 수 있습니다. 그러나 SEO First Contentful Paint 및 First meaningful Paint에 대한 중요한 시간도 극적으로 증가했습니다. 그것은 의미가 있습니다. 번들 파일이 로드될 때까지 추적이 수행되지 않습니다.

________________

우리가 최선을 다한 것 같습니까? 지금이 최신 기술을 시도해 볼 때라고 생각합니다.

HTTP/2

Magento에서 Bundle JS를 비활성화하고 서버에서 HTTP/2를 활성화해 보겠습니다.
우리의 경우에는 nginx일 뿐입니다. 우리가 한 것은 몇 줄 변경되었습니다. 443 포트에 대한 http2 지원이 추가되었습니다.

 listen 80; listen 443 ssl http2; server_name md201.local; ssl_certificate /etc/nginx/ssl-certificates/md201.local/localhost.crt; ssl_certificate_key /etc/nginx/ssl-certificates/md201.local/localhost.key;

Chrome에서 테스트하려면 신뢰할 수 있는 루트 기관(이 경우 MacOS)에 자체 서명된 인증서를 추가해야 합니다.

HTTP/2 연결은 다음과 같습니다.

이것은 예외없이 모든 매개 변수를 개선했습니다! 그것은 모두 HTTP/2 기술의 기능에 달려 있습니다.

특히 다음을 통해 페이지 로드 시간을 단축하기 위해 액세스 지연을 줄입니다.

• HTTP 헤더의 데이터 압축,
• 서버 측에서 puch 기술 사용,
• 이송 요청,
• head-of-line HTTP 1.0/1.1 프로토콜 차단의 해결,
• 하나의 TCP 연결에서 수많은 요청을 다중화합니다.

HTTP/2를 사용하면 각 요청에 대해 TCP 연결이 열리지 않으므로 많은 수의 요청이 문제가 되지 않습니다.

HTTP/2는 대부분의 실제 브라우저에서 최신 버전의 nginx 및 Apache에서 지원됩니다. https://caniuse.com/#search=http2

이와 관련하여 다음과 같은 질문이 있을 수 있습니다. Advanced JS Bundle과 HTTP/2를 결합하면 어떻게 될까요?

이론적으로 HTTP/2는 대용량 번들 js 파일을 로드하는 데 큰 이점이 없기 때문에 페이지 로드 시간을 단축하지 않습니다. 하지만 확실히 알기 위해 확인해보자.

보시다시피 HTTP/2 연결 내에서 Advanced Bundle JS를 사용하면 속도가 향상되지 않습니다.

번들을 미세 조정하려는 시도는 시간이 많이 걸리는 프로세스입니다. 각 Magento 또는 타사 확장(프론트 엔드에 JS를 추가하는) 업데이트 후, 그리고 특정 js를 연결하거나 다른 제품의 js를 사용하지 않는 새로운 제품 유형을 추가한 후에 번들이 다시 생성되어야 합니다. 유형. 기본적으로 고려해야 할 뉘앙스가 더 있습니다. 제 생각에는 Bundle JS로 이동해도 HTTP/2를 사용할 가능성이 있다면 중요한 결과를 얻지 못할 것입니다.

속도 최적화의 다른 수단은 무엇입니까? 페이지 로드 시간을 더 빠르게 할 수 있습니까?

_______________

JS 코드를 페이지 하단으로 이동

솔직히 말하면, 우리는 이 최적화 수단을 타사 공급업체로부터 검토할 계획이었지만 이 기사가 작성되는 동안 Magento 2.3.2가 출시되었습니다. 이 기능은 새 버전에 추가되었으며 기본적으로 비활성화되어 있습니다.

활성화하면 일부 js 파일이 <head> 섹션에서 </body> 끝까지 전송되어 이론적으로 사이트 시각화 시작 속도가 빨라집니다.

그것이 우리가 처음에 가지고 있었던 것입니다:

활성화한 후 얻은 결과는 다음과 같습니다.

이러한 테스트를 실행하려면 Magento 버전을 2.3으로 업데이트해야 했습니다. 연결된 파일의 개수와 크기가 변경되었습니다. 따라서 테스트 결과가 거칠 수 있습니다. Magento 버전 자체가 결과에 어떤 영향을 미쳤는지 이해하기 위해 먼저 HTTP/2 + Minify JS/CSS 조합을 사용하여 M2.3.1과 M2.3.2 버전을 비교했습니다.  

보시다시피 First Contentful Paint 와 First meaningful Paint는 모든 경우에 10-15% 향상되었습니다.

Magento 속도 최적화의 모든 개요 수단 내에서 다음 변형이 선두에 있는 것 같습니다.

Gzip + JS/CSS 축소 + HTTP/2 + JS 코드를 페이지 하단으로 이동

그것을 출발점으로 생각하고 더 나아가자. 이전에는 JS/CSS만 다루는 구성을 가지고 놀았습니다. 따라서 개선할 수 있는 특정 측면이 있습니다.

HTML 축소

설정은 여기에서 찾을 수 있습니다.

홈 페이지의 HTML 부분 ― HTML 축소 전 89 Kb 및 후 88,7 / 서버 압축 포함 ― 12,2 대 12,1 Kb.

카테고리 페이지의 HTML 부분 ― HTML 축소 전 155Kb 및 후 100K / 서버 압축 포함 ― 16,8 대 15,2 Kb.

제품 페이지의 HTML 부분 ― HTML Minify 전 80 Kb 및 후 67 / 서버에서 압축 포함 ― 15 대 14,1 Kb.

서버 측 압축이 사용되므로 1-2Kb 차이는 중요하지 않으며 감사 결점 내에 있습니다.

2장. 추가 도구

타사 확장: JS/CSS/HTML 축소/병합 | 번들 JS

한편, JS/CSS/HTML 및 번들 JS에 대한 타사 솔루션을 찾는 데에는 큰 의미가 없습니다. 추가 압축 결과를 얻더라도 프런트 엔드에서 1%의 몫으로 제한됩니다. 그 대가로 시스템에서 하나 이상의 Magento 확장을 얻을 수 있습니다. 알고리즘의 존재 및 작동 사실은 추가 리소스를 필요로 할 뿐만 아니라 일반적으로 시스템 오류의 위험을 증가시킵니다. 잠재적인 이점이 관련 위험을 능가하는지 확실하지 않은 경우 사용을 중단하는 것이 좋습니다 .

압축 및 번들링을 통해 로딩 속도를 획기적으로 향상시키는 타사 솔루션을 알고 있다면 댓글로 공유하거나 [email protected] 으로 직접 알려주십시오. 기꺼이 조사해 드리겠습니다.  

이제 Magento에서 기본적으로 사용할 수 없는 수단을 사용하여 개선을 시도합시다.

이미지 크기 줄이기

웹에서 이미지를 사용하는 것은 항상 품질과 이미지 파일 크기 사이의 절충안입니다.

우리의 주요 관심사는 품질 손실 없이 이미지 크기를 줄이는 것입니다. 음, 기본 Magento 기능을 사용하면 실제로 이미지 크기를 줄일 수 있습니다. 그러나 이미지의 품질은 크게 저하될 것입니다.

Magento가 구성에 따라 변환하고 크기를 조정한 표준 이미지의 크기를 줄입니다. 즉, 주로 magento_root_directory/pub/media/catalog/product/cache에 있는 이미지에 관심이 있습니다.

Magento 구성은 여기에서 찾을 수 있습니다.

먼저 수동으로 수행하고 jpegoptim 유틸리티를 사용해 보겠습니다. Magento 속도 향상을 목표로 하는 여러 모듈(유료 모듈 포함)은 이 유틸리티로 구동됩니다.

이미지 품질을 낮추지 않는 한 캐시의 이미지에 대한 결과 없음:

그것에 대해 뭔가 잘못된 것 같습니다. 테스트를 위해 실제로 페이지에 표시되지 않는 원본 이미지에 적용했습니다. 우리는 중요하지 않지만 특정 결과를 달성했습니다.

자동화 솔루션으로 가는 것은 어떻습니까?

다음 무료 이미지 최적화 프로그램을 사용해 보겠습니다. https://github.com/justbetter/magento2-image-optimizer.

확장 프로그램에서 사용하는 제공되는 모든 유틸리티를 설치했습니다.

• JpegOptim
• 최적화
• 핑퀀트 2
• SVGO
• 기프시클

이미지 압축 설정은 JPEG에 대해 최대 80으로 설정되었습니다. 이것은 기본 Magento 설정에 해당합니다. 그런 다음 모든 미디어 디렉터리에 대해 최적화를 실행했습니다.

압축 전의 전체 미디어 디렉토리 크기는 353Mb, 후 ― 340,1Mb입니다.

media/catalog/product/cache 디렉토리 크기는 194,7Mb이며 압축 후에도 변경되지 않았습니다.

특히 이미지를 사이트에 업로드하기 전에 이미지를 준비하지 않은 경우 솔루션이 편리하고 유용하다는 것을 알게 되었습니다.

그러나 제품 및 카테고리 페이지의 전체 이미지 크기를 줄이는 것과 관련하여 크게 개선된 것은 없습니다.

아마도 다른 이미지 형식이 귀하의 경우 주로 사용됩니다. 따라서 결과는 훨씬 더 중요할 수 있습니다.

Apple 브라우저는 https://caniuse.com/#feat=webp 형식을 지원하지 않기 때문에 여기에서 의도적으로 webp 이미지 형식에 대해 설명하지 않습니다.

____________________

자, 이미지 파일 크기를 크게 줄일 수 없다면 보이는 영역에 대해서만 업로드해 보겠습니다.

이미지 로딩 지연

처음 접하는 무료 타사 솔루션인 Magento 2 Lazy Loading을 사용해 보겠습니다.

이전과 마찬가지로 제품, 카테고리 및 홈페이지에 대한 감사를 실시했습니다.

큰 변화는 없었습니다. 변동은 측정 불확도 내에 있습니다.

이는 샘플 데이터 페이지가 매우 가볍고 모든 기본 이미지가 보이는 영역에 바로 있기 때문일 수 있습니다.

제품 설명에는 이미지가 포함되어 있지 않습니다. 카테고리에 설명이 전혀 없습니다.
가장 쉬운 방법으로 호출기의 카테고리 페이지에 있는 제품 수(로딩 이미지 수 포함)를 먼저 9개에서 30개, 그 다음 최대 48개로 늘리고 결과를 나열해 보겠습니다.

결과는 분명합니다. 초기로드 웹 사이트 영역에서 보이지 않는 이미지가 (수량 및 크기 면에서) 더 크면 클수록 이점이 더 중요합니다. 이 기능은 특정 유용성 단점이 있지만 최적화 관점에서 확실히 유용한 기능입니다.

_________________

마지막 말 대신

표준 Magento 기능과 페이지 로드 성능을 최적화할 수 있는 일부 타사 솔루션을 모두 살펴보았습니다.

연구에도 불구하고 모든 웹사이트는 고유하고 고유한 특성을 가지고 있기 때문에 확고한 결론을 내리기는 어렵습니다. 따라서 한 사이트에서 작동하는 솔루션이 다른 사이트에는 영향을 미치지 않을 가능성이 어느 정도 있습니다.

하지만 의미 있는 효과를 주는 가장 유용한 기능은 기본 Magento의 Gzip + Minify JS/CSS + HTTP/2 + Image Lazy Loading 입니다.

번들 JS 정보

따라서 타사 확장 개발자가 제공하는 이 번들 의 고급 버전은 추가 개인화된 사이트 미세 조정 없이 로드 속도를 크게 증가시키는 것을 허용하지 않습니다.

로드 시간을 늘리는 데 도움이 될 수 있는 더 많은 방법이 분명히 있습니다. 그러나 그들 중 많은 수가 만능 솔루션이 아닙니다. 예를 들어, 전 세계 여러 국가의 사이트 방문자와 물리적 서버/서버 위치의 상관 관계도 중요합니다. 사이트를 서버로 전송하는 것이 합리적입니다. 서버에서 데이터 전송은 대부분의 사이트 사용자에게 더 빠르며 정적 파일에는 CDN을 사용합니다. 사이트 방문자가 주로 한 지역에서 온 경우 Varnish를 사용하여 정적 파일 캐시를 시도할 수 있습니다. https://devdocs.magento.com/guides/v2.3/config-guide/varnish/config-varnish-magento.html# 캐시 정적 파일.

궁극적으로 상황을 근본적으로 바꾸고 모바일 장치에서 사이트를 최대한 빠르게 만드는 수단은 AMP 기술을 사용하는 것입니다.

PS 앰프

(https://amp.dev/about/websites)

휴대용 장치의 경우 Google SERP에서 사용자는 사이트가 아니라 Google 서버에 저장된 캐시된 버전으로 이동합니다. 초기 로드는 번개처럼 빠를 것입니다. 이러한 웹 사이트는 SERP에서 번개 로 자연스럽게 표시됩니다.

이 기술은 단순한 기술이 아니며 자체 amp js 라이브러리만 사용한다고 가정합니다. 또한 현재 테마와 어떤 식으로든 연결되지 않은 별도의 페이지 버전을 가질 수 있습니다.

이것은 어려운 선택이 될 수 있습니다. 한편으로는 개선된 로드 속도와 변환에 관한 것입니다. 다른 하나는 AMP 기술이 부과하는 제한 사항입니다. 즉, AMP 라이브러리에서만 js 및 HTML을 사용할 수 있습니다. 결과적으로 기능이 제한됩니다.