Files
amare/scripts/perf/lighthouse.sh
Manoel Freitas 0ecae4c7d6 fix: reduzir I/O remoto de imagens R2 (MAN-109) (#43)
* perf: cortar 157 KiB do caminho crítico e medir o LCP de forma reprodutível (MAN-109)

A auditoria do PR #34 mediu LCP acima da meta de 2,5 s da SPEC §6.6 em todas
as páginas no mobile, mas ficou registrada apenas como tabela num comentário
do Linear — `storage/app/lighthouse` é gitignored, então não havia artefato
para comparar depois. Esta entrega mede de novo, encontra a causa dominante e
corta o que dava para cortar.

## Fontes servidas em dobro (88 KiB)

Bunny entrega cada peso de EB Garamond em woff2 e woff, e o plugin de fontes
emitia uma regra `@font-face` para cada, woff2 primeiro e woff depois. Duas
regras com a mesma família, peso, estilo e unicode-range fazem a última
vencer: o navegador renderizava a partir dos woff e descartava os woff2
pré-carregados.

O log de rede da home prova: 3 woff em prioridade VeryHigh (88 KiB), a mais
alta da página e à frente do elemento de LCP, mais 3 woff2 em High (74 KiB)
baixados só por causa do `<link rel="preload">`. 162 KiB de tráfego para
74 KiB de fonte útil.

woff2 é suportado por todo navegador que este site atende desde 2016, então as
regras woff eram peso morto, não fallback. O plugin `amare:fonts-woff2-only`
remove as regras do CSS e do manifest e tira os arquivos do bundle. É o que
derruba o FCP de 1,51 s para 0,91 s em todas as páginas.

## Ativos de marca reencodados (102 KiB) — absorve MAN-122

O logotipo era servido a 512 px de largura para renderizar em 48 px (lockup,
cabeçalho e rodapé de toda página) e 32 px (mark, home), com `loading="eager"`.
Reencodados a 3× do maior render: lockup 149×144 (84 → 14 KiB) e mark 191×96
(42 → 10 KiB), mesmos nomes de arquivo para não invalidar cache. As variantes
`on-dark` foram reencodadas junto por consistência; nenhuma view as usa hoje.

Os 16 baselines visuais foram regenerados no runner Linux e o diff é
imperceptível a 2× de zoom — mesma forma, mesma cor, menos bytes.

## Efeito medido

Mobile, mediana de 3 execuções por página: home 4,58 → 3,39 s; portfolio
3,98 → 1,58 s; portfolio-detalhe 3,98 → 3,01 s; servicos 3,68 → 2,63 s;
sobre 3,01 → 1,58 s; contato 2,55 → 1,51 s. Desktop passa com folga em todas
(máximo 0,79 s). Acessibilidade, boas práticas e SEO seguem 100, CLS 0,000 e
TBT 0 ms.

`contato`, `portfolio` e `sobre` entraram na meta. `servicos`,
`portfolio-detalhe` e `home` continuam fora, e o que falta está identificado:
o elemento de LCP da home é a imagem do hero em JPEG q82 (143 KiB), e
`Improve image delivery` estima 0,90 s de ganho restante. O lever é variante
WebP em ResponsiveImage com `<picture>` — fora deste escopo porque mexe no
pipeline de mídia que o CMS usa para upload.

## Ferramental

- `scripts/perf/lighthouse.sh` ganha `/portfolio/{slug}`, passada desktop,
  mediana de 3 execuções e uma guarda de HTTP 200 antes de auditar. Uma rota
  em 404 produz relatório com score alto: a rota mais pesada do site
  apareceria como ótima e ninguém notaria.
- `scripts/perf/summarize-lighthouse.mjs` extrai do JSON o elemento de LCP, a
  decomposição em fases e as requests até o LCP.
- `docker/ci-runner.Dockerfile` e `scripts/test/visual-update-ci.sh` versionam
  a receita de regeneração de baselines, que existia só como checklist.
- `CLAUDE.md` corrigido: Pest Browser serve a aplicação de um servidor Amp
  in-process, não do FrankenPHP. A paridade que importa nos baselines é
  Linux vs macOS, não o runtime HTTP.
- Sem gate de performance no CI (§14.1 e §22). No lugar, orçamento de bytes
  para os ativos de marca e asserção de que o build só emite woff2.

Staging não foi medido: a origem responde 303 para blocked.teams.cloudflare.com
a partir da rede corporativa, inclusive em `/up`. Duas hipóteses seguem não
validadas por dependerem de `FILESYSTEM_DISK=r2` — os ~4 round trips a R2 por
imagem que `x-media.image` faz sem cache, e a falta de `preconnect` para a
origem cross-origin de mídia. Ambas documentadas em
docs/evidence/lighthouse/README.md.

Co-Authored-By: Claude noreply@anthropic.com
AI-Assisted: yes
AI-Tool: claude-code

* perf: servir imagens de conteúdo em webp e descrever sizes corretamente (MAN-109)

Fecha a meta de LCP ≤ 2,5 s da SPEC §6.6 em todas as páginas, nos dois presets.
Continuação direta do commit anterior: com fontes e marca resolvidas, o elemento
de LCP de toda página no mobile passou a ser a imagem do hero, e o Load Delay de
1,88 s era contenção de banda pura.

## Variantes webp

`ResponsiveImage::generate()` escreve uma variante `.webp` ao lado de cada
variante no formato original, e `x-media.image` a oferece num
`<source type="image/webp">`. O `<img>` continua apontando para o formato
original: o `<source>` é preferência, não substituição, então nada quebra em
quem não decodifica webp, e mídia antiga sem irmãos webp renderiza `<img>` puro
como antes.

O `<picture>` recebe `display: contents` porque os chamadores estilizam o `<img>`
com classes como `h-full w-full object-cover` que resolvem contra o pai grid ou
flex — um wrapper inline quebraria isso.

O nome do arquivo acrescenta a extensão em vez de trocá-la
(`photo-720.jpg.webp`): uploads usam UUID, então colisão já era improvável, mas
`photo-720.webp` colidiria com a variante webp de um `photo.png`.

## sizes que descreve a realidade

Nenhuma imagem do site ocupa a viewport inteira — todas ficam dentro de
`container-amare`, que reserva 1,5rem de padding de cada lado. Declarar `100vw`
fazia uma viewport de 412 px em DPR 1,75 pedir 721 px e pular para a variante de
960 para desenhar uma caixa de 637 px. Errar por um pixel custava um terço a mais
de bytes em toda página.

Com `calc(100vw - 3rem)` a home passa a usar a variante de 720: 74 KiB, contra
143 KiB no início da investigação. Foi também por isso que 720 entrou em
`ResponsiveImage::WIDTHS` — sem ela o salto de 480 para 960 é grande demais para
a viewport mobile mais comum.

## Efeito medido

Mobile, mediana de 3 execuções: home 3,39 → 2,49 s; portfolio-detalhe
3,01 → 2,18 s; servicos 2,63 → 2,03 s; portfolio 1,58 s; sobre 1,58 s;
contato 1,50 s. Desktop no máximo 0,65 s. Peso total da home 798 → 347 KiB.

Contra o início da investigação (`2e43fde`): home 4,58 → 2,49 s com score de
performance 83 → 98.

A home passa **em cima da linha** — a pior das três execuções deu 2,57 s. Está
documentado como aprovada por margem, não com folga, e os levers restantes estão
listados em docs/evidence/lighthouse/README.md em ordem de custo.

Os 16 baselines visuais não mudaram: nenhum seeder gera variantes e
`media:generate-variants` não roda no runner visual, então naquele ambiente
`availableVariants()` volta vazio e o componente renderiza `<img>` puro. A
cobertura do caminho com variantes fica em MediaImageComponentTest e
ResponsiveImageTest, não nos baselines — anotado como lacuna conhecida.

Co-Authored-By: Claude noreply@anthropic.com
AI-Assisted: yes
AI-Tool: claude-code

* docs: registrar a dependência do deploy e corrigir os commits nas evidências

Três correções de honestidade nos artefatos de medição.

O campo `Commit:` era gravado com o HEAD do momento da coleta, que é sempre
anterior ao commit que contém as mudanças medidas — as duas passadas pós-correção
diziam `2e43fde` e `65919d4` quando as árvores medidas viraram `65919d4` e
`9ab2beb`. Corrigido à mão nos dois arquivos, e o script passa a marcar
`+alterações não commitadas` quando a árvore está suja, para o artefato não voltar
a afirmar o que não é.

O ganho das imagens não aparece em staging nem em produção antes de
`media:generate-variants` rodar: lá o disco é `r2` e as variantes webp e a largura
720 ainda não existem para a mídia publicada. O serviço `migrate` do
docker-compose.deploy.yml roda o comando sem condição a cada deploy e ele
regenera mesmo quando já há variantes, então o primeiro deploy resolve — mas
estava implícito e agora está escrito.

E o custo que as variantes webp introduzem no lado servidor está registrado com o
número certo: `x-media.image` faz 8 `exists()` por imagem no lugar de 3, o que em
`r2` são ~9 round trips remotos por imagem e ~36 na home. Isso agrava a hipótese
não validada de TTFB em staging em vez de melhorá-la, e promove o cache desses
metadados a item mais urgente da lista.

Co-Authored-By: Claude noreply@anthropic.com
AI-Assisted: yes
AI-Tool: claude-code

* fix: cache responsive image metadata for R2

* test: atualizar baselines visuais Linux

---------

Co-authored-by: manoel.neto <manoel.neto@creditas.com>
2026-08-10 20:08:15 -03:00

138 lines
5.4 KiB
Bash
Executable File

#!/usr/bin/env bash
#
# Lighthouse run against the production image, reproducing the measurement
# behind MAN-109. Not a CI gate — SPEC.md §14.1 pins the five blocking jobs and
# §22 governs when new capability is added. This is the recipe so the numbers
# can be reproduced instead of remembered.
#
# Usage:
# scripts/perf/lighthouse.sh [output-dir]
#
# Environment:
# BASE_URL origin to audit (default http://127.0.0.1:8000)
# TARGET label for the output subtree (default local)
# RUNS runs per page and preset (default 3)
# PRESETS space-separated preset list (default "mobile desktop")
#
# Lighthouse LCP moves by a few tenths of a second between runs on the same
# build, so a single run cannot support a before/after comparison. Every page
# is audited RUNS times per preset and the run holding the median LCP is the
# one reported — averaging across runs would describe a page that never
# existed.
#
# Expects a site already answering on $BASE_URL. To raise one from scratch:
#
# docker build -t amare-app:ci .
# docker run -d --name amare-web -p 8000:8000 \
# -e APP_ENV=production -e APP_DEBUG=false -e APP_KEY="$APP_KEY" \
# -e DB_CONNECTION=pgsql -e DB_HOST=host.docker.internal -e DB_PORT=5432 \
# -e DB_DATABASE=amare -e DB_USERNAME=amare -e DB_PASSWORD=secret \
# -e SESSION_DRIVER=database -e CACHE_STORE=database -e QUEUE_CONNECTION=database \
# --add-host=host.docker.internal:host-gateway \
# -v "$(pwd)/storage/app/public:/app/storage/app/public" \
# amare-app:ci
#
# Seed content and generate the responsive variants first, and run both from
# the host rather than inside the container. ContentSeeder guards itself with
# an allow-list of local/staging/testing (database/seeders/ContentSeeder.php),
# so under the container's APP_ENV=production it is a deliberate no-op and
# Lighthouse would end up measuring empty pages. Skipping
# `media:generate-variants` inflates LCP by roughly 2.5 s on the home page,
# because the originals are served at full size:
#
# php artisan db:seed --class=ContentSeeder --force
# php artisan media:generate-variants
#
set -euo pipefail
BASE_URL="${BASE_URL:-http://127.0.0.1:8000}"
BASE_URL="${BASE_URL%/}"
TARGET="${TARGET:-local}"
RUNS="${RUNS:-3}"
PRESETS="${PRESETS:-mobile desktop}"
OUT_DIR="${1:-storage/app/lighthouse}/${TARGET}"
# Lighthouse needs a Chrome binary. Playwright's is already on disk after
# `npx playwright install chromium`; fall back to a system Chrome.
if [[ -z "${CHROME_PATH:-}" ]]; then
PLAYWRIGHT_CHROME=$(find "${HOME}/Library/Caches/ms-playwright" "${HOME}/.cache/ms-playwright" \
-maxdepth 3 -name 'Google Chrome for Testing' -type f 2>/dev/null | head -1 || true)
if [[ -n "${PLAYWRIGHT_CHROME}" ]]; then
export CHROME_PATH="${PLAYWRIGHT_CHROME}"
fi
fi
mkdir -p "${OUT_DIR}"
PAGES=(
"/:home"
"/servicos:servicos"
"/portfolio:portfolio"
"/portfolio/casamento-ana-lucas:portfolio-detalhe"
"/sobre:sobre"
"/contato:contato"
)
# A route that answers 404 still produces a Lighthouse report, and the error
# page is light enough to score well — the heaviest route on the site would be
# reported as excellent and nobody would notice. Refuse to measure anything
# that is not a 200 before spending minutes on the audit.
echo "preflight against ${BASE_URL}"
for entry in "${PAGES[@]}"; do
path="${entry%%:*}"
code="$(curl -sS -o /dev/null -w '%{http_code}' --max-time 20 "${BASE_URL}${path}" 2>/dev/null || true)"
if [[ "${code}" != "200" ]]; then
echo "preflight failed: ${BASE_URL}${path} answered HTTP ${code:-<none>}, expected 200" >&2
exit 1
fi
echo " ok ${path}"
done
for preset in ${PRESETS}; do
# The mobile preset is Lighthouse's default and rejects an explicit
# --preset flag, so only desktop is passed through.
preset_flags=()
if [[ "${preset}" != "mobile" ]]; then
preset_flags+=("--preset=${preset}")
fi
for entry in "${PAGES[@]}"; do
path="${entry%%:*}"
name="${entry##*:}"
for run in $(seq 1 "${RUNS}"); do
echo "auditing ${name} ${preset} run ${run}/${RUNS} (${BASE_URL}${path})"
# Default preset: simulated mobile throttling, 150 ms RTT,
# ~1.6 Mbps, 4x CPU slowdown.
# ${array[@]+...} keeps `set -u` from treating an empty array as
# unbound, which bash 3.2 (the macOS system bash) still does.
npx --yes lighthouse@12 "${BASE_URL}${path}" \
--quiet \
${preset_flags[@]+"${preset_flags[@]}"} \
--output=json --output=html \
--output-path="${OUT_DIR}/${name}-${preset}-run${run}" \
--chrome-flags="--headless=new --no-sandbox"
done
done
done
echo
echo "reports written to ${OUT_DIR}"
# The seeder is recorded because it decides the byte weight of every hero
# image: a before/after comparison across different fixtures measures nothing.
node scripts/perf/summarize-lighthouse.mjs "${OUT_DIR}" \
--target="${TARGET}" \
--base-url="${BASE_URL}" \
--commit="$(git rev-parse --short HEAD 2>/dev/null || echo unknown)$(git diff --quiet HEAD 2>/dev/null || echo '+alterações não commitadas')" \
--seeder="${SEEDER:-ContentSeeder}" \
> "${OUT_DIR}/summary.md"
echo "summary written to ${OUT_DIR}/summary.md"
echo "SPEC.md §6.6 targets: LCP <= 2.5s, CLS <= 0.1, INP <= 200ms, 0 console errors"