WordPress용 핵심 성능 보고서 이해하기

Core Web Vitals는 특히 SEO 및 사이트 성능이 디지털 전략에 중요한 경우 사이트를 최적화하기 위한 일련의 필수 메트릭을 나타냅니다. 그럼에도 불구하고 사이트에서 Core Web Vitals를 개선하려고 할 때 어떤 WordPress 도구 및 전략이 가장 중요한지 파악하기 어려울 수 있습니다.

WordPress 사이트에서 Core Web Vitals 점수를 이해하고 개선하기 위한 모범 사례와 도구를 자세히 살펴보려면 이 세션을 시청하세요.

스피커:

• WP Engine의 제품 관리자 Alex Zuniga
• Mark Davoli, Amsive Digital의 웹 개발 이사
• Matt Chase, Vital Design의 개발 이사
• Sanjucta Ghose, WP Engine 수석 웹 개발자
• Mike Crantea, XWP 프론트엔드 엔지니어링 이사

성적 증명서:

ALEX ZUNIGA: 안녕하세요. Demystifying Core Web Vitals for WordPress에 오신 것을 환영합니다. 저는 여기 WP Engine의 제품 관리자인 Alex Zuniga입니다. 그리고 오늘, 우리는 WordPress 웹사이트의 핵심 웹 바이탈에 대해 자세히 논의할 것입니다. Core Web Vitals는 SEO 및 사이트 성능을 위해 사이트를 최적화하는 데 관심이 있는 경우 최적화해야 하는 필수 메트릭입니다. 그러나 어떤 WordPress 도구와 전략이 가장 영향력이 있는지 아는 것은 어려울 수 있습니다. 따라서 이 세션에 참여하여 모범 사례와 도구가 WordPress의 웹 필수 점수를 향상시키는 데 어떻게 도움이 되는지 자세히 살펴보십시오.

이제 더 이상 고민하지 않고 이 세션의 패널리스트를 소개하겠습니다. 그리고 먼저 Mike에게 넘겨주어 간단히 소개하겠습니다.

MIKE CRANTEA: 안녕하세요, 저는 Mike Crantea입니다. 저는 스페인 카나리아 제도에 있습니다. 저는 지난 17년 동안 근무한 XWP의 프런트엔드 엔지니어링 이사입니다. 주로 프론트엔드 기술 분야에서 저는 웹 성능을 좋아합니다. 그리고 여기 오게 되어 기쁩니다. 여기요.

ALEX ZUNIGA: 감사합니다, 마이크. 다음으로 Matt Chase가 있습니다.

MATT CHASE: 저는 뉴햄프셔 주 포츠머스에 있는 Vital Design의 개발 이사입니다. 내 작업에 무거운 프런트 엔드 초점. 그래서 우리는 Lighthouse 및 Core Web Vital 점수를 많이 사용합니다.

ALEX ZUNIGA: 굉장합니다. 고마워, 매트. 그리고 마크.

MARK DAVOLI: 안녕하세요, 저는 Amsive Digital의 웹 개발 이사인 Mark Davoli입니다. SEO는 우리 회사에 매우 중요하기 때문에 우리 팀의 Core Web Vital 공간을 전문으로 하고 있습니다. 따라서 Core Web Vitals도 마찬가지입니다. 이곳에 오게 되어 기쁩니다.

ALEX ZUNIGA: 만나서 반갑습니다. 마지막으로 Sanjucta입니다.

SANJUCTA GHOSE: 안녕하세요. 저도 WP 엔진에서 왔습니다. 저는 WP 엔진 웹사이트 유지 관리를 담당하는 팀의 일원입니다. 그리고 여기에는 WP 엔진이 맛있는 두뇌를 인수했을 때 함께 온 사이트가 포함됩니다. 그리고 저는 Core Web Vitals를 위해 Delicious Brain 사이트를 최적화하는 데 작년의 상당한 시간을 보냈습니다. 그래서 저는 이것이 매우 흥미로운 대화가 되어야 한다고 생각합니다. 이곳에 오게 되어 기쁩니다.

알렉스 주니가: 감사합니다. 감사합니다. 자, 패널 여러분 모두를 환영합니다. 그리고 우리는 당신이 말해야 할 것을 듣고 기다릴 수 없습니다. 따라서 Core Web Vitals와 관련하여 이러한 질문을 측정, 관리, 도구 및 고객 기대치를 기준으로 분석할 것입니다. 그래서 우리가 여러분 모두에게 묻고 싶은 첫 번째 질문은, 애초에 Core Web Vitals에 관심을 가져야 하는 이유는 무엇입니까? 그리고 Core Web Vital 최적화에 어느 정도 집중해야 합니까?

MARK DAVOLI: 원하시면 말씀드릴 수 있습니다. 저에게는 페이지 속도가 빠른지 확인하는 것이 정말 중요합니다. 중요한 이유는 최종 결과 전환에 있습니다. 오른쪽? 따라서 누군가 웹사이트를 방문하면 로드 시간이 길어질수록 이탈할 가능성이 높아집니다. 그리고 페이지 속도가 빠르지 않으면 운이 좋지 않고 잠재적으로 많은 비즈니스를 잃게 될 것입니다. 특히 전자 상거래 상점에서.

