Onlineshop auf den Black Friday vorbereiten: Lasttests, Checkout und Performance

Warum eine erreichbare Website keine erfolgreichen Bestellungen garantiert

Ein Shop kann seine Startseite ausliefern, während Kunden ihre Einkäufe nicht abschließen können. Black-Friday-Traffic belastet dynamische Vorgänge wie Warenkorbänderungen und Zahlungsanfragen. Eine einfache Erreichbarkeitsüberwachung kann einen störungsfreien Betrieb melden, obwohl diese Vorgänge scheitern.

Stellen Sie sich eine Checkout-Seite vor, die HTTP 200 OK zurückgibt, den Statuscode für eine erfolgreiche Webanfrage. Anschließend überschreitet die Anfrage zur Versandkostenberechnung ihr Zeitlimit, sodass der Kunde nicht fortfahren kann. Die Seite ist erreichbar, aber der Kaufprozess ist unterbrochen.

Fehler können entlang des gesamten Kaufprozesses auftreten:

• Katalog und Produktsuche: Langsame Produktabfragen, aufwendige Filter und Zeitüberschreitungen bei der Suche verhindern die Produktauswahl.
• Warenkorb und Aktionen: Gleichzeitige Änderungen blockieren Warenkörbe, während Gutscheinregeln wiederholt die Gesamtsumme neu berechnen.
• Checkout und Zahlung: Steuerberechnungen, Versandkostenabfragen oder Zahlungsanfragen überschreiten ihre Zeitlimits.
• Lagerbestand: Gleichzeitige Käufe konkurrieren um die Reservierung desselben Restbestands.
• Bestellverarbeitung: In Warteschlangen sammeln sich Aufgaben an. Das verzögert die Bestätigung oder die Übergabe an Systeme, die Bestellungen abwickeln.

Für das Unternehmen bedeuten diese Fehler, dass bereits bezahlte Maßnahmen zur Besuchergewinnung nicht zum Kauf führen können. Deshalb bewerten wir die Einsatzbereitschaft anhand abgeschlossener Geschäftstransaktionen, einschließlich eines gültigen Zahlungsstatus und einer dauerhaft gespeicherten Bestellung.

Technische Risiken in Shop-Frontend, Checkout und Integrationen erfassen

Beginnen Sie mit einer Übersicht der Abhängigkeiten. Sie zeigt, was jeder Kaufschritt benötigt, wer die jeweiligen Dienste betreibt und ob deren Ausfall eine Bestellung verhindert. Dadurch werden Tests und Monitoring gezielter. Die Übersicht zeigt auch, wo Ihr Team ein Problem direkt beheben kann und wo eine Vereinbarung mit dem Anbieter oder eine Ersatzlösung nötig ist.

Berücksichtigen Sie die Dienste hinter dem sichtbaren Shop-Frontend:

• DNS, das Besucher zum Shop leitet, sowie das Content Delivery Network (CDN) und Sicherheitsdienste am Netzwerkrand.
• Hosting-Regionen, Load Balancer und Dienste für die Kundenanmeldung.
• Zahlungsgateways, Betrugsprüfungen, Steuerberechnungen und APIs zur Versandkostenberechnung.
• Systeme für Enterprise Resource Planning (ERP), Auftragsmanagement (OMS) und Lagerverwaltung (WMS).
• Drittanbieter-Skripte für Analysen, Bewertungen, Chat und Personalisierung.

Kennzeichnen Sie jede Abhängigkeit als kaufkritisch oder nicht kritisch. Ein ausgefallenes Bewertungs-Widget sollte sich deaktivieren lassen, ohne den Checkout zu beeinträchtigen. Für einen Dienst zur Versandkostenberechnung braucht es eine freigegebene Ersatzlösung, wenn sein Ausfall jede Bestellung verhindern würde.

Hosted/SaaS und individuelle Plattformen: Wer kontrolliert was?

Die Plattform bestimmt, welche technischen Eingriffe möglich sind. Bei gehosteten SaaS-Plattformen wie Shopify oder BigCommerce betreibt der Anbieter die zentrale Infrastruktur. Bei selbst gehosteten Plattformen tragen Händler und ihre technischen Partner mehr Verantwortung.

Für Shopify-Händler sieht die BFCM-Checkliste von Shopify unter anderem vor, Ladegeschwindigkeit, Checkout und Rabatte vor einem Besucheransturm zu prüfen. Diese Prüfungen helfen, Aufgaben im Einflussbereich des Händlers zu erkennen. Sie bedeuten nicht, dass Händler der zentralen Shopify-Plattform zusätzliche Server hinzufügen sollten.

