Wichtigste Erkenntnisse
- Ein Sticky Add to Cart-Balken sorgt dafür, dass Produkttitel, Preis, Variantenauswahl und On-Page Buy Button sichtbar bleiben, während der Käufer auf einer langen Produktseite (PDP) nach unten scrollt – auf Mobile meist in Form einer Bottom Bar.
- Er reduziert Abbrüche und Reibungsverluste (Friction) auf langen PDPs. Der Kaufen-Button ist immer nur einen Tap entfernt, sodass User für den Kauf nie wieder komplett nach oben scrollen müssen.
- Der native Aufbau besteht aus einem CSS
position:stickyoderfixedBalken, einem IntersectionObserver, der ihn einblendet, sobald der Haupt-Button aus dem Blickfeld gerät, sowie einem kurzen Skript zum Synchronisieren von Preis und Variante.- Richtig umgesetzt kostet das kaum bis kein Page Weight (Ladezeit). Wer es stattdessen über eine schwere App löst, fängt sich schnell unnötiges JavaScript und ärgerlichen Layout Shift ein.
- Fudge generiert den Balken als nativen Theme-Code – also kein unpassendes Widget, voll im Brand-Design und er bleibt auch nach einer Deinstallation des Tools erhalten.
Ein Sticky Add to Cart-Balken ist eine der wirkungsvollsten Anpassungen, die du auf einer Shopify-Produktseite vornehmen kannst. Auf einer langen PDP (Produktdetailseite) voller Bewertungen, Spezifikationen und Lifestyle-Bilder scrollt der Haupt-Kaufen-Button ziemlich schnell aus dem sichtbaren Bereich. Eine Sticky Bar hält ihn deshalb die ganze Zeit griffbereit.
Dieser Guide zeigt dir auf, worum es sich bei diesem Pattern genau handelt, warum es aus CRO-Sicht Sinn ergibt, welche zwei Hauptvarianten es gibt, wie du es komplett nativ in einem Theme aufbaust und auf welche Accessibility- und Performance-Aspekte du achten musst, um einen richtig guten und keinen rein nervigen Balken zu bauen.
Warum du uns vertrauen kannst
Jacques bringt über 15 Jahre Erfahrung in der Entwicklung mit und hat dieses spezifische Produktseiten-Pattern bereits für Hunderte Shopify Stores umgesetzt. Wir bei Fudge arbeiten selbst an einem KI-Storefront-Editor, der mit 5.0 Sternen im Shopify App Store bewertet ist (siehe Fudge). Das heißt: Wir arbeiten exakt in jenem Theme-Layer, in dem sich auch solch ein Sticky-Balken tummelt – und wissen sehr genau aus der Praxis, was alles schiefgeht, wenn man es unsauber umsetzt.
Was ist ein Sticky Add to Cart-Balken?
Ein Sticky Add to Cart-Balken ist eine schmale Fixierung (Leiste), die durchgängig am Rand des Viewports „kleben“ bleibt, während der Rest der Seite weiter nach oben und unten scrollt. Dabei greift diese Leiste im Vorbeiziehen auf die wichtigsten Elemente aus der primären Buy Box zurück: Produkttitel, aktueller Preis, Variantenauswahl, Menge und den Add to Cart-Button.
Auf Desktops sitzt der Balken meistens oben. Bei Mobile Devices wiederum am unteren Bildschirmrand, genau in passender (und somit komfortabler) Daumenreichweite.
Der Grundgedanke ist absolut simpel: Der anfängliche Haupt-Add to Cart-Button ist nur im oberen Layout-Teil der Produktdetailseite sichtbar. Alles, was darunter folgt – Textbeschreibungen, Größentabellen, Reviews, Infos zum Versand, ähnliche Produkte – drängt den Kaufen-Button schon bald komplett vom Bildschirm. Ohne einen Sticky-Balken müsste ein Shopper, der die Seite bis zum Fuß abscrollt und sich erst dann zum Kauf entschließt, extra komplett wieder nach oben scrollen. Dieses Hochscrollen ist das Paradebeispiel für „Friction“, und Friction kostet dich Conversions.
Der CRO-Aspekt
Die Logik beim CRO (Conversion Rate Optimization) beruht hier hauptsächlich darauf, Käufern im exakten Moment der echten Kaufentscheidung hinderliche Schritte aus dem Weg zu räumen. Eine tatsächliche Kaufentscheidung wird sehr oft erst dann getroffen, wenn der Besucher weiter unten auf der PDP Detailinformationen liest. Die Sticky Bar ermöglicht hierbei einen absoluten Direktzugriff ohne das abrupte, verzweifelte Suchen eines Buttons.
Dieser Effekt entfaltet die mit Abstand größte Wirkung, wenn die Detailseiten verhältnismäßig lang sind und ohnehin fast der gesamte Shop-Traffic übers Smartphone reinkommt (was für den absoluten Großteil der Shopify Stores gilt). Auf kleinen mobilen Endgeräten (Mobile Devices) verschwindet dieser Hauptbutton im Grunde bereits nach einem kleinen Swipe – bei einem solchen Szenario hat ein beständiger Bottom-Balken also massiven Einfluss.
Ein Sticky-Balken ist natürlich nur ein Puzzlestück innerhalb einer übergreifenden Produktseiten-Strategie. Das größere, ganzheitliche Bild findest du in unserem Shopify CRO Guide. Wie du den hierfür nötigen Layout-Rahmen baust, erfährst du zudem hier: Wie man eine Shopify-Produktdetailseite anpasst.
Die zwei Varianten: Top Bar vs. Mobile Bottom Bar
In der Praxis gibt es zwei bewährte Positionierungen, und die meisten Stores haben beide aus ein und demselben Code heraus direkt gemeinsam platziert.
1. Desktop Top Sticky Bar. Eine schmale (slim) Bar, die fest an das Top-Level-Window geheftet wird. Dargestellt werden in der Regel ein Produkt-Thumbnail, Titel, Preis, ein ziemlich verschlanktes Varianten-Dropdown und am rechten Rand ein übersichtlicher Add to Cart-Button. Ersichtlich wird der Balken genau in jenem Moment, in dem die ursprüngliche Buy Box außer Sicht gerät.
2. Mobile Bottom Bar. Ein Balken, der fast immer über die volle Breite fix am unteren Rand des Bildschirm-Elements sitzt, genau oberhalb der Daumen-„Griffzone“. Platz auf mobilen Telefonen ist stark limitiert (Tight Screen Space), aber das natürliche Greifen konzentriert sich unten am Rand. Allein deswegen konvertiert eine Bottom Bar in diesen Fällen deutlich besser. Der Varianten-Picker wird hier oft auf ein simples Select oder ein „Tap-to-expand“-Verhalten reduziert, das nur per Klick ein kleines Overlay aufruft.
Die Grundinhalte sind völlig identisch; nur die Platzierung auf dem Raster (Density) verschieben sich bei unterschiedlichen Breakpoints. Halte den Balken ohnehin immer sehr dünn. Er darf bei einer Live-Ausspielung den eigentlichen Page-Content zu keiner Zeit massiv verdecken.
Wie man ein Sticky Add to Cart nativ ins Theme einbaut
Du brauchst für solch ein Element wahrlich absolut gar keine App. Der native Code besteht grob nur aus den folgenden drei Bestandteilen: Das Sticky-Element, der Show/Hide-Trigger und das Varianten-Syncen.
1. Das Sticky-Element
Damit der Balken dem Shopper die komplette Seite nach unten (und oben) verlässlich im Sichtmaß (Viewport) hinterherzieht, nutze schlichtweg ein fixed- oder sticky-positioniertes Element. CSS position:sticky sorgt dafür, dass die Leiste basierend auf ihrem ursprünglichen Scroll-Container sofort am Screen gestanzt bleibt, sobald sie einen durch top oder bottom bestimmten Grenzwert (Threshold) erreicht. Genial dabei: Diese Action passiert vollständig über den eigenen Browser Compositor und stützt sich null auf JavaScript.1 Für solch einen Balken, der aber gar nicht die Sektion, sondern die ganzheitliche View abdecken muss – sich also außerhalb von Section-Blöcken positionieren will – bleibt ein festes position:fixed weitestgehend die weitaus unkompliziertere Option. Ein Sticky kann leicht durch Elternelemente im Layout ausbrechen, oft verursacht durch einen unbewussten overflow:hidden Container.
Das Markup in Liquid wäre ein einfacher Container. Er beherbergt die entscheidenden Kauf-Basics und ist standardmäßig erstmal verborgen (hidden):
<div class="sticky-atc" data-sticky-atc hidden>
<span class="sticky-atc__title">Produktname</span>
<span class="sticky-atc__price" data-sticky-price>49.00 €</span>
<!-- kompaktes variant select spiegelt den main-picker wider -->
<button type="submit" form="product-form-id">In den Warenkorb</button>
</div>
Achte bitte insbesondere auf das form-Attribut in der Button-Zeile. Eine simple Logik lässt ein Button-Action-Element auf externe Formen zurückgreifen (submit), selbst wenn dieses gar nicht im selbigen Code-Zweig geschachtelt wird, da es ja bereits eine eindeutige Identifier-Verlinkung via Form-id enthält. Das Formular kann also schlicht vom Theme selbst mit der bereits passenden Struktur weiter bedient werden. Es gibt gar keinen Zwang, den Button mit all den versteckten Infos umständlich im Code um die halbe HTML-Reise zu schleppen oder zu duplizieren.
2. Ein- und Ausblenden mit dem IntersectionObserver
Du möchtest den Code idealerweise exakt dann zuschlagen und laden (bzw. aufscheinen) lassen, wenn der „normale“, eigentliche CTA (Buy-Button) aus dem Bildschirm verschwunden ist. Am elegantesten und vor allem performantesten klappt das mit einem IntersectionObserver. Dieser überwacht ein vorab markiertes Target-Element und wartet auf sein bestimmtes Eintreten. Sobald das Target das Live-Bildfeld verlässt oder betritt, stößt er völlig frei den Callback auf und leitet ihn ab. Im extremen (und perfekten) Gegenbild zu einem stumpfen ScrollListener-Script rennt der IntersectionObserver abseits des Main Threads quasi still, unsichtbar und weitaus ressourcenschonender mit. Er schießt erst aktiv bei Kontaktierung der Grenze aus (statt unzähliger Dauer-Rechnungen bei jedem Zentimeter Swipe).2
Richte den Link direkt auf den Main Button aus, der als Kipp-Auslöser fungiert:
const mainButton = document.querySelector('[data-main-atc]');
const bar = document.querySelector('[data-sticky-atc]');
const observer = new IntersectionObserver(([entry]) => {
bar.hidden = entry.isIntersecting; // Bar verstecken, wenn der Main-Button im Viewport ist
}, { rootMargin: '0px' });
observer.observe(mainButton);
Ergebnis: Solange der eigentliche Kaufknopf unübersehbar mitten im Layout hängt, versteckt sich die Bar geduckt. Flattert der Kaufknopf beim Scrolldown aus dem Viewport nach oben (oder unten) raus, poppt die Bar unmissverständlich sichtbar auf. Das war’s. Genau das ist die gesamte Technik dahinter.
3. Variante und Preis synchron halten
Da der Sticky-Balken gewissermaßen die „verlängerte visuelle Werkbank“ eines bereits definierten Standard-Produktes ausspielen soll, muss seine Logik jederzeit zu 100 % passend auf die Live-Variante anspringen. Single Source of Truth dafür ist das zentrale Haupt-Produktformular.
Viele der „Online Store 2.0“-Themes im Shopify-Kosmos (z.B. Dawn und Konsorten) arbeiten glücklicherweise nahtlos mit Change Events – wann immer jemand eine Variante per Klick abändert, dispatched das Theme diesen Trigger glasklar durchs System, den du nur via Listener-Events fangen musst. Bei Trigger wird der Balken veranlasst, unverzüglich Price und verdeckten (Hidden) Varianten-Input-Wert (ID) passend zu ersetzen. Dadurch existieren nie widersprüchliche Outputs. Falls die Balken-Leiste am Seitenende noch eine kleine Dropdown Choice-Liste oder Vergleichbares verbirgt, verknüpfe dieses so, dass es blind beim Haupt-Form den Sync erzwingt (State Management im Picker, nicht separat).
4. In den Warenkorb (Add to Cart)
Du hast zwei verlässliche Optionen, Produkte von ebenjenem Bar-Knopf aus abzuleiten.
- Produktformular wiederverwenden. Setze den Checkout über das Button/Formular-Binding (das oben beschriebene
form-Attribut). Hierbei greift die Standard-Routine via Theme exakt dort rüber, inklusive aller Zusatzfunktionen wie das Ausklappen des Cart Drawers von der Seite. - POST / AJAX Cart. Sende hierfür einfach die via Picker identifizierte Varianten-ID zusammen mit der passenden Quantity zum fixierten Endpunkt
/cart/add.js. Die Routine verfrachtet den Job ab, schnappt dasitemsals Array und schmeißt entweder JSON Cart-Werte in das Frontend zurück, oder prangt (bei Overselling/Sold-Out Constraints) eine saure 422 Error Message (Restriktive Stocks) zurück aufs Handy.3 Daraufhin aktualisierst du noch fix den Counter oben in der Header-Leiste und triggerst danach manuell das Drawer-Menü auf.
Der sauberste Ansatz ist und bleibt der Weg über den Standard-Submit (Option 1). Du überlässt das Cart-Handling und das Aufstellen all jener bereits fertig implementierten Drawer, Toast-Pop-Up-Banner, Analytics-Event-Lauscher, Upsell-Ketten und Subscriptions dem Theme auf dem Rücken, so wie es immer vorgesehen war.
Accessibility: Erreichbar machen, nicht einsperren
Ein Sticky-Balken wird unweigerlich wie ein Layer über alle eigentlichen Text- und Inhaltsblöcke gestapelt. Daher ergeben sich logische Pflichten in Sachen Accessibility (Barrierefreiheit).
- Keinen Content verdecken. Sorge für Spacer/Padding-Blocks im unteren Footer, sodass zettelte Banner am Ende nicht gnadenlos Footer-Links, Cookie-Benachrichtigungen oder gar Text-Schlusssätze abdecken (oder verbergen). Gönne mobilen Usern stets einen sauberen Buffer (Bottom Padding), welcher dem Balken-Space entspricht.
- Fokus nie fangen (Trap Focus), via Tab zugänglich. Ein Screenreader (und Keypad) muss das Menü aus einer freien Focus Tab-Order sicher überspringen lassen. Fokussierte Objekte müssen auch flüssig aus der Bar herausgeschleust werden können und rein. Das Ding ist kein Modal Event Layer. Banne dort keine Fokus-Traps rein!
- Farbkontraste respektieren. Halte dich strikt an Kontrast-Benchmarks. Der Background muss zu Call to Actions und Texten ein hohes Kontrastverhältnis passend vor der Box stützen. Diese Theme-Regeln gelten dort nicht weniger als auf dem ganzen Dokument.
- Den Preis (Live-Region) kontrollieren. Beim Switchen und Anpassen eines Wertes ändern sich automatisch Live-Preise – lass diese bloß nicht jede Sekunde panisch im ARIA Live-Region-Broadcast über Screenreader knattern, bis es dem Kunden in den Ohren dröhnt. Der Standard-Visuelle Text ist zumeist absolut hinreichend.
- Reduced Motion respektieren. Wenn das gute Stück wie per Zauberhand in die Ansicht slidet, pack diesen Keyframe-Spaß hinter eine
prefers-reduced-motionRegel für all jene User mit sensitiven Präferenzen (Reduced Motion Check).
Performance: Günstig, wenn man es richtig macht
Die nativ integrierte Variante belastet deinen Server, Store und das Skript gar nicht. position:sticky und position:fixed greifen blind als Basic-Fundament. CSS kümmert sich darum via nativem Compositing (Hardware Layering / Browser). Und um das Abfangen des Listeners kümmert sich der IntersectionObserver so viel ressourcenschonender und moderner, dass er all die unendlich loopenden ScrollListener aus den alten Tagen alt aussehen lässt. Die Rechnung am Ende? Fünf, sechs Zeilen Code. Das ist nichts.
Ladezeit/Payload knallt rein, wenn du fertige Dritthersteller-Apps (Bloatware) zuschaltest. Diese pumpen ihre JavaScript-Bandbreite an jedem einzelnen Produkt ab. Die fettesten von ihnen crashen dich außerdem zusätzlich, weil sie – aufgrund einer Injected-Integration via Widget – stark verzögert spawnen. Dadurch produzieren sie unangenehme, verschlechternde Shifts (CLS Metrics), während das Layout ruckelt. Auf ohnehin überladenen Stores staut und verschärft sich das dramatisch, was sofort abwärts driftende Conversion-Wellen garantiert.
Hakt dein PDP (Product Layout) bereits? Fix das bitte zwingend vorher! Schau mal in diesen Artikel zu dem Thema rein: Wie du ein Shopify Theme schneller machst. Das ist absolut basic, bevor du auch nur ansatzweise irgendetwas ins Boot packst.
Wann du einen Sticky Add to Cart NICHT nutzen solltest
Sticky Bars sind kein Wundermittel für wirklich jedes einzelne Layout. Checke stets vorher sehr gut ab, ob das Pattern passt:
- Sehr kurzes PDP-Format. Sitzt der reguläre Buy Button eh zu 90 % der Zeit glasklar im Blickfenster des Users, produzierst du mit dem Bar-Klon einfach nur unnötiges „Clutter“-Echtzeit-Gewimmel ohne Mehrwert.
- Mangel an Screen Space. Bist du ohnehin auf sehr sehr kleinen Mobile-Phone-Displays unterwegs? Du zimmerst dir dort schnell viel Freiraum-Kapazität endgültig weg. Bau das Teil dünn oder lass es andernfalls ganz bleiben.
- Dein Produkt hat knifflige Abhängigkeiten (Configuration). Made-to-order-Artikel oder extrem kunden-konfigurierbare Unikate (z.B. Gravuren, Pflicht-Checkboxes, Uploads)? Da brauchst du im Vorfeld erst Zwangshandlungen, Pflichtwahlen, Texte. Wenn du da mit einem „1-Tap-Button“-Konstrukt am unteren Rand um die Ecke kommst, fressen die Kunden sofort Fehlermeldungen, Checkpoint-Stornierungen (Bouncing) und ärgerliches Loop-Scrolling im Checkout.
- Clash der Titanen (Fixes über Fixes). Chatbot-Bubbles, Cookie-Law-Banner und noch ein paar Sales Floaties? Eine UI Wall Of Horror baut sich dort schnell auf. Werf erst einmal Ballast von Bord, bevor du das Ganze an eine Wand aus Sticky-Buttons ranfährst.
App vs. Nativ: Der Trade-off
Mit Hilfe von App-Providern klickst du dir eine Sticky Bar nach Anmeldung direkt zackig auf den Shop, was nicht-technischen Gründern absolut den schnellsten Rollout pusht. Aber der klassische Widget-Kompromiss beißt sofort brutal mit zu: Du leistest Abo-Boni (Monthly Fee), frisst zwingenden JavaScript-Code, dealst oft mit unschön fehl-brandendem Style – und der Dependency-Bug fängt dich sofort ab: Wird das Abo gekickt, löst sich sofort diese Bar ab.
Das Native-Code-Einpflanzen killt dir auf einen Schlag diese vier Feinde (Dependencies / Fees). Du opferst „nur“ dafür deine Zeit, dir das Liquid-Script sauber, Accessible und komplett in the Zone zu programmieren. Exakt in dieser Brücke helfen kluge Native-Tools rein.
Wie Fudge ins Spiel kommt
Fudge ist ein KI-gestützter Storefront Editor, der für dich echten nativen Theme-Code spinnt. Alles, was du beisteuern musst: Beschreib die Featureschnipsel präzise. Beispiel: “Mach mir ‘ne Sticky Add to Cart Bar auf meinen Product-Pages, wenn der Standard-Kaufen-Button weggescrollt wird. Bitte mit Bottom Bar-Ansicht für Handys – und halt Varianten und Preise immer komplett synchron.” Fudge greift rüber und tippt exakt diese Liquid-, CSS- und JS-Architekturen pur ins Theme deiner Wahl.
Dadurch, dass der pure Payload nativ gedrückt wurde, entfällt der Bedarf eines Third-Party Widgets über deiner Seite vollkommen. Bye bye JavaScript App-Bloat-Laden für nichts und wieder nichts. Tschüss nervige laufende Abos für banale 6 Zeilen JavaScript. Der Storefront liest die Integration exakt, wie es ein Coder in die Maske reingewedelt hätte, organisch als ein Stück Design.
Der Königsvorteil als Theme Code-Stück: Es überlebt jeden Uninstall. Willst du Fudge je verlassen, tangiert das gar nix: Dein Sticky-Balken thront eisern im Shopify-Code, ganz das Gegenteil diverser Plugins, welche jegliche CSS und Skripte beim Auszug mit abräumen (bzw. auf tot schalten). Dasselbe Prinzip greift bei allen Bausteinen, die du mit dem Shopify Store Editor oder dem Fudge Page Builder hinzauberst.
Falls du so ein Quick-Buy-Pattern auch auf Collections-Pages im Feed umsetzen willst, ist das Thema Shopify Quick View Modal übrigens der ideale Folgeschritt. Damit fangen Käufer die Additions gleich ein, ohne je voll aufs detaillierte PDP runterdriften zu müssen.
FAQ
Am meisten hilft es auf langen Produktseiten und auf Mobile, wo der reguläre Haupt-Button schnell komplett wegfällt aus dem Screen. Sind der konkrete Preis, die Varianten Specs und der sofortige Button weiterhin extrem griffig dort, zerschmettert man lästige Scroll-Back Friction im Bruchteil der entscheidenden Sekunde direkt on the fly. Auf kurzen PDP-Layouts mit sowieso permament im Sichtfeld haltenden Button bewirkt es dagegen kaum messbare Sprünge.
Nein. Eine Sticky Bar baut man idealerweise pur via kurzem nativen Code Stück zusammen, u.a. mit fixed oder position:sticky Attribut, plus einem super leichten IntersectionObserver zum Einkoppeln, wenn das alte Layout Element entschwindet (dazu ein kurzer Skript-Lauf für das Update vom Preis Feed und den Variants). App Widgets gehen flotter in der Installatur, kassieren aber oft Monthly Payment Abo Beträge, zwingendes JS Rendering Layerings und reißen den Bar sofort bei Kündigung mit raus.
Ziele via IntersectionObserver schlicht auf den echten, alten Buy-Button ab. Wenn sich das beobachtete Knopf Target Layering im Viewport aufschneidet (oder ihn blockt), setze den Zustand versteckt, wenn nicht, zeig ihn. Weil der Observer außerhalb und losgelöst eines Haupt Core Loops (dem Main Thread) mit-rentiert und schuss-genau auf ein reines Trigger Limit einhakt, frisst er weitaus weniger Performance als Scroll Event Tracker.
Deklariere das originale Product-Form Element glasklar als alleinige Source und Truth. Zapf das Change Update Script beim originalen Select Picker an und synce den neuen Variant/Preis Value in die Werte der Bottom Bar. Entweder feuerst du dann das Main Form an, via Formattribut Submission aus dem Bar Knopf raus, oder pfefferst den puren Post Fetch AJAX Push an /cart/add.js aus mit der geklärten Variante und Quantity Nummer.
Nativen Formaten absolut gar nicht – bis kaum. CSS Property position:sticky greift durch Compositing auf pure Architektur – IntersectionObserver entlasten dir schwere Event Script Scroll Lines. Load Weight baut sich massiv auf ab dem Moment, wo Widget-Apps sich pro Seite durch die JS-Tunnel nach laden. Performance-Fixierte bauen es aus Code und nicht im Widget Paket.
Sofern schlecht eingeklöppelt, ja. Sorge strikt dafür, dass sich kein Layout blockt oder Text (wie Footer Content) ver-verdeckt. Gieße saubere Paddings aus! Checke per Tab Check einwandfreies Navigieren im Selection und Button durchgängig mit. Focus nie fangen lassen (Kein Modal Fallback Trap) – und zieh High Contrast Colours durch. Sorgfältig eingegossen stört es weniger, als es den Komfort liftet.
Footnotes
-
MDN Web Docs, “position” - ein
position: sticky-Element wird als relativ positioniert abgewickelt, solange, bis der umschließende Container Block die Schwelle beitop/bottomtangiert. Zu genau diesem Knackpunkt greift die Sticky-Phase fest. Es passiert pur beim Rendern der Architektur via Browser Compositor (ohne JS Einsätze). https://developer.mozilla.org/en-US/docs/Web/CSS/position ↩ -
MDN Web Docs, “Intersection Observer API” - scannt asynchron pass-genau, wann ein Ziel Target Element konkret in das definierte Sichtfenster kreuzt und reizt (im Gegensatz der alten, massiv teuren Per-Frame Event Loop Listener Variante) exklusiv da via Call Back den Render. https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserver ↩
-
Shopify Dev, “Cart AJAX API” -
POST /cart/add.jsschickt Variante / Array Pakete (inklusive der Werte Line Itemidwiequantity) direkt hinüber. Returnt sauber gepackte Line Items aus JSON (Succes) und klopft als Response einen harten 422 Error Status heraus, sobald Quantity Limitierungen krachen (Oversellings / No Stocks). https://shopify.dev/docs/api/ajax/reference/cart ↩