SANJUCTA GHOSE: 그렇습니다. 검색엔진 최적화에 매우 중요하기 때문에 말씀하신 내용에 어느 정도 동의합니다. 하지만 Core Web Vitals는 사이트의 인지된 성능을 측정하는 척도라는 점도 기억해야 합니다. 사용자가 귀하의 사이트를 인식하는 방법. 그리고 사용자가 귀하의 사이트가 반응적이고 상호 작용이 가능하며 안정적이라고 인식한다는 점에 주의를 기울이는 것이 매우 중요하다고 생각합니다. Core Web Vitals가 측정하는 항목입니다. 그래서 저는 SEO 점수보다 더 중요한 것은 사용자의 성과에 대한 인식이 중요하다고 생각합니다. 이것이 우리가 Core Web Vitals에 집중해야 하는 이유입니다.

ALEX ZUNIGA: 물론입니다. 매트, 당신은-

MATT CHASE: 네, 기본적으로 제가 말하려고 했던 것은 SEO 측면이 훌륭하다는 것입니다. 그러나 궁극적으로 우리는 사람들을 위해 이러한 사이트를 코딩합니다. 그리고 우리는 그러한 사람들이 가능한 가장 빠르고 가장 빠른 사이트를 가지기를 원합니다. 그러나 이것은 두 세계 모두에 영향을 미칩니다. 오른쪽? 따라서 이러한 Core Web Vitals를 조정하면 훌륭한 UX를 수행하게 됩니다. 그러나 SEO 팀을 만족시키는 방식으로, 때때로 이기는 것이 항상 쉬운 전투는 아닙니다. 그래서 그것은 모두에게 효과가 있습니다.

ALEX ZUNIGA: 말씀하신 대로 그것이 중요하다는 것을 압니다. 그러나 점수를 측정하는 가장 좋은 방법은 무엇입니까?

MARK DAVOLI: 우리가 사용하는 것 외에 측정하는 방법 중 하나는 Google의 Page Speed ​​Insight Tool이 있는데, 이는 그들이 측정하는 데 사용하는 도구이기 때문에 매우 중요합니다. 맞습니다. 영향을 미치고 싶다면 해당 도구를 사용하는 것이 중요합니다. 브라우저 내 Lighthouse도 Chrome DevTools에 있으며 이는 매우 중요합니다. 그리고 Search Console에는 지난 28일 동안의 실제 사용자 메트릭을 모니터링하기 위한 훌륭한 페이지 사용자 경험 도구가 있으며 이는 장기간 모니터링에 중요합니다.

SANJUCTA GHOSE: 네. Page Speed ​​Insights는 Core Web Vitals 자체가 지난 28일 동안의 실제 사용자 데이터를 기반으로 한다는 점에서 실시간 데이터를 제공하기 때문에 Page Speed ​​Insights는 매우 좋은 도구라고 말하고 싶습니다. 그러나 실험실 데이터를 기반으로 하는 Lighthouse 보고서도 볼 수 있습니다. Core Web Vitals의 개선 사항은 일정 기간 동안 측정되기 때문에 실제로 개선 사항을 확인할 수 있기까지 어느 정도 시간이 걸리기 때문에 실제로 즉시 개선할 수 있는 것입니다.

따라서 점수를 향상시키려는 경우 Lighthouse는 훌륭한 도구라고 생각합니다. 따라서 이러한 기회를 즉시 구현하려고 시도하고 점수가 어떻게 향상되는지 확인할 수 있습니다.

ALEX ZUNIGA: 굉장합니다. Lighthouse에 대한 큰 외침처럼 들립니다. 훌륭한. 훌륭한.

MIKE CRANTEA: 실제 사용자 메트릭 성능 데이터를 추적하는 것이 프로덕션에 도달한 성능 저하에 더 빠르게 대응할 수 있다는 점을 이 주제에 추가하고 싶습니다. 실험실 테스트는 준비 단계에 있을 때 도움이 됩니다. 우리가 전파하고 싶지 않은 저하가 있다고 말하는 것과 같습니다. 그러나 프로덕션에서는 항상 놀라운 일이 발생할 수 있습니다. 그리고 검색 콘솔과 크럭스 데이터베이스의 실제 사용자 측정항목이 표시될 때까지 몇 주를 기다리는 대신 성능 보고서 라이브러리를 사용하여 직접 추적하여 앞서 나갈 수 있습니다.

ALEX ZUNIGA: 굉장합니다. 응. 때때로 발생하는 생산상의 놀라움보다 항상 앞서 나가야 합니다. 괜찮은. 음, 측정에 대한 답변을 주셔서 감사합니다. 이제 관리를 살펴보면 Core Web Vitals에 가장 큰 영향을 미칠 수 있는 한두 가지 작업은 무엇입니까?

MATT CHASE: 그래서 한 가지 눈에 띄는 것은 당신이 할 수 있는 모든 것과 같은 게으른 로드입니다. 그리고 가능한 모든 것의 로딩을 연기하세요. 그것은 저에게 일종의 턴키 솔루션이라고 할 수 있으며 즉각적인 개선을 볼 수 있습니다. WP Rocket에는 그런 종류의 기능을 활성화하기 위해 설정할 수 있는 매우 쉬운 확인란이 많이 있습니다.