Ein selbst gehosteter WooCommerce-Shop benötigt möglicherweise Datenbankoptimierungen und einen Objekt-Cache wie Redis, der wiederverwendbare Anwendungsdaten speichert. Bei einem Headless-Shop kommen getrennt betriebene Frontend- und API-Komponenten hinzu. Seine GraphQL-Antworten können Daten mit unterschiedlichen Aktualitätsanforderungen kombinieren. Deshalb braucht das Caching klare Regeln für gemeinsam genutzte Katalogdaten und kundenspezifische Informationen.

Einen Lasttest im E-Commerce an realistischen Kaufabläufen ausrichten

Ein Lasttest im E-Commerce sollte das Einkaufsverhalten bei der Last nachbilden, die Ihre Kampagnen erwarten lassen. Nutzen Sie eine produktionsnahe Infrastruktur und synthetische Daten, um Ausgangswerte zu ermitteln, Engpässe aufzudecken und die Erholung nach Belastung zu prüfen. Der Test muss neben Antwortzeiten auch die Ergebnisse der Kaufvorgänge überprüfen.

Bilden Sie einen vollständigen Kaufablauf als Testskript ab:

1. Ein Produkt oder eine Kategorie auswählen.
2. Suchen und Filter anwenden.
3. Produkte in den Warenkorb legen.
4. Einen Gutschein anwenden und die Gesamtsumme prüfen.
5. Den Checkout über einen isolierten Testablauf für Zahlungen abschließen.
6. Bestätigung, Bestandsverhalten und Bestellübergabe prüfen.

Mischen Sie diese Abläufe mit Sitzungen, in denen Besucher nur stöbern. Wenn jeder simulierte Besucher den Checkout durchläuft, entsteht eine andere Last als in einem typischen Shop.

Die Anleitung von Grafana k6 zum Testen von Websites unterscheidet browserbasierte Frontend-Prüfungen von protokollbasierten Backend-Tests. Protokolltests erzeugen effizient gleichzeitige Anfragen. Browsertests prüfen Rendering und Interaktionen, während ein hybrider Ansatz beide kombiniert.

Lastspitzen modellieren, ohne Anfragen, Sitzungen und Nutzer zu verwechseln

Nutzen Sie Logs und Analysedaten aus den Spitzenstunden der letzten Saison als Ausgangspunkt. Passen Sie das Modell an den diesjährigen Kampagnenplan und erwartete Änderungen im Einkaufsverhalten an. Ein Newsletter-Versand oder eine zeitlich begrenzte Aktion kann einen stärkeren kurzfristigen Besucheransturm auslösen, als die tägliche Gesamtzahl vermuten lässt.

Wie stark sich Bestellungen auf einzelne Tage und Stunden konzentrieren können, zeigt die Bilanz von OTTO zu den Black-Friday-Aktionstagen 2025: Am Black Friday, dem 28. November 2025, lagen die Bestellwerte um 10 Prozent über dem Vorjahr, das höchste Bestellaufkommen verzeichnete die Plattform gegen 21:30 Uhr. Für das eigene Lastmodell heißt das: Spitzen können auch am späten Abend auftreten und sollten aus den eigenen Shopdaten abgeleitet werden.

• Anfragen pro Sekunde (RPS) messen das Anfragevolumen über die Zeit. Erfassen Sie es getrennt nach kritischem Endpunkt.
• Sitzungen stehen für Besuche im Shop. Eine Sitzung kann viele Anfragen erzeugen.
• Gleichzeitige Nutzer bezeichnet die Nutzer, die zur selben Zeit aktiv sind. Sitzungsdauer und Pausen zwischen Aktionen beeinflussen diese Zahl.

Ein Ziel wie "10.000 Nutzer" ist ohne Angaben zu Ankunftszeiten und Verhalten unvollständig. Definieren Sie Pausen beim Stöbern, Warenkorbgrößen und Gutscheinnutzung. Bilden Sie ein realistisches Cache-Verhalten ab, statt wiederholt dasselbe bereits zwischengespeicherte Produkt abzufragen.

