Jeder Anbieter verspricht Schnelligkeit. Keine Zahl in einer Anbieterpräsentation, auch nicht unserer, sollte eine Integration entscheiden, weil die Leistung einer Bild-API von der Lage Ihrer Nutzer, Ihrer Anfrage und Ihrem Cache abhängt. Was ein Anbieter Ihnen ehrlich geben kann, ist Architektur und eine Methode. Hier sind beide.
Was bestimmt tatsächlich die Geschwindigkeit
- Edge-Caching: ob das Bild von einem CDN-Knoten in der Nähe des Benutzers geliefert oder auf Anfrage gerendert wird
- Payload-Größe: Format und Abmessungen. Ein 1200px WebP ist ein Bruchteil eines Vollformat-PNG
- Kalt vs. warm: Die erste Anfrage für eine ungewöhnliche Kombination aus Ausstattung, Farbe und Winkel erfordert mehr Arbeit als die millionste Anfrage für eine beliebte Kombination
- Ihr eigenes Caching: eine in Ihrem CDN oder Bucket gespeicherte Bild-URL verursacht keine API-Latenz bei jedem weiteren Aufruf.
Die gelieferte Zwischenspeicherung vom Rand erfolgt typischerweise im Bereich von einigen Millisekunden, im Wesentlichen der Netzwerkentfernung. Kalte Rendern dauern länger, und jeder ehrliche Anbieter wird das zugeben. Die Leistungsfrage ist daher wirklich eine Frage des Cache-Treffer-Verhältnisses, und Ihr Zugriffsmuster entscheidet darüber mehr als der Anbieter.
Die vier Zahlen, die sich zu messen lohnen
| Metrik | Was es Ihnen sagt | Wie |
|---|---|---|
| TTFB, warm | Edge-Liefergeschwindigkeit | Wiederholte Anfragen für dieselbe URL |
| TTFB, kalt | Geschwindigkeit der Render-Pipeline | Erste Anfragen für seltene Kombinationen |
| p95, nicht Durchschnitt | Was langsame Nutzer erleben | Hunderte Anfragen, schauen Sie sich den Tail an |
| Bytes im Netzwerk | Was mobile Nutzer herunterladen | Format- und Breitenvarianten vergleichen |
Ein Benchmark, den Sie an einem Nachmittag durchführen können
Nehmen Sie zwanzig Fahrzeuge aus Ihrem eigenen Katalog, echte, einschließlich unpopulärer Ausstattungen. Für jedes fordern Sie die Winkel an, die Sie tatsächlich anzeigen würden, im Format und in der Größe, die Sie tatsächlich ausliefern würden, zum Beispiel front_left?format=webp&width=1200. Führen Sie jeden URL zweimal aus, aus den Regionen, in denen Ihre Nutzer sind, und zeichnen Sie die Kalt- und Warmzeiten getrennt auf. Wiederholen Sie dies bei der Äquivalenz Ihrer Spitzenstunde und gleichzeitiger Nutzung.
Zwei Details machen oder brechen die Ehrlichkeit des Ergebnisses. Erstens: Messen Sie den Schwanz, nicht den Mittelwert. Eine langsame Renderung, die in einem schnellen Durchschnitt versteckt ist, ist genau das, was Ihre Nutzer bemerken werden. Zweitens: Benchmarken Sie die Payload zusammen mit der Latenz, weil ein Anbieter, der doppelt so viele Bytes bei gleicher TTFB zurückgibt, auf jedem echten Telefon langsamer ist.
Payload-Disziplin
- Fordern Sie WebP an, es sei denn, Sie benötigen PNG-Transparenz speziell für den Druck oder das Compositing
- Fordern Sie die Breite an, die Sie rendern. Ein 2400px-Bild in einen 600px-Slot zu senden, ist reine Verschwendung
- Den Qualitätsparameter gezielt einsetzen. Fahrzeugausschnitte überstehen die Komprimierung gut
- Zwischenspeichern Sie aggressiv auf Ihrer Seite: Die schnellste Anfrage ist die, die Sie nie stellen.
Ergebnisse ehrlich lesen
Wenn die Zahlen zurückkommen, widerstehen Sie der Versuchung, sie zu einem einzigen Wert zu mitteln. Ein Anbieter mit einem schnellen Warmweg und einem langsamen Kaltweg eignet sich für einen Marktplatz, dessen Top-Tausend-Fahrzeuge den meisten Verkehr absorbieren, und eignet sich für einen langfristigen Versicherungsangebotsfluss viel schlechter. Passen Sie die Form des Latenzprofils an die Form Ihres Zugriffsmusters an, denn diese Passform ist wichtiger als der Median eines Anbieters.
Unsere eigene Architektur bedeutet, dass Anfrageparameter, Formate und Lieferung auf der Seite Vehicle Image API und in der API-Dokumentation dokumentiert sind. Führen Sie den Nachmittags-Benchmark gegen uns und gegen jeden anderen durch, den Sie in Betracht ziehen. Dieser Vergleich schlägt jede Tabelle, die wir veröffentlichen könnten.