마크 다볼리: 네. 그리고 저에게 핵심 초점은 우리가 폴드 렌더 위라고 부르는 것입니다. 따라서 가능한 한 빨리 렌더링되는지 확인하십시오. 그리고 앞서 언급했듯이 가능한 최고의 점수를 얻을 수 있도록 화면 밖에 있는 모든 항목을 지연 및 지연 로드합니다. 즉, WP Rocket은 지연 스크립트 기능이 뛰어납니다. 그러나 우리는 그것을 GTM이나 Google 광고 스크립트 또는 이와 유사한 것들로 제한하려는 경향이 있습니다. 그리고 가능한 한 최적화되도록 웹 사이트를 강화하는 테마의 실제 핵심 아키텍처를 개선하는 데 정말 집중하세요. 따라서 이러한 종류의 성능 영향을 미치기 위해 타사 플러그인에 의존하지 않습니다.

맷 체이스: 오, 물론이죠. 응. 양쪽 끝.

ALEX ZUNIGA: 잡았다. 잡았다. 그리고 명확히하기 위해 WP Rocket을 말했습니다. 그리고 그것이 지연 스크립트 기능입니까?

마크 다볼리: 네.

ALEX ZUNIGA: 굉장합니다.

MIKE CRANTEA: 충분한 주목을 받지 못하는 한 가지는 캐싱입니다. 그러나 빠른 서버 응답 시간이 빠른 경험을 보장하지는 않습니다. 그러나 서버가 느리게 응답하면 느린 경험을 보장하는 것입니다. 따라서 사용 가능한 모든 캐싱 계층(브라우저 캐싱, 개체 캐싱, 페이지 캐싱)을 사용하고 이를 켜고 작동시키는 것이 좋은 첫 단계입니다. 기본을 지키세요. 그런 다음 프런트엔드 최적화까지 작업할 수 있습니다. 당신의 머리에 무엇이 있는지 확인합니다. 등등.

알렉스 주니가: 훌륭합니다

SANJUCTA GHOSE: 네. 그리고 이미지를 최적화하는 것도 잊지 말아야 한다고 생각합니다. 요즘 많은 웹사이트가 이미지가 무거운 경향이 있기 때문에 이것이 매우 중요하다고 생각합니다. 따라서 이미지를 압축하고 CDN을 통해 제공한 다음 이미 언급한 것처럼 이미지를 지연 로드하는 것이 중요하다고 생각합니다. 더 중요한 것은 반응형 이미지를 제공하는 것입니다. 따라서 사진 태그 또는 이미지 태그의 소스 집합 속성을 사용하여 반응형 이미지를 제공할 수 있습니다. Core Web Vitals는 모바일 우선 측정이기 때문에 이것이 실제로 많은 개선으로 이어지는 것을 보았습니다. 따라서 반응형 이미지를 제공하는 것이 매우 중요합니다. 우리가 때때로 잊어버리는 것입니다.

그래서 나는 이미지를 생각한다. 또한 빌드 단계 중에 CSS에서 JavaScript를 최소화하는 것과 같은 매우 간단한 작업도 있습니다. 그것도 도움이 많이 되는 것 같아요. 아주 간단합니다.

맷 체이스: 네. 그 주제에 관해서는 실제로 당신이 그것을 제기한 이후로 WordPress는 일종의 패키지 웹팩 빌드 시스템을 배포합니다. 그들은 WordPress Scripts에서 호출합니다. 그리고 우리 에이전시는 자체 웹팩 시스템을 유지하기 위해 오랜 시간 동안 고군분투했습니다. 그런 다음 8개월마다 일부 노드 종속성이 변경되어 전체 도구 체인이 중단됩니다. 그러나 WordPress는 우리를 위해 이것을 유지합니다. 그리고 그것은 엄청난 이득이 되었습니다.

그리고 거기에 있는 webpack은 동적 가져오기를 사용하여 기본 JavaScript 번들을 빌드하기 시작했습니다. 따라서 우리는 모든 것을 하나의 기본 JavaScript 패키지로 묶는 대신 런타임에 노드 종속성을 가져오는 것입니다. 이렇게 하면 동일한 종류의 지연된 스크립트 로딩에 대해 정말 미세하게 조정할 수 있습니다. 특정 경우에만. 우리 블록이 페이지에 있을 때처럼.

마크 다볼리: 네. 또한 웹사이트에서 사용하는 플러그인에 대해 매우 선택적인지 확인하는 것이 매우 중요하다는 것을 알았습니다. 타사 플러그인을 설치하면 예상치 못한 많은 블로트웨어를 얻을 수 있습니다. 따라서 평판이 좋고 잘 구축된 플러그인으로 제한하십시오. 그리고 해당 플러그인이 로드하는 항목에 주의를 기울이십시오. 실제로 사이트의 성능을 제어하는 ​​데 도움이 될 수 있습니다. 불행히도 WordPress는 여전히 백엔드 사용 등을 위해 jQuery에 크게 의존합니다. 그러나 프런트엔드에는 실제로 필요하지 않습니다. 따라서 가능하다면 웹사이트의 프런트엔드에서 jQuery 지원을 중단하고 기본 JavaScript를 고수하는 것이 성능에 실제로 도움이 될 수 있습니다.