Der Checkout kann weniger Anfragen als das Stöbern verursachen, aber pro Anfrage mehr Arbeit erfordern. Gewichten Sie die Szenarien anhand des beobachteten Verhaltens. Ergänzen Sie gezielte Tests der Checkout-Performance für Abläufe mit vielen Rabattaktionen und kritischen Bestandsreservierungen.

Tests nach der zu unterstützenden Entscheidung auswählen

• Lasttest: Lassen sich kritische Kaufabläufe bei der erwarteten Spitzenlast innerhalb der vereinbarten Grenzen abschließen?
• Lastspitzentest: Kann der Shop einen plötzlichen, aktionsbedingten Ansturm bewältigen, bevor Skalierung oder Warteschlangenverarbeitung nachziehen?
• Stresstest: Wo ist die Kapazität erschöpft, und bleiben Bestellungen auch im Fehlerfall korrekt?
• Dauertest: Erschöpft anhaltender Traffic nach und nach Arbeitsspeicher, Verbindungen oder Warteschlangenkapazität?

Die Unterscheidung zwischen Lasttest und Stresstest ist für die Freigabeentscheidung wichtig. Die erwartete Spitzenlast muss bewältigt werden. Ein Stresstest geht bewusst darüber hinaus, um die Belastungsgrenze und das Verhalten bei der Wiederherstellung aufzuzeigen.

Vor dem Test sichere Grenzen festlegen

Eine produktionsnahe Umgebung macht Ergebnisse aussagekräftig. Ihre Unterschiede zur Produktionsumgebung müssen jedoch dokumentiert werden. Die AWS-Anleitung zur Planung von Lasttests betont die Nähe zur Produktionsumgebung und die Grenzen der Lastgeneratoren. Eine kleine Staging-Datenbank oder ein überlasteter Lastgenerator kann zu irreführenden Schlussfolgerungen führen.

• Nutzen Sie synthetische Kunden sowie isolierte Produkt-, Bestands- und Gutscheindatensätze mit realistischen Dateneigenschaften.
• Verwenden Sie Zahlungs-Sandboxes oder Mocks. Leiten Sie Bestellexporte an Testziele weiter, niemals in produktive ERP- oder OMS-Abläufe.
• Stimmen Sie Traffic-Volumen und Testfenster mit Plattformanbietern und externen Dienstleistern ab.
• Legen Sie Abbruchkriterien für Fehler, erschöpfte Ressourcen und unerwartete Auswirkungen auf gemeinsam genutzte Dienste fest.
• Überwachen Sie während des gesamten Testlaufs die Anwendung und die Lastgeneratoren.

Tests in der Produktionsumgebung erfordern eine ausdrückliche Freigabe und einen eng begrenzten Umfang. Wenn ein Anbieter keine Lasttests erlaubt, simulieren Sie seine dokumentierten Limits, Verzögerungen und Fehlerantworten. Damit prüfen Sie das Verhalten Ihrer Integration, ohne die tatsächliche Spitzenkapazität des Anbieters nachzuweisen.

Welche Einkaufsszenarien Sie vor der Lastspitze prüfen sollten

Prüfen Sie in Lasttests vollständige Kaufabläufe und die Übergabe an externe Systeme, nicht nur die Erreichbarkeit des Shop-Frontends. Die folgenden Szenarien zeigen geeignete Messgrößen und mögliche Probleme. Es handelt sich nicht um Ergebnisse aus Webdelo-Kundenprojekten.

Legen Sie die Grenzwerte für jede Messgröße vor dem Test anhand der Shop-Architektur, des erwarteten Traffics und der Geschäftsanforderungen fest. Dokumentieren Sie tatsächliche Ergebnisse, erkannte Risiken und Korrekturmaßnahmen separat.

Lasttest-Ergebnisse und Core Web Vitals: Belastbarkeit und Ladezeit messen

Lasttests zeigen, ob Transaktionen bei gleichzeitigen Zugriffen gelingen. Core Web Vitals beschreiben Ladeverhalten, Reaktionsfähigkeit und visuelle Stabilität im Browser. Ein gut nutzbarer Shop braucht sowohl ein reaktionsschnelles Kundenerlebnis als auch eine zuverlässige Verarbeitung im Hintergrund.

Google definiert die Core Web Vitals als Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Sie beschreiben, wann der Hauptinhalt erscheint, wie schnell Interaktionen eine sichtbare Reaktion auslösen und wie stark sich Seiteninhalte unerwartet verschieben.

