Todo fornecedor afirma ser rápido. Nenhum número em uma apresentação de fornecedor, incluindo a nossa, deve decidir uma integração, pois o desempenho do API de imagem depende de onde estão seus usuários, o que você solicita e como você faz cache. O que um fornecedor pode honestamente oferecer é arquitetura e um método. Aqui estão ambos.
O que realmente determina a velocidade
- Cache na borda: se a imagem é servida a partir de um nó CDN próximo ao usuário ou renderizada sob demanda
- Tamanho da carga útil: formato e dimensões. Um WebP de 1200px é uma fração de um PNG de tamanho completo
- Frio vs quente: o primeiro pedido para uma combinação incomum de acabamento-cor-ângulo faz mais trabalho do que o milésimo pedido para uma popular
- Seu próprio cache: uma URL de imagem armazenada em seu CDN ou bucket custa zero de latência de API em cada visualização subsequente
A entrega em cache da borda é geralmente na casa das dezenas de milissegundos, essencialmente distância de rede. Renderizações frias levam mais tempo, e qualquer fornecedor honesto dirá isso. A questão de desempenho é, portanto, realmente uma questão de taxa de acertos em cache, e seu padrão de acesso decide isso mais do que o fornecedor.
Os quatro números que valem a pena medir
| Métrica | O que isso te diz | Como |
|---|---|---|
| TTFB, quente | Velocidade de entrega na borda | Repetir solicitações para a mesma URL |
| TTFB, frio | Velocidade do pipeline de renderização | Primeiras solicitações para combinações raras |
| p95, não a média | O que os usuários lentos experimentam | Centenas de solicitações, veja o desempenho |
| Bytes na rede | O que os usuários móveis baixam | Compare variantes de formato e largura |
Um benchmark que você pode executar em uma tarde
Pegue vinte veículos do seu próprio catálogo, reais, incluindo acabamentos impopulares. Para cada um, solicite os ângulos que você realmente exibiria, no formato e tamanho que realmente serviria, por exemplo front_left?format=webp&width=1200. Execute cada URL duas vezes, das regiões onde seus usuários estão, e registre os tempos frios e quentes separadamente. Repita na concorrência equivalente à hora de pico.
Dois detalhes fazem ou quebram a honestidade do resultado. Primeiro: meça a cauda, não a média. Um render lento escondido em uma média rápida é exatamente o que seus usuários notarão. Segundo: faça o benchmark do payload junto com a latência, pois um provedor que retorna o dobro de bytes com o mesmo TTFB é mais lento em todos os telefones reais.
Disciplina de carga útil
- Solicite WebP a menos que você precise especificamente da transparência PNG para impressão ou composição
- Solicite a largura que você renderiza. Enviar uma imagem de 2400px para um slot de 600px é puro desperdício
- Use o parâmetro de qualidade deliberadamente; os recortes de veículos resistem bem à compressão
- Armazene em cache de forma agressiva do seu lado: a solicitação mais rápida é a que você nunca faz.
Lendo os resultados honestamente
Quando os números voltarem, resista a transformá-los em uma única pontuação. Um provedor com um caminho de acesso rápido e um caminho de acesso lento se adapta a um marketplace cujos mil veículos principais absorvem a maior parte do tráfego, e se adapta a um fluxo de cotação de seguro de longo prazo muito pior. Combine a forma do perfil de latência com a forma do seu padrão de acesso, pois essa adequação importa mais do que qual fornecedor ganha a mediana principal.
Nossa própria arquitetura, ou seja, parâmetros de solicitação, formatos e entrega, está documentada na página da API de imagens de veículos e na documentação da API. Execute o benchmark da tarde contra nós e contra qualquer outra pessoa que você esteja considerando; essa comparação supera qualquer tabela que poderíamos publicar.