ALEX ZUNIGA: 굉장합니다. 우리는 이미 이 분야에 뛰어들고 있다고 생각합니다. 그리고 당신은 몇 가지를 언급했습니다. 하지만 도구를 사용하여 조금 더 살펴보겠습니다. Core Web Vital 최적화에 선호하는 도구는 무엇입니까? 어떤 종류의 사용 사례에 가장 적합합니까? 아니면 적합하지 않은 시나리오가 있습니까?

MATT CHASE: 내 말은, 전에도 나왔었거든요. 하지만 실제로 Lighthouse 인브라우저 도구는 즉각적인 결과를 제공하기 때문에 제가 정말 사용하는 도구입니다. 오른쪽. Core Web Vitals는 훌륭하지만 그 힘은 시간이 지남에 따라 결합되는 집계라는 사실에 있습니다. 따라서 실제로 무언가를 변경하고 숫자가 변경되는 것을 볼 수 없습니다. Lighthouse와 비교할 때 브라우저에서 업데이트를 수행합니다. 로컬 개발 환경을 보고 Lighthouse 테스트를 실행합니다. 그리고 즉시 알 수 있습니다. 오, 내 성능이 15점 상승했습니다. 시원한. 그것은 옳은 일이었습니다. 프로덕션으로 푸시합니다.

ALEX ZUNIGA: 굉장합니다. 사용하고 싶은 다른 도구가 있습니까?

MIKE CRANTEA: Chrome의 로컬 재정의 기능에 큰 박수를 보내고 싶습니다. 즉, 성능 탭과 함께 웹 사이트의 항목 로드 순서를 변경하여 놀 수 있는 외과적 기능을 제공합니다. 그리고 그것이 얼마나 많은 영향을 미치는지. 특정 변화를 위해 노력하는 것이 그만한 가치가 있는지, 아니면 그냥 그대로 두고 정말 영향을 미치는 다른 일에 집중하는 것이 좋은지 알 수 있도록 필요한 감독을 제공합니다.

MARK DAVOLI: 또한 중요하다고 생각하는 한 가지는 서버 아키텍처 모니터링입니다. 오른쪽. 따라서 세계에서 가장 뛰어난 Core Web Vitals를 보유할 수 있지만 서버에 비정상적으로 많은 부하가 걸리고 인식하지 못하는 경우 갑자기 콘텐츠가 포함된 첫 번째 페인트가 급격히 떨어지는 것을 발견할 수 있으며 이는 거의 모든 다른 것에 영향을 미칩니다. 따라서 New Relic과 같은 도구 또는 성능 모니터링을 위한 도구를 면밀히 주시하십시오. 웹 사이트를 가능한 한 빨리 렌더링하기 위한 적절한 인프라가 있는지 확인하기 위해 면밀히 주시하는 것이 중요합니다.

MIKE CRANTEA: 캐싱을 켜고 준비하는 것이 도움이 되는 부분입니다.

MARK DAVOLI: 그리고 CDN.

마이크 크랜테아: 네. 잠재적인 재해를 피하십시오.

알렉스 주니가: 훌륭합니다. 글쎄요, 그 명확성에 감사드립니다. 질문 중 하나입니다. Core Web Vitals를 최적화하기 위한 많은 최적화 플러그인이 있습니다. 이를 지원하는 WordPress 플러그인의 제한 사항은 무엇입니까? 아니면 진정으로 사이트를 최적화하고 있습니까? 아니면 Google의 측정을 속일 가능성이 있습니까? 그리고 아마도 그것은 아마도 플러그인에 의존하는 대신 플러그인을 사용하거나 작업을 수행하는 것이 더 나은지에 대한 질문일 것입니다.

SANJUCTA GHOSE: 그래서 저는 플러그인이 훌륭하다고 생각합니다. 예를 들어 WP Rocket은 훌륭합니다. 우리는 EWWW Image Optimizer를 많이 사용합니다. 그리고 그것도 대단하다고 생각합니다. 하지만 이미 말한 것처럼 생각합니다. WP Rocket은 defer JavaScript 기능을 켜면 이상한 버그가 발생하는 경우를 보았기 때문에 신중하게 사용해야 합니다. 일회성 버그. 그래서 저는 때때로 플러그인을 사용하기보다는 제 자신의 솔루션을 사용하는 것을 선호합니다. 개발 전문 지식이 있는 경우.

그래서 우리가 딜리셔스 브레인 사이트에 대해 수행한 대부분의 최적화는 플러그인을 사용하지 않고 자체적으로 수행했습니다. 하지만 저는 플러그인이 훌륭한 출발점이라고 생각합니다. 따라서 막 시작할 때 예를 들어 스테이징 사이트에 WP Rocket 배포를 구현하고 문제가 발생하는지 확인하고 싶을 수 있습니다. 또는 실질적인 개선을 가져오는 경우. 그래서 플러그인은 신중하게 사용해야 한다고 생각합니다. 그리고 백그라운드에서 플러그인이 수행하는 작업을 알아야 합니다. 그리고 그것이 귀하의 사이트에 어떤 영향을 미칠 수 있는지.