Die p95-Latenz ist die Antwortzeit, innerhalb derer 95 % der gemessenen Anfragen abgeschlossen werden. Die p99-Latenz macht die besonders langsamen Antworten sichtbar. Prüfen Sie beide Werte für jeden kritischen Vorgang, statt Suche und Checkout gemeinsam zu mitteln.

Vereinbaren Sie vor den Tests Grenzwerte für Transaktionen und Latenzen. Definieren Sie, was als gültiger Kaufversuch gilt, und unterscheiden Sie erwartete Zahlungsablehnungen von technischen Fehlern. Prüfen Sie bei asynchronen Bestellexporten neben dem Checkout-Abschluss auch die spätere erfolgreiche Übermittlung und den Abbau der Warteschlange.

PageSpeed Insights kann neben Labordiagnosen auch Felddaten enthalten, simuliert aber keine gleichzeitigen Käufer. Verfolgen Sie das mobile Nutzererlebnis bei steigendem Traffic, insbesondere wenn Drittanbieter-Skripte um Rechenzeit im Browser konkurrieren.

Onlineshop-Performance optimieren: Engpässe gezielt beseitigen

Priorisieren Sie technische Verbesserungen nach ihren Auswirkungen auf den Kaufprozess und der zugrunde liegenden Ursache. Vergleichen Sie langsame Vorgänge bei normalem Traffic und Spitzenlast, setzen Sie eine gezielte Änderung um und wiederholen Sie dasselbe Szenario. Zusätzliche Kapazität hilft, wenn Kapazität der Engpass ist. Sie behebt aber weder eine fehlerhafte Bestellverarbeitung noch eine blockierende externe Abhängigkeit.

Bevor Sie größere Server buchen, sollten Sie den Engpass finden. Eine langsame Abfrage kann auf jeder Replik mehr Ressourcen verbrauchen. Ein Timeout bei der Zahlung kann unverändert bleiben, unabhängig davon, wie viel zusätzliche Kapazität das Shop-Frontend erhält.

Bewerten Sie Endpunkte sowohl nach ihrer gesamten Verarbeitungszeit als auch nach der Latenz einzelner Anfragen. Häufig aufgerufene Vorgänge können den Ressourcenverbrauch dominieren, selbst wenn jede einzelne Anfrage unauffällig wirkt. Andere Vorgänge werden erst langsam, wenn gleichzeitige Anfragen um dieselben Daten konkurrieren.

Verbesserungen über den gesamten Stack priorisieren

• Backend und Daten: Optimieren Sie SQL-Abfragen und Indizes, reduzieren Sie wiederholte Abfragen, cachen Sie wiederverwendbare Daten und prüfen Sie die Einstellungen der Verbindungspools.
• Shop-Frontend: Reduzieren Sie unnötige Skripte und Tags, optimieren Sie Bilder und cachen Sie geeignete Kataloginhalte im CDN.
• Integrationen: Setzen Sie Timeouts, kontrollierte Wiederholungsversuche und freigegebene Ersatzlösungen ein. Verschieben Sie Aufgaben in Warteschlangen, wenn sie den Checkout nicht blockieren müssen.
• Kapazität: Passen Sie die Anzahl der Worker oder die automatische Skalierung (Auto Scaling) an, nachdem Sie die Limits nachgelagerter Datenbanken und Anbieter geprüft haben.
• Bedienbarkeit im Checkout: Erhalten Sie eingegebene Daten nach Fehlern und erklären Sie ausstehende Zahlungszustände verständlich.
• Architektur: Entkoppeln Sie eng verbundene Vorgänge, wenn gezielte Änderungen den Engpass nicht beseitigen können.

Speichern Sie kundenspezifische Warenkörbe und Checkout-Antworten nicht in gemeinsam genutzten öffentlichen Caches. Sichern Sie wiederholbare Bestellvorgänge durch Idempotenz ab: Die Wiederholung derselben Anfrage darf weder eine weitere Bestellung noch eine weitere Abbuchung auslösen.

Jede Diagnose mit einer Korrektur und einer erneuten Prüfung verbinden

Schließen Sie eine Korrektur erst ab, wenn dasselbe Szenario bei gleicher Last mit korrekten Geschäftsergebnissen besteht. Testen Sie auch benachbarte Schritte erneut: Ein schnellerer Checkout kann einen zuvor verborgenen Engpass in der Bestellverarbeitung offenlegen.

Öffentliches Beispiel: Wie Shopify sich auf BFCM 2025 vorbereitet hat

