웹 성능 컨설턴트 backend
서버 TTFB 제어, performant backend
ORM N+1, indexed되지 않은 쿼리, blocking synchronous job. Laravel, Symfony, Django 및 인프라를 최적화해 서버 응답 시간을 장기적으로 떨어뜨립니다.
Ils me font confiance
감사를 부르는 backend 신호
Backend는 성능의 천장입니다. 다뤄지지 않는 한 frontend 최적화는 제한된 효과를 가집니다.
⏱️ 전략 페이지에서 TTFB가 600ms 이상
PageSpeed는 원인을 제공하지 않고 빨간 TTFB를 표시합니다. APM 트레이스가 즉시 느린 SQL 쿼리, blocking third-party 서비스, 비용 큰 deserialization을 표면화합니다.
🔁 누구도 보지 못하는 N+1 쿼리
ORM은 join을 보이지 않게 만듭니다. with() 없이 50개 entity에 loop하고 relation에 접근하는 페이지는 51개 쿼리를 트리거합니다. Telescope, Symfony Profiler, django-silk가 즉시 패턴을 노출합니다.
📊 Hot 테이블의 non-indexed SQL 쿼리
Slow query에 대한 EXPLAIN이 full scan을 식별합니다. 접근 패턴에 적합한 index 추가가 쿼리 시간을 10x~100x 떨어뜨립니다.
🔌 Rendering을 차단하는 third-party 호출
Synchronous 인증, fraud scoring, marketing webhook, 원격 캐시. APM Service Map이 이를 가시화합니다. 비동기화, 캐싱, 이동시킵니다.
💾 Object cache 없음, Redis 없음
DB session, 모든 페이지에서 다시 쿼리되는 option, uncached fragment. Cache와 session을 위한 Redis가 애플리케이션 코드를 건드리지 않고 TTFB를 떨어뜨립니다.
⚙️ PHP 7.x 또는 Python 3.10, opcache 비활성화
PHP 8.x + opcache + JIT가 실행 시간을 2~4로 나눕니다. Python 3.11+가 상당한 interpreter 이득을 가져옵니다. Runtime 업그레이드는 가장 비용 효율적인 스택 이득입니다.
제가 최적화하는 backend 스택
Laravel (Eloquent, opcache, Octane), Symfony (Doctrine, HTTP cache, FrankenPHP), Python (Django ORM, async, gunicorn). 이미 도입된 것에 따라 Datadog 또는 Dynatrace instrumentation과 함께.
미션 약속
Frequently asked questions
Laravel, Symfony, Django 중 어느 것이 최고의 성능을 가지는가?
제 backend가 병목인지 어떻게 알 수 있나?
Async (Octane, FrankenPHP, FastAPI)로 이동해야 하나?
Backend engagement는 어떻게 구조화됩니까?
Backend TTFB를 떨어뜨리세요
2023-2025 데이터
Ce qu'en disent mes clients
훌륭한 작업입니다.
Paul은 사이트 속도를 눈에 띄게 개선했고 Google 권장사항에 완벽히 맞춰 주었습니다.
전문적이고 꼼꼼하며 효율적이라 강력히 추천합니다.
Nicolas - April Moto
디지털 & 이커머스 디렉터
저희는 Paul의 업무에 매우 만족하고 있습니다. 그는 신속하고, 언제든지 응대 가능하며, 특히 효율적입니다. 그가 합류한 이후 성과와 대응력 측면 모두에서 매우 좋은 결과가 확인되었습니다. 저희 팀의 진정한 자산입니다.
Léo - Maison de luxe
이커머스 프로덕트 오너
우리가 이 말을 충분히 했는지는 모르겠지만.
하지만 로딩 속도를 개선하고,
Google을 만족시키고 Core Web Vitals를 초록 영역으로 만들고 싶다면,
Paul Delcloy에게 연락하세요.
Florian Darroman - Les Makers
공동 창업자
TTFB, 성능의 유리 천장
Time To First Byte는 전체 rendering chain의 바닥을 설정합니다. 브라우저는 서버가 응답할 때까지 아무것도 시작할 수 없습니다. 800ms TTFB는 완벽하게 최적화된 frontend로도 LCP가 1.5~2초 미만으로 떨어질 수 없음을 의미합니다.
감사에서 정기적으로 발견하는 발견입니다: 팀이 lazy loading과 이미지 압축에 수주를 투자하는 동안, 실제 병목은 category 페이지에서 1.2초 서버 응답 시간입니다. Backend가 다뤄지지 않는 한 frontend 최적화는 제한된 효과를 가집니다.
일반적인 원인
Backend 성능 문제는 프로젝트마다 비슷해 보입니다. 50개 제품 카탈로그의 표시를 200개 데이터베이스 호출로 바꾸는 N+1 쿼리. 구성되었지만 너무 자주 invalidate되거나 전혀 invalidate되지 않는 application cache. Third-party API(ERP, search engine, stock service)에 대한 synchronous 호출이 응답할 때까지 rendering을 차단합니다.
Instrumentation이 시작점입니다. 요청 내부에서 무슨 일이 일어나는지에 대한 가시성 없이는 추측합니다. Dynatrace, Datadog, New Relic. 도구는 거의 중요하지 않습니다. 중요한 것은 HTTP 요청을 종단 간으로 추적하고 시간이 정확히 어디에서 소비되는지 볼 수 있는 능력입니다. E-commerce checkout에서 "서버가 8초가 걸린다"와 "서버가 8초가 걸리며, ERP 응답을 기다리는 5초 포함" 사이의 차이는 접근을 완전히 바꿉니다.
Cache 및 invalidation 전략
Cache는 아마도 backend에서 가장 강력하고 가장 underused한 lever입니다. 잘 구성된 page cache는 고트래픽 페이지에서 TTFB를 10으로 나눌 수 있습니다. 복잡성은 invalidation에 있습니다: 가격이 변경될 때, 제품이 매진될 때, 프로모션이 시작될 때.
제가 보는 대부분의 구현은 너무 aggressive하거나(stale 가격을 서비스하는 5분 cache), 너무 conservative(모든 수정에서 global invalidation, 이는 cache가 없는 것과 같음)입니다. 효율적인 전략은 granular합니다: 정확히 변경된 것을 invalidate하고, 전체 카탈로그가 아닙니다.
성능과 인프라 비용
요청당 더 적은 CPU를 소비하는 backend는 동일한 트래픽을 처리하기 위해 더 적은 서버가 필요합니다. 사용량으로 청구되는 cloud 아키텍처에서 코드 최적화는 직접 청구로 변환됩니다. 최적화된 SQL 쿼리, 효율적인 cache, 병렬화된 외부 호출. 합산됩니다. 사용자 성능 이득은 비용 감소 옆에 거의 bonus입니다.
제 backend 전문 페이지
- Laravel: Eloquent N+1, opcache, Octane, async queue
- Symfony: Doctrine, HTTP cache, ESI, FrankenPHP
- Python: Django ORM, async view, gunicorn, FastAPI
- Datadog: APM, trace, P95, continuous profiling
- Dynatrace: Smartscape, PurePath, auto baseline
CMS에서 제 backend 개입은 WordPress, Drupal, Magento, Shopify, Prestashop을 커버합니다.
Backend + frontend + CDN을 커버하는 complete 개입의 경우 제 웹 성능 감사가 가장 효율적인 entry point로 남아 있습니다.