맷 체이스: 네. 고맙게도 WP Rocket은 최신 버전에서 적어도 그들이 가지고 있는 위험한 스위치에 매우 명확하게 레이블을 지정하는 데 능숙했다고 생각합니다. 나는 지연된 스크립트와 CSS 최적화와 같이 예상하지 못한 것조차도 클래스 이름이 그들을 보이게 할 것이라고 말한 것을 얻지 못한 모델을 깨뜨린 경우에도 많은 시간을 태워 왔기 때문입니다. . 그래서 신나는 하루였습니다.

하지만 그래. WP Rocket은 확실히 좋은 코드 인, 좋은 코드 아웃 이외의 다른 곳으로 가는 것입니다. 오른쪽. 작업을 수행하는 것이 항상 작업에 접근하는 가장 좋은 방법입니다. 플러그인은 물건을 자동화할 수 있습니다. 그러나 실제로 코드를 간결하고 비열하게 만드는 것을 대신할 수 있는 것은 없습니다.

MIKE CRANTEA: 실험실 유형의 플러그인으로 표시된 플러그인이 하나 더 있습니다. 퍼포먼스 랩입니다. 이는 WordPress Performance Core 팀에서 수행합니다. 무서운 것처럼 들리지만 지금까지의 모든 테스트에서 완전한 안정성을 제공했습니다. 그리고 그것은 그것이 기대했던 것과 그 Performance Lab 플러그인에서 끝난 작업의 품질에 대해 매우 인상적이었습니다. 따라서 시도해 볼 가치가 있습니다. 몇 개의 확인란. 그리고 거기에 있는 모든 것은 안전합니다. 음, 데이터베이스 스위치에 대해 잘 모르겠습니다. 내가 그것에 대해 읽을 때 그것은 더 논란이되는 것입니다. 응. 그 버튼을 만지지 마십시오. 플러그인 내부에 SQLite 지원 또는 이와 유사한 것을 추가한 것처럼 일부 소규모 웹사이트에서 확실히 작동합니다.

ALEX ZUNIGA: 흥미롭군요.

마크 다볼리: 네. 그리고 저에게는 WP Rocket이 환상적입니다. 우리가 수행하는 대부분의 작업은 기본적으로 구축되기 때문에 대부분의 사이트에서 사용을 제한합니다. 그러나 Core WordPress에는 적절하게 사용하면 실제로 잘 최적화된 사이트를 얻을 수 있는 많은 다른 기능이 있습니다. Elementor 등과 같은 타사 대신 블록 편집기를 사용하는 것처럼 사이트에 많은 부풀림을 추가할 수 있습니다. 예를 들어 모든 단일 페이지에 모든 것을 한 번에 로드하는 대신 필요에 따라 실제로 파일을 로드하는 새로운 네이티브 구텐베르크 유형 블록 시스템처럼 빌드하는 경우입니다. 이제 WordPress에 지연 로딩 기능이 내장되어 있습니다. 따라서 사용 방법을 모니터링하고 적절하게 사용하는 등의 작업을 수행합니다. 그런 다음 WP Rocket과 같은 도구를 추가하여 이미 있는 것을 향상시킵니다. 그러나 그것에만 의존하는 것은 아닙니다.

특히 제대로 작동하지 않는 사이트가 있는 경우 해당 위치로 이동하는 데 도움이 될 수 있습니다. 그러나 언급했듯이 중요한 CSS 생성과 마찬가지로 이러한 것들은 봇이 페이지에서 보는 것을 기반으로 많은 가정을 하기 때문에 많은 문제가 있을 수 있습니다. 그러나 초기 보기를 렌더링하지 않을 항목을 예측할 수는 없습니다. 따라서 언급한 대로 모델이 있는 경우 해당 모델이 팝업되면 그것이 가능성이라는 것을 알지 못할 것입니다. CSS를 생성하지 않고 제대로 인라인합니다. 핵심 글꼴을 미리 로드하거나 스크롤 없이 볼 수 있는 부분에 렌더링하는 것과 같은 작업을 수행하는 것과 같습니다. 다시 말하지만 그것이 핵심입니다. 정말 가장 중요한 것입니다.

SANJUCTA GHOSE: 중요한 CSS에 대해 언급하고 싶었습니다. 바로 Addy Osmani가 Critical이라는 멋진 도구를 가지고 있다는 것입니다. 이를 빌드 프로세스에 추가하여 중요한 CSS를 생성할 수 있습니다. 그것은 굉장. 그리고 그것은 매우 신뢰할 수 있습니다. 중요한 CSS를 언급하셨으니 추가해야겠다고 생각했습니다. 끊어서 죄송합니다.