Shopify Engineering hat sein Vorbereitungsprogramm für BFCM 2025 öffentlich beschrieben. Über das Jahr hinweg simulierte das Team in Übungen 150 Prozent der BFCM-Last des Vorjahres. Von April bis Oktober liefen zusätzlich fünf große Skalierungstests auf dem prognostizierten Traffic-Niveau.

Die Tests deckten unter anderem zu wenige Kafka-Partitionen in Datenpipelines und einen zu hohen Speicherverbrauch in der API-Schicht auf. Außerdem mussten Verbindungs-Timeouts angepasst werden, damit Verbindungspools nicht erschöpft werden. Das Team behob diese Engpässe und prüfte die Änderungen in den folgenden Tests erneut. Dieselbe Abfolge gilt für Shops jeder Größe: Test, technische Verbesserungen, erneute Prüfung.

Website-Monitoring mit sicheren Deployments verbinden

Während BFCM muss das Monitoring Fehler sichtbar machen, die Kunden betreffen. Es muss einer benannten verantwortlichen Person genügend Informationen zum Handeln liefern. Kombinieren Sie synthetische Prüfungen der Kaufabläufe mit Real User Monitoring und Backend-Telemetrie aus dem Application Performance Monitoring. Begrenzen Sie unnötige Änderungen, damit das getestete System weiterhin dem Live-Shop entspricht.

Synthetische Prüfungen führen skriptgesteuerte Interaktionen nach einem Zeitplan aus. Real User Monitoring erfasst das tatsächliche Besuchererlebnis. Konfigurieren Sie Checkout-Prüfungen so, dass keine echten Zahlungen oder Aufträge zur Bestellabwicklung entstehen.

• Vor dem Änderungsstopp: Schließen Sie kritische Korrekturen, erneute Tests und eine Rollback-Probe ab.
• Während des Änderungsstopps: Beschränken Sie nicht notwendige Code- und Konfigurationsänderungen, einschließlich Apps, Tags und Checkout-Erweiterungen.
• Bei dringenden Änderungen: Nutzen Sie einen vereinbarten Freigabeprozess, ein festgelegtes Rollback-Kriterium und eine benannte entscheidungsverantwortliche Person.
• Bei Störungen: Leiten Sie Alarme nach ihren Auswirkungen auf den Kaufprozess weiter und nutzen Sie dokumentierte Eskalationswege.
• Für den eingeschränkten Betrieb: Bereiten Sie sichere Maßnahmen vor, etwa das Deaktivieren eines nicht kritischen Widgets.

Prüfen Sie, ob die Maßnahmen aus den Störungen der letzten Saison umgesetzt wurden. Halten Sie den Bereitschaftsplan aktuell und stimmen Sie vereinbarte Reaktionszeiten und Eskalationswege auf den vereinbarten Umfang, die Betreuungszeiten und die Zuständigkeiten der Anbieter ab.

Black-Friday-Checkliste für Onlineshops: Go/No-Go und Kapazitätsplanung

Geben Sie den Shop für die Spitzenlast frei, wenn kritische Kaufabläufe bei erwartetem Traffic die vereinbarten Grenzwerte einhalten und Wiederherstellungsmaßnahmen getestet sind. Ein ungelöster Fehler bei der Zahlung oder Bestandsreservierung verhindert die Freigabe. Eine nicht kritische Funktion kann als dokumentiertes Risiko bestehen bleiben, wenn ihr Ausfall keine Käufe behindert.

• Abhängigkeiten: Für kaufkritische Dienste sind Verantwortliche und ein freigegebenes Verhalten im Fehlerfall festgelegt.
• Lastmodell: Traffic-Volumen, zeitlicher Besucherzulauf und Verteilung der Kaufabläufe entsprechen den Kampagnenerwartungen.
• Testnachweise: Lasttests und Lastspitzentests bestehen. Stresstests zeigen nachvollziehbare Ausfall- und Wiederherstellungsgrenzen auf.
• Korrekte Bestellungen: Gültige Testkäufe erzeugen die erwarteten Zahlungs-, Bestands- und Bestellzustände.
• Performance: p95/p99-Latenz, technische Fehler und Durchsatz halten die vereinbarten Grenzen ein.
• Ressourcen: Datenbanken, Caches und Warteschlangen verfügen über gemessene Reserven und erholen sich nach dem Ansturm.
• Integrationen: Anbieterlimits sind dokumentiert, und das Verhalten bei einem Anbieterausfall ist getestet.
• Mobiles Nutzererlebnis: Kritische Interaktionen bleiben bei aktivierten vorgesehenen Skripten nutzbar.
• Betrieb: Alarmierung, Rollback-Verfahren und Eskalation an den Bereitschaftsdienst wurden erprobt.

