핵심 웹 중요한 툴링

Google에서 시작한 핵심 웹 생명은 매우 실용적입니다. 처음에 성능에 중점을두면 다음에 중점을 두었습니다. 요청 감소! 캐시 컨텐츠! 파일 크기를 줄이십시오! 이것들은 웹 페이지 성능과 밀접한 관련이 있지만 추상적입니다. 사용자의 경우 실제 웹 페이지 성능이 반영됩니다. 페이지 컨텐츠를보기 위해 기다리는 데 얼마나 걸립니까? 실제로 페이지와 상호 작용할 수있는 데 얼마나 걸립니까 (예 : 양식에 컨텐츠를 입력하거나 링크를 클릭)? 작업을 수행하려고 할 때 페이지 컨텐츠가 성가신 일입니까? 이것은 핵심 웹 메트릭의 영리성입니다. 이러한 측면을 측정합니다.

Chrome Devtools의 등대 탭에는 이제 이러한 메트릭이 포함되어 있습니다.

웹 사이트를 방문하면 사용자가 웹 사이트를 방문할지 여부에도 영향을 줄 수 있기 때문에 이러한 메트릭을 주시하는 것이 중요합니다. Core Web Metrics는 이전에 AMP 페이지에만 예약 된 SEO 및 새로운 회전 목마 요구 사항에 통합되고 있습니다.

일회성 감사를위한 이러한 메트릭을 추적하는 것은 유용하지만 더 중요한 것은 성능 저하를 방지하기 위해 시간이 지남에 따라 관찰하는 것입니다. 구경과 같은 성능 도구는 이러한 메트릭을 다룹니다. 새로운 유물에는 이러한 메트릭도 포함됩니다. SpeedCurve는 이러한 메트릭을 추적합니다.

누적 레이아웃 오프셋 (CLS)은 어려운 문제입니다. 예를 들어, 웹 사이트에는 기사 맨 위에 광고가 있습니다. 이 광고에 대한 요청은 비동기식이므로 광고는 발생을 지연시키고 기사 내용을 아래로 밀어 낼 수 있습니다. 이 성가신 일뿐 만 아니라 성능 지표에 심각한 영향을 미치고 궁극적으로 SEO에 영향을 줄 수 있습니다.

Nic Jansma의 "실제 응용 프로그램의 누적 레이아웃 오프셋"은 심도있는 토론을 제공합니다.

CLS는 단순한 "페이지가 이렇게합니까?"이상입니다. 위 그림에서 볼 수 있듯이 점수가 있습니다. CLS 버전은 누구에게나 좋은 것이 아니기 때문에 0은 좋은 목표라고 생각합니다. 이에는 "통합"(예 : 헤드리스 브라우저, 특히 성능 도구에서) 및 실제 웹 사이트 (럼 또는 실제 사용자 지표)의 실제 사용자를 추적하는 등 많은 뉘앙스가 있습니다. 둘 다 유용합니다.

CLS 문제를 해결 해야하는 경우 까다로울 수 있습니다. SpeedCurve 몇 가지 새로운 도구가 도움이 될 수 있습니다.

각 레이아웃 오프셋에 대해 오프셋 전후에 두 개의 프레임이있는 필름을 표시합니다. 그런 다음 움직이는 요소 주위에 빨간색 상자를 그립니다. 오프셋을 일으킨 정확한 요소를 강조합니다. 각 오프셋의 레이아웃 오프셋 점수는 해당 오프셋의 영향과 누적 점수에 추가되는 방법을 이해하는 데 도움이됩니다.

이것이 문제를 근절하고 해결하기가 매우 쉬워지기를 바랍니다. 특히 어려운 질문. 나는 이것을 전에 알지 못했지만 CLS는 더 미묘한 문제로 인해 발생할 수 있습니다. Mark Zeman 은이 기사에서 지적합니다. 예를 들어:

• 수평으로 움직이는 그림 회전 목마 만 CLS를 트리거합니다. 이것은 정확히 그들이 해야 할 일이기 때문에 기분이 나쁘지만 CSS 변환 모바일 캐 러셀을 사용 하여이 문제를 해결할 수 있습니다.
• 지역이 매우 큰 경우 해당 지역을 이동할 위험이 더 큽니다. 조금만 움직이면 CLS에 심각한 영향을 미칩니다.
• 스타일 텍스트 (Fout)의 플래싱은 CLS의 이유입니다. 다른 이유로 성능에 유익하더라도! 모순! 이것은 완벽한 글꼴로 돌아가는 좋은 변명입니다.

힘들지만 중요한 질문. 성능 테스트를 CI/CD에 통합해야합니다.이 문제를 해결하는 데 먼 길을 갈 것입니다. 웹 성능이 웹 개발의 완벽한 경력 하위 범주라고 느끼고 있습니다. 프론트 엔드 웹 개발자는 이것을 이해하고 어느 정도 도움이 필요하지만, 우리는 이미 할 일이 많습니다.

위 내용은 핵심 웹 중요한 툴링의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!