MIKE CRANTEA: 좋습니다. 중요한 CSS의 동일한 주제에 대해 Jetpack 팀에서 Jetpack Boost 플러그인으로 작업을 수행하기 위해 약간의 노력을 기울였습니다. 그것은 iframe 또는 이와 유사한 것으로 페이지를 렌더링하여 중요한 CSS를 생성하는 매우 흥미로운 방법입니다. 그것이 작동할 때 제공하는 것은 훌륭한 솔루션입니다. 작동하지 않으면 "이봐, 여기서는 작동하지 않는다"고 알려줍니다. 그냥 움직여. 다른 것이 필요합니다. 중요한 CSS에 도달하는 것이 항상 쉬운 것은 아닙니다. 반면에 4~5년 전만 해도 크리티컬 CSS는 엄청나게 컸습니다. 많은 도움이 되었습니다.

HTTP/3의 발전과 함께 지난 2~3년 동안 차단 렌더링된 하나의 중요한 CSS를 갖는 것은 100킬로바이트 또는 그 정도의 인라인 CSS를 갖는 데 매우 작은 영향을 미쳤습니다. 4~5년 전에 중요한 CSS를 사용했던 웹사이트만큼 빠르게 작동하는 웹사이트를 만들고 있습니다. 따라서 사이트 내부에 적당한 크기의 CSS를 두는 것을 두려워하지 마십시오. 당신은 그것을 제거할 필요가 없습니다. 그리고 매우 최적화된 웹사이트를 본 적이 있습니다.

100킬로바이트의 인라인 CSS와 같은 중요한 CSS가 있습니다. 그리고 렌더링 차단, jQuery 및 사용되지 않은 두 가지 다른 스크립트. 예, 예. 당신은 그것으로 목적을 무너뜨리고 있습니다. 5% 유형의 접근 방식을 지속하는 데 도움이 될 수 있습니다. 그러나 그것으로 시작한다면 첫 번째를보십시오.

ALEX ZUNIGA: 굉장합니다. 엄청난. 나는 그 모든 도구를 생각합니다. 그 외침을 듣는 것이 좋습니다. 이러한 제안과 권장 사항을 듣게 되어 기쁩니다. 그리고 그런 종류의 많은 것들이 우리의 다음 질문을 둘러싸고 있습니다. 특히 Core Web Vitals를 사용하여 WordPress에서 작업하는 고유한 측면은 무엇입니까? 다른 기술 스택과 비교하여 플러그인을 통해 이 작업을 수행해야 합니까? 워드프레스가 더 쉽나요? 사용 가능한 도구가 더 있습니까? 방금 언급했듯이 여러분 모두 많은 도구를 사용했습니다. 워드프레스가 더 쉽나요? 워드프레스가 더 어렵나요? 뭘 가져가?

MATT CHASE: WordPress를 사용하면 매우 쉽다고 생각합니다. 그래서 우리는 약간의 이야기를 나눴습니다. 또는 저는 그들이 배포하는 WordPress 스크립트 노드 패키지에 대해 언급했습니다. 이는 훌륭한 종류의 웹팩 빌드 시스템입니다. 그들은 또한 WordPress 기반 사이트에 대한 사용자 정의 블록을 부트스트랩하는 정말 빠르고 쉬운 방법인 WordPress Create 블록을 가지고 있습니다. 하지만 말하자면 많은 글루 코드가 여러분을 위해 작성되는 방식으로 만들어졌습니다. 그래서 그것은 이미 현명합니다– Mark, 당신은 당신이 해야 할 때 그 스크립트에 신호를 보낼 때만 언급했습니다. 따라서 귀하의 블록이 문 밖에서 바로 그렇게 하고 있는지 알 수 있습니다. 그것에 대해 생각할 필요조차 없습니다. 따라서 WordPress는 그런 종류의 작업을 정말 쉽게 만듭니다.

MARK DAVOLI: 네, 물론이죠. 그리고 그것은 오픈 소스입니다. 오른쪽? 따라서 거의 모든 것을 변경할 수 있습니다. Core Web Vitals와 WordPress를 최적화하기 위해 폐쇄형 시스템으로 작업할 때 훨씬 더 어렵습니다. 그리고 Core Web Vitals가 처음 발표되었을 때는 아직 그 수준에 도달하지 못했습니다. 훨씬 더 어려웠습니다. 그들은 자산, CSS 파일, 글꼴 파일 등을 선택적으로 로드하는 기능을 실제로 최적화하기 위해 특히 블록 편집기 및 블록 기반 건물 등을 사용하여 이러한 기능을 많이 추가하여 먼 길을 왔습니다. 그래. 정말 좋았습니다.

ALEX ZUNIGA: 아마도 폐쇄형 시스템 대 오픈 소스의 요구일 것입니다. 계속해, 산죽타.

SANJUCTA GHOSE: 네. 응. WordPress 전용 호스팅 제공업체가 많기 때문이라고 생각합니다. 그리고 당신이 말했듯이. 워드프레스는 오픈 소스입니다. 따라서 WordPress 사이트 호스팅과 관련하여 많은 최적화가 있습니다. 따라서 WordPress를 기반으로 구축하는 경우 이미 많은 지원이 가능하다고 생각합니다. 즉, 바퀴를 다시 발명할 필요가 없습니다. 따라서 Core Web Vitals를 최적화하기 위해 WordPress 위에 구축하는 것이 확실히 더 쉽다고 생각합니다.