Dokumentieren Sie die Entscheidung mit offenen Risiken, Verantwortlichen und Bedingungen für eine erneute Bewertung. Eine bekannte Belastungsgrenze oberhalb der erwarteten Spitze kann die Kapazitätsplanung unterstützen. Scheitert ein kritischer Kaufablauf bereits bei erwarteter Spitzenlast, braucht es vor der Freigabe eine Korrektur oder eine getestete Ersatzlösung.

Wann wiederkehrende Engpässe eine Plattformmodernisierung erfordern

Wiederkehrende Fehler in denselben Kaufschritten deuten auf eine strukturelle Begrenzung hin. Entscheiden Sie anhand von Test- und Störungsdaten, ob gezieltes Refactoring genügt oder eine umfassendere Modernisierung gerechtfertigt ist. Planen Sie diese Arbeiten außerhalb des eingeschränkten Änderungsfensters rund um die Spitzenlast.

Folgende Anzeichen sollten Sie untersuchen:

• Kapazitätserweiterungen verschieben wiederholt denselben Engpass.
• Synchrone ERP- oder OMS-Aufrufe machen den Checkout von der Verfügbarkeit der Backoffice-Systeme abhängig.
• Checkout-Änderungen lassen sich nur schwer isolieren, testen oder zurücknehmen.
• Grenzen einer gehosteten Plattform verhindern notwendige Geschäftslogik.
• Bei einem individuellen Stack fehlen klare Zuständigkeiten oder ein verlässlicher Prozess zur Skalierung.

Die Möglichkeiten reichen vom Refactoring aufwendiger Vorgänge bis zur Umstellung von Integrationen auf Warteschlangen und Ereignisse. Ein Plattformwechsel oder ein Headless-Frontend kann sinnvoll sein, bringt aber jeweils eigene Betriebsaufgaben mit sich. Wählen Sie die kleinste Änderung, die die dokumentierte Begrenzung beseitigt und die Produktroadmap unterstützt.

Planen Sie Budget für fortlaufende Prüfungen nach dem Start ein. Ein Verständnis für Leistungsumfang und Kosten der Website-Wartung hilft, laufende Pflege von den technischen Investitionen zu trennen, die Architektur und Checkout-Zuverlässigkeit verbessern.

Einsatzbereitschaft anhand technischer Nachweise beurteilen

Ein Shop ist für die Lastspitze bereit, wenn der gesamte Kaufprozess bei erwarteter Last funktioniert, Bestellungen korrekt verarbeitet werden und der Shop auch mobil gut bedienbar bleibt.

Stützen Sie die Freigabe auf realistische Tests, nachweislich wirksame Korrekturen und erprobte Wiederherstellungsverfahren. Engpässe, die jede Saison wiederkehren, gehören in den nächsten Entwicklungszyklus statt in eine weitere Runde kurzfristiger Notlösungen.

Mit Webdelo E-Commerce-Plattformen entwickeln und optimieren

Webdelo entwickelt, modernisiert und optimiert E-Commerce-Plattformen über den gesamten Produktlebenszyklus. Der Umfang kann die Performance des Shop-Frontends, die Zuverlässigkeit des Checkouts, Architektur, Integrationen und laufende Verbesserungen umfassen. Lasttests unterstützen diese Arbeit als diagnostische Methode.

Bei gehosteten Shops konzentrieren sich die technischen Arbeiten auf Komponenten im Einflussbereich des Händlers und angebundene Dienste. Individuell entwickelte und selbst gehostete Plattformen benötigen möglicherweise auch Änderungen an Datenbank, Infrastruktur und Deployment. Die Prioritäten hängen von den Risiken im Kaufprozess, den Geschäftsanforderungen und den verfügbaren Eingriffsmöglichkeiten ab.

Bringen Sie Informationen zu Ihrer Plattform, Ihren kritischen Schnittstellen und dem erwarteten Spitzen-Traffic mit, damit sich der Umfang der Arbeiten an Ihrem Unternehmen ausrichten lässt. Sprechen Sie mit Webdelo über die Optimierung Ihres bestehenden Shops oder die Entwicklung eines Online-Shops.