wp-performance

wp-performance 스킬 개요

wp-performance가 하는 일

wp-performance 스킬은 브라우저 UI에 의존하지 않고, 백엔드에서 WordPress 성능을 조사하고 개선하는 데 도움을 줍니다. “이 사이트가 느리다”는 상태에서 측정 가능한 해결책까지 실제로 이어질 수 있도록 설계되어 있으며, 특히 WordPress 6.9+ 환경의 Performance Optimization 작업에 잘 맞습니다.

누가 설치하면 좋은가

프론트엔드 요청, 관리자 페이지, REST 라우트, WP-Cron 동작이 느릴 때 wp-performance 스킬을 사용하세요. 프로파일링, 원인 진단, 안전한 검증까지 안내된 워크플로가 필요할 때 특히 유용합니다. WP-CLI, 로그, 직접 HTTP 요청은 사용할 수 있지만, 완전한 브라우저 기반 디버깅 세션은 어렵거나 불가능한 경우에 가장 효과적입니다.

무엇에 가장 잘 맞는가

wp-performance 스킬의 가장 강한 부분은 측정 우선의 트리아지와 데이터베이스 쿼리, autoloaded options, object cache, cron, 원격 HTTP 호출에 대한 백엔드 수정입니다. 또한 작업에 맞는 도구를 고르게 해 주며, wp profile, wp doctor, REST 헤더를 통한 Query Monitor, 가능할 경우 Server-Timing까지 안내합니다.

wp-performance 스킬 사용 방법

올바르게 설치하고 범위를 지정하기

WordPress/agent-skills 컬렉션에서 wp-performance install 흐름을 실행하고, 스킬 슬러그가 wp-performance인지 확인한 뒤 분석을 요청하기 전에 대상 사이트 컨텍스트를 다시 점검하세요. WordPress 루트에는 --path=<path>를 지정하는 것이 가장 좋고, multisite 또는 라우팅된 설치에서는 평가할 정확한 사이트나 엔드포인트에 대해 --url=<url>도 함께 지정해야 합니다.

스킬이 실제로 필요한 입력을 주기

좋은 wp-performance usage 프롬프트에는 증상, 범위, 환경이 모두 들어가야 합니다. 예를 들어: “Staging site, no writes allowed, slow logged-in admin dashboard, use wp-performance to profile the main query path and suggest safe read-only checks first.” 이렇게 쓰는 편이 “site is slow”보다 훨씬 낫습니다. 무엇을 측정해야 하는지, 어떤 제약이 있는지를 스킬이 바로 이해할 수 있기 때문입니다.

먼저 읽어야 할 파일을 정확히 고르기

증상에 따라 먼저 SKILL.md를 읽고, 이어서 references/measurement.md, references/database.md, references/autoload-options.md, references/object-cache.md, references/cron.md, references/http-api.md를 살펴보세요. 헤드리스 Query Monitor나 커맨드 중심 점검이 필요하면 references/query-monitor-headless.md, references/wp-cli-profile.md, references/wp-cli-doctor.md, scripts/perf_inspect.mjs도 함께 확인해 워크플로 신호를 잡는 것이 좋습니다.

측정 우선 워크플로를 사용하기

가장 좋은 wp-performance guide 흐름은 이렇습니다: 기준선을 먼저 캡처하고, 재현 가능한 단일 URL 또는 REST 라우트를 테스트한 다음, 가장 비용이 큰 계층을 확인하고, 마지막으로 타깃을 좁힌 변경 후 다시 검증합니다. 실행마다 같은 시나리오를 유지하고, 한 번의 급등값보다 여러 샘플을 비교하며, 명시적으로 허용하지 않았다면 파괴적인 작업을 요청하지 않도록 하세요.

wp-performance 스킬 FAQ

wp-performance는 백엔드 에이전트 전용인가요?

네. 이 스킬은 WP-CLI, 헤더, 로그, HTTP 요청을 활용하는 백엔드 전용 조사용으로 설계되었습니다. 브라우저 상호작용, 시각적 waterfall 분석, 클릭 경로 테스트가 필요하다면 wp-performance는 주 도구로 적합하지 않습니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트는 “WordPress를 최적화하라”고만 말할 수 있지만, wp-performance는 측정, 안전장치, WordPress 특유의 장애 영역을 고려한 제한된 워크플로를 제공합니다. 병목이 DB 쿼리인지, autoload 비대화인지, cron인지, 원격 HTTP 호출인지에 따라 해결책이 달라지므로 이 차이가 중요합니다.

초보자도 쓰기 쉬운가요?

네, 증상을 설명하고 설치 컨텍스트를 제공할 수 있다면 그렇습니다. 이 스킬은 첫 점검 범위를 좁혀 주기 때문에 초보자에게도 도움이 됩니다. 다만 명확한 대상 URL이나 라우트를 주어야 하고, writes, plugin installs, cache flushes가 허용되는지도 함께 알려야 합니다.

언제는 사용하지 말아야 하나요?

문제가 CDN 라우팅, DNS 장애, 순수한 프론트엔드 JavaScript 병목처럼 WordPress 실행과 무관하다면 wp-performance를 쓰지 마세요. 서버에 접근할 수 없고, WP-CLI도 실행할 수 없고, HTTP 응답이나 로그를 확인할 방법도 없는 경우에도 적합하지 않습니다.

wp-performance 스킬 개선 방법

시작 증거를 더 구체적으로 주기

가장 유용한 입력은 구체적인 대상과 증상 패턴을 함께 주는 것입니다: https://example.com/wp-json/..., “logged-in editors에서만 느림”, “TTFB가 5분마다 치솟음”, “로그인 후 admin page가 멈춤” 같은 정보가 좋습니다. 그래야 wp-performance가 추측이 아니라 측정 경로를 기준으로 선택할 수 있습니다.

어떤 변경이 가능한지도 분명히 말하기

안전한 1차 점검을 원한다면 그렇게 말하세요. 예: “Read-only diagnostics only,” “no cache flush,” 또는 “staging only, can change options.” 이렇게 주면 wp-performance skill이 위험한 점검을 피하고 운영 제약 안에서 움직일 수 있어 워크플로가 더 정확해집니다.

진단만이 아니라 수정 경로까지 요청하기

가장 좋은 wp-performance usage 결과는 병목과 다음 검증 단계까지 함께 요청할 때 나옵니다. 예를 들어: “Identify the slowest layer, name the likely cause, and give the exact follow-up command or request to confirm improvement.” 이렇게 요청하면 결과가 바로 실행 가능한 형태로 나옵니다.

첫 보고를 바탕으로 반복 개선하기

첫 분석이 쿼리를 가리키면, 느린 table, hook, route를 다시 전달하고 더 좁힌 query plan을 요청하세요. autoloaded options, object cache, cron, HTTP API 호출이 원인이라면, 가장 작은 범위의 안전한 remediation과 before/after measurement plan을 요청하는 것이 좋습니다. 바로 이 지점에서 wp-performance 스킬은 Performance Optimization 작업에 가장 큰 가치를 제공합니다.