알렉스 주니가: 아름답습니다. 그래서 우리는 이러한 도구를 측정하는 방법, Core Web Vitals, 일부 도구를 실제로 향상시키기 위해 무엇을 사용하는지에 대해 이야기했습니다. 이제 클라이언트 기대치에 대해 이야기할 때 새 프로젝트의 어느 단계에서 빌드 또는 전략의 일부로 Core Web Vitals를 고려하기 시작합니까? 기본 상용구 템플릿처럼 시작할 때 맞습니까? 아니면 스토리에서 조금 더 최적화하는 것인가요? 다들 뭐하세요?

맷 체이스: 네. 저에게는 이것이 최적화되지 않은 웹사이트에서 하는 것 이상으로 시작하는 것을 만드는 방법에 더 가깝다고 생각합니다. 처음부터입니다. 그리고 그것은 당신이 이상적으로 작성하는 모든 코드 라인에 있습니다. 크게 최적화된 사이트를 구축한 다음 나중에 돌아가서 수정하고 싶지 않습니다. 처음부터 최대한 깔끔하게 쓰고 싶습니다. 그런 다음 일반적으로 그런 식으로 작업을 수행하면 마지막에 마지막 최적화 주스를 짜내는 것이 조금 더 쉽습니다.

마크 다볼리: 네. 그는 절대적으로 정확합니다. 처음부터 바로 구축을 시작합니다. 내 말은, 끝이 가까워지면 일어나지 않는 구성 요소가 있다는 것입니다. 출시가 가까워질 때까지 이미지 최적화를 통해 이미지를 실행하지 않을 것입니다. 하지만 빌드 자체가 아니라 때때로 디자인 프로세스에서도 Core Web Vitals를 고려한다면 사이트가 어떻게 디자인되고 있는지 생각하는 것이 중요합니다. 구조적으로 특정 디자인을 다른 디자인보다 빠르게 구현하는 것이 더 어렵기 때문입니다. 따라서 잠재적으로 구현을 더 어렵게 만들 수 있는 것과 그렇지 않은 것에 대해 디자이너를 이해하고 교육하는 것이 매우 도움이 됩니다.

MIKE CRANTEA: 그리고 한계를 지시합니다. 이봐, 최대 x개의 전화만 가질 수 있어. 모든 변형과 함께 25개를 테이블에 가져오면 안 됩니다. 이는 설계 단계에서 도움이 됩니다. 또한 프로젝트 기간 동안 발생하는 일부 터치포인트가 없기 때문에 때로는 일부 작업을 쉽게 수행할 수 있습니다. 믹스에 퀴즈 플러그인을 추가하기 위한 스프린트 7개의 요청과 같습니다. 확인하지 않으면 마지막에 조금 찾을 수 있습니다. 그래서 제 권장 사항은 스프린트 두 번마다 이것을 처리하는 것입니다. 우리는 사물이 어떻게 진화하는지에 대한 스테이징에 대한 자동화된 측정을 확인합니다. 마지막으로 밀려난 일에 무슨 일이 일어 났습니까? 일이 느려졌습니까? 프로젝트가 끝날 때 반응하지 않고 사전에 시정 조치를 취해야 합니까?

SANJUCTA GHOSE: 네. 나는 동의한다. 팝업, 광고 배너 또는 이와 유사한 것이 있어야 하는지 여부와 같은 단순한 것과 같기 때문에 디자인 단계에서 시작하는 것이 매우 중요합니다. 때로는 누적 레이아웃 점수에 큰 차이가 있을 수 있습니다. 따라서 어떤 일이 일어날지 미리 아는 것이 좋습니다. 팝업이 나타나든 배너가 나타나든 상관없습니다. 그리고 프로젝트가 끝날 무렵 놀라움을 원하지 않습니다. 따라서 설계 단계부터 바로 클라이언트 또는 이해 관계자를 참여시키고 이들이 정보에 입각한 결정을 내릴 수 있도록 이것이 Core Web Vitals에 영향을 미칠 수 있다고 말하는 것이 매우 중요하다고 생각합니다.

MARK DAVOLI: 출시 후 매우 유용한 기능입니다. 사이트가 공개되자마자 나중에 채팅 위젯을 던지자고 생각하는 경우가 있기 때문입니다. 그러다가 갑자기 꼬임이 생깁니다. 그런 다음 이를 통합하고 최적화하는 방법에 대해 생각해야 합니다. 따라서 지연 스크립트 기능은 Core Web Vitals 점수를 죽이는 것으로 악명 높은 대부분의 광고 픽셀을 푸시할 수 있습니다. 하지만 클라이언트가 진정으로 원하는 것이 중요하기 때문에 무언가를 미룰 수 없는 경우도 있습니다. 따라서 최대한 균형을 잡고 잠재적인 영향을 전달해야 합니다. 그리고 최종 결과는 가능한 한 빨리 얻는 것입니다. 때로는 기능을 위해 희생해야 합니다. 때로는 그렇지 않습니다. 그러나 이러한 전환을 늘리려면 가능한 한 빨리 얻으십시오.

알렉스 주니가: 훌륭합니다. 훌륭한. 그래서 저는 더 나은 재료가 처음부터 더 나은 웹사이트를 만든다는 말을 듣고 있습니다. 마지막에 일부 Core Web Vitals를 치는 것이 아닙니다. 그런 식으로 먼저 생각하고 싶다면 정말 삶의 방식입니다. 글쎄요. 마지막 질문입니다. Core Web Vitals 작업에 소요되는 시간의 가치를 클라이언트에게 전달하는 데 문제가 있습니까? 그들이 다시 밀어 붙이는 것이 있습니까? 그들은 당신이 왜 그 일을 하는지 이해하지 못합니까?

MATT CHASE: 실제로 어떤 종류의 반발도 받은 적이 없는 것 같습니다. 오히려 그 반대입니다. 일반적으로 우리는 성능을 원합니다. 우리는 Core Web Vitals를 원합니다. 실현시켜 보자. 나는 우리가 항상 반성하지는 않는다고 말할 것입니다. 우리는 추적 픽셀에 대해 이야기했고 픽셀이 점수를 낮추는 것으로 악명 높은 방법에 대해 이야기했습니다. 하지만 아무도 신경 쓰지 않습니다. 우리는 픽셀, 픽셀, 픽셀, 픽셀과 같습니다. 따라서 사람들은 추적을 추가할 때 비용 이점을 실제로 평가하는 것에 대해 생각해야 합니다. 추적을 추가하고 결과를 얻는 것만 큼 간단하지 않기 때문입니다. 비용이 있기 때문입니다.

ALEX ZUNIGA: 굉장합니다.

MIKE CRANTEA: 퍼포먼스에는 인내심이 부족하다고 생각합니다. 그래서 만약 당신이 생각하고 있다면, 오, 첫 번째 스프린트 후에 몇 번의 스프린트를 지속할 성능 작업을 해보자. 언제 볼 수 있습니까? 언제 볼 수 있습니까? 하나의 기능, 하나의 기능, 하나의 기능을 늘리는 것과 같이 반복적으로 릴리스할 계획을 세우면 이 작업이 미치는 영향에 대한 확신이 커집니다. 그리고 이것이 전환과 변화로 해석되는 것을 더 많이 볼수록 교육 작업에 많은 시간을 할애하지 않고도 가치를 더 빨리 인식할 수 있습니다.

마크 다볼리: 네. 고객이 이해하기 까다로울 수 있는 한 가지는 실제 사용자 메트릭과 실험실 데이터의 차이입니다. 많은 사람들이 자체 테스트 등을 실행할 수 있기 때문입니다. 그리고 완전히 이해하지 마십시오. 따라서 페이지의 원본 요약 부분이 통찰력이라는 것을 이해하도록 돕는 것이 실제로 Google이 SEO 순위와 같은 효과를 내기 위해 사용하는 것입니다. 많은 사람들이 그 점수를 찾고 그것을 최적화하기 때문입니다. 그리고 변경 사항이 사물에 어떤 영향을 미치는지 전체 범위를 파악하기 전에 프로덕션에서 변경된 사항을 측정하는 데 28일이 걸린다는 점을 이해하도록 돕습니다.

ALEX ZUNIGA: 멋진 외침입니다. 훌륭한 외침.

MIKE CRANTEA: 그리고 가장 혼란스러운 지표 중 하나를 불러야 합니다. 상호 작용 지표. 그것들은 악명 높게 휘발성이었습니다. 그리고 점수의 변화를 더 두려워하는 일부 유형의 사람들에게는 우리가 구축한 새로운 기능이 웹 사이트 속도를 크게 저하시킨 것과 같은 것입니까? 그런 다음 다시 시험을 치면 10점 상승했다가 10점 하락하는 것과 같습니다. 이 변형을 설명하는 데 시간이 많이 걸립니다. 일관된 숫자가 하나뿐인 이유는 무엇입니까? 음, 이름을 지정하고 캐싱하는 것만큼 어려운 일입니다.

ALEX ZUNIGA: 글쎄요. Core Web Vitals에 대한 여러분의 모든 의견과 피드백에 진심으로 감사드립니다. 그것들을 사용하는 방법, 그것들을 측정하기 위해 무엇을 사용할 것인지, 그 모든 것에 대한 고객 기대치를 설정하는 방법. 정말 배움의 시간이 되었습니다. 패널리스트들이 즐거운 시간을 보내셨기를 바랍니다. 우리는 확실히 귀하의 모든 피드백을 듣는 것을 즐깁니다. 그리고 여기 참석하신 분들도 좋은 피드백을 받으셨기를 바랍니다.

여러분, 시간 내주셔서 정말 감사합니다. 글쎄, 그것은 우리 패널이었습니다. 패널 여러분께 정말 감사하다는 말씀을 드리고 싶습니다. 이 패널에 참석해 주셔서 감사합니다. DE{CODE} 세션의 나머지 부분을 시청하시면서 즐거운 시간을 보내시기 바랍니다.