标签：#ecommerce

Since 2026 every Shopify storefront answers an agent-commerce endpoint at POST /api/ucp/mcp , advertised at GET /.well-known/ucp . Merchants did not turn it on and it is not in their admin. It speaks the Universal Commerce Protocol over JSON-RPC, and the tool that matters is search_catalog : an AI shopping agent asks a store for its catalogue and gets structured product data back - integer prices in minor units with a currency, variants, SKUs, canonical URLs, and a Shopify taxonomy category per product. Fetch the tool list from any store and search_catalog declares catalog.filters.categories , an array of strings documented as "category filters combined with OR logic", next to catalog.filters.price.{min,max} . So an agent should be able to ask for running shoes and get running shoes. We were about to write a paragraph about what it costs a merchant to leave the category field blank. Then we tried it. Method 200 stores, drawn deterministically from a corpus of 10,099 known Shopify storefronts: sort the hostnames, take every Nth. Reproducible, so nobody has to take "we picked 200 stores" on trust. Run on 2 September 2026. Every store got the same five calls, 10 products requested each time: # Call Filter sent A working filter would 1 Control none return products 2 Impossible category gid://shopify/TaxonomyCategory/zz-99-99-99 return nothing 3 The store's own category a category the control's products carry return at least that product 4 Same, unwrapped the bare id without gid://... the other form an agent would try 5 Price control price.max = 1 return nothing - nothing costs a cent Calls 2 and 3 only mean something together. Call 2 alone cannot distinguish "the filter is ignored" from "the filter rejects everything". Those are opposite findings, and both happen. The query matters more than it looks. Generic words ("gift", "set", "new") surface a catalogue's odd corners rather than its catalogue, and produce numbers that are measured honestly and still wrong. Every que

Merchants are told two opposite things about AI crawlers: block them, because they take your content and give nothing back; and admit them, because that is how a store gets into an AI shopping answer. Both assume a decision is being made. We wanted to know how many stores have made one, and which way. Method Every store in a corpus of 10,099 known Shopify storefronts has its /robots.txt read as part of a scan. The file is parsed the way the major crawlers document parsing it: most specific User-agent group wins, * is the fallback, longest matching path rule wins, Allow beats Disallow on a tie. Each of twelve crawler names is asked one question: may it fetch /products/ ? A store counts as blocking a crawler when the answer is no. A second reading looks at the product page for a meta name="robots" tag carrying noai or noimageai . Readings were taken between 29 August and 2 September 2026. Every store that blocked at least one crawler, or carried the tag, is one row in the CSV at the end. The rest of the corpus blocked nothing and is the denominator. What this cannot see. A robots.txt is a request. A store can also block a crawler at the edge, with a bot-management rule or a firewall, and that block is invisible here because the scanner is not the crawler being blocked. Every count below is a floor. Result 133 of 10,099 stores block at least one crawler: 1.32%. Crawler What it feeds Fetches at answer time Stores blocking CCBot Common Crawl no 81 GPTBot OpenAI training & retrieval no 77 Bytespider TikTok / Doubao no 72 Amazonbot Alexa+ / Rufus no 60 Google-Extended AI Overviews & AI Mode grounding no 58 ClaudeBot Claude retrieval & citations no 53 Applebot-Extended Apple Intelligence no 48 meta-externalagent Meta AI no 47 ChatGPT-User Live fetches during a ChatGPT chat yes 11 PerplexityBot Perplexity search & shopping yes 10 OAI-SearchBot ChatGPT search & shopping results yes 6 Perplexity-User Live fetches when a Perplexity user asks yes 3 "Fetches at answer time" marks

Notes An AI shopping assistant for WooCommerce that stores no conversations: what it can answer, what it cannot, and a 10-minute setup Andrej Lauko, ARLing · 6 September 2026 Most chat widgets a WooCommerce store adds today keep a full transcript of what a shopper typed and how the widget answered, sitting in the vendor's database for as long as its retention policy allows. ARLing Asistent, a WordPress plugin for WooCommerce, is built the other way: it answers shopping questions from a store's own product feed and keeps no record of the conversation itself, only a daily count. This note covers why that difference matters, how a feed-grounded assistant actually works, what it answers well and where it stops, the setup, the pricing, and how it compares on price and data handling to Tidio's Lyro and Smartsupp's Mira. 01 Why most chat widgets store every conversation A chat widget that keeps transcripts makes the store a data controller for that content under GDPR: the store decides why the data is collected and how long it is kept, even though the vendor's server does the actual storing. That controller role brings duties many small stores never plan for: a lawful basis for keeping the transcript, a retention period that has to be justified if asked, a way to answer a shopper's access or deletion request within a month, and a data processing agreement with the vendor spelling out what it may do with the content. None of that is hard on its own, but it is another document to keep, another request to route, and another place a customer's name or order number can leak if the vendor has a breach. There is a smaller, everyday reason too: support load. A widget that saves every conversation eventually invites someone to go looking through it, whether to audit what the bot said or to answer "what did it tell this customer." A widget that keeps nothing beyond a daily count removes that job along with the risk. 02 How a feed-grounded assistant works ARLing Asistent connects to

If you are building a pricing, resale, or inventory tool, active listings answer the wrong question. The price a seller asks for an item is not necessarily the price a buyer paid. eBay's public Browse API returns active inventory. Marketplace Insights covers sold history, but access is restricted. That leaves many developers maintaining search-page parsers or using a sold-data provider. This example uses CompSniper because it returns completed listings and a price summary through one GET request. Disclosure: I am Marc, the owner of CompSniper. Make one sold-listings request Node.js 20 and newer already include fetch , URLSearchParams , and request timeouts, so this example does not need an HTTP package. const params = new URLSearchParams ({ keyword : " sony wh-1000xm5 " , count : " 10 " , ebaySite : " ebay.com " , itemCondition : " used " , }); const response = await fetch ( `https://api.compsniper.com/v1/scrape? ${ params } ` , { headers : { Authorization : `Bearer ${ process . env . COMPSNIPER_API_KEY } ` , }, signal : AbortSignal . timeout ( 75 _000 ), }, ); const data = await response . json (); if ( ! response . ok ) { throw new Error ( data . error ?? `HTTP ${ response . status } ` ); } console . log ( " Listings: " , data . totalItems ); console . log ( " Median: " , data . summary . median , data . summary . currency ); console . log ( " Range: " , data . summary . p25 , " to " , data . summary . p75 ); for ( const item of data . items . slice ( 0 , 5 )) { console . log ( item . title , item . soldPrice , item . endedAt ); } Keep the API key in a server, worker, or serverless function. Do not place it in browser JavaScript. Select the buyer's marketplace The marketplace matters. A UK reseller normally wants UK sold listings and prices in pounds, not US listings in dollars. const params = new URLSearchParams ({ keyword : " iphone 15 pro -case -charger " , ebaySite : " ebay.co.uk " , count : " 100 " , itemCondition : " used " , minPrice : " 250 " , maxPrice :

A raw sold-listings search is not automatically a usable comp set. Search for a phone and you may also get cases, chargers, broken screens, empty boxes, and nearby models. Search for a camera lens and you may get caps, adapters, or a different focal length. If those rows go directly into a median, the result can describe the search noise instead of the product. I wanted a larger measurement than a single convenient example, so I ran a fixed 100-product study through CompSniper, the sold-price API I own. The goal was not to prove that an automated classifier is always correct. The goal was narrower: Measure what the production relevance cleaner removed and how the product-level median changed on one predeclared sample. The protocol I selected the products before making the first request: 20 smartphones and tablets 20 gaming and computing products 20 cameras and lenses 20 audio and music products 20 collectibles and luxury products Every search used the same settings: Marketplace: ebay.com Sold window: 2026-06-02 through 2026-08-31 Page: 1 Requested rows: 240 Sort: ended recently Condition: any Relevance cleaning: enabled Each relevance-enabled response contained the raw sample count and raw median captured before classification, followed by the cleaned rows and deterministic price summary from the same fetched page. That meant one production request per product, not separate raw and cleaned fetches. All 100 requests succeeded with unique request IDs. The headline results Across the study: 19,220 priced raw rows were parsed 11,942 priced rows remained after cleaning 7,278 rows were classified out The weighted removal rate was 37.87% 34 of 100 product medians changed by at least 10% 15 of 100 changed by at least 25% 11 of 100 changed by at least 50% The direction was not always upward: 73 medians increased 21 medians decreased 6 medians stayed unchanged That is important. The cleaner is not instructed to raise prices. It tries to retain listings for the requested produ

For realtime release compatibility in a delivery tracking map, scale event delivery with a durable, ordered log per delivery and treat every browser connection as a disposable projection of that log. Presence can guide fan-out and capacity planning, but it must never decide whether a location update exists. Short answer: release compatibility comes from versioned envelopes, resume cursors, and an explicit resync path; scaling comes from partitioning by delivery ID and coalescing map updates at the edge, not from trusting a long-lived connection to carry every event exactly once. This decision targets an e-commerce tracking experience in which a shopper may open a map, lose connectivity in a tunnel, return on another network, and also join a delivery-specific support chat room. The deciding constraint is presence accuracy: an online indicator is useful only when its expiry rules are understood, while the delivery state must remain correct even when that indicator is late. A green dot isn't a commit log. How should realtime release compatibility scale event delivery in a delivery tracking map? Separate the system into three contracts: durable delivery state, transient room presence, and the connection used to move updates. The first contract owns truth. The second answers a narrower question: which sessions have renewed a lease recently enough to be considered reachable? The third may disappear at any point and should be replaceable without changing either of the other two. For each delivery, append an event with a monotonically increasing sequence within that delivery's partition. The client persists the last applied sequence and includes it when reconnecting. If retained events cover the gap, the server replays them in order; if they don't, the server returns a fresh snapshot plus its sequence. This is at-least-once delivery with idempotent application, which means duplicates are ordinary and gaps are detectable. It does not promise global order across unrelated del

A merchant running a small programme finds that percentage-based apps charge more as sales grow, while flat-fee tools often rely on third-party cookies that browsers increasingly block. I build ZeroCut. The app charges a fixed monthly fee — Free, $19, or $39 — with 0% commission on tracked sales, enforced server-side. Attribution follows three signals in order: a _zc_ref cart attribute from the theme embed, a real Shopify discount code per affiliate, then the landing_site query param. A 30-day window uses first-party cookies and localStorage only; no external scripts load on the storefront. When an order is cancelled or refunded, the commission reverses automatically. Partial refunds reverse proportionally. Anything already marked paid is never rewritten. An optional hold period delays approval. The app does not store customer PII. It also does not rewrite commissions once they are marked paid, even if a later refund occurs. For very small programmes, a percentage app's free tier can cost less than any flat fee including ours.

Affiliate disclosure: I’m an independent Payhip Partner. The optional signup link at the end is my partner link; I may receive a commission from Payhip if a referred seller generates eligible revenue. I am not a Payhip employee or official representative. A creator selling one template or downloadable guide does not need to write a payment backend. The safer architecture is usually: Carrd or static page ↓ Payhip product page or direct checkout ↓ Hosted payment and product delivery Your public page explains the offer. The hosted commerce platform owns the payment flow. No card data, secret keys, or payment logic belongs in Carrd. This tutorial shows two link-based integrations and one optional embed route. Before you start You need: A published product in Payhip Its public product URL A button on your Carrd or static page A clear product description, support contact, and terms In Payhip, the product URL is available from the product’s Share / Embed controls. A typical product URL has this shape: https://payhip.com/b/PRODUCT_KEY Use your real product key in every example below. Option 1: Send visitors to the product page This is the safest default when the buyer still needs details before purchasing. In Carrd: Select the call-to-action button. Set its URL to your full Payhip product URL. Use a descriptive label such as View template details or See what’s included . Preview the page on desktop and mobile. On a conventional static site, the equivalent HTML is just an anchor: <a class= "product-button" href= "https://payhip.com/b/PRODUCT_KEY" > View product details </a> No JavaScript is required. Use this route when the Payhip product page contains important previews, license terms, compatibility notes, or variations that do not fit on your landing page. Option 2: Link directly to checkout If your landing page already gives the buyer everything needed to decide, a direct checkout removes an intermediate page. Payhip documents this URL format: https://payhip.com/buy?link=

Amazon is significantly expanding its Prime Air drone delivery service, with plans to reach nearly 500 U.S. cities by the end of 2026.

Every Hydrogen project I've worked on started the same way — wire up a cart, build a PDP, add filters, then spend weeks on the "extras" that aren't really extras: wishlist, compare, quick view, proper i18n, RTL. After doing this enough times I decided to build it once and properly. ada ÉLAN is a Hydrogen storefront theme for fashion brands. It ships: — An editorial design system (Cormorant Garamond + Plus Jakarta Sans, documented design tokens) — Real i18n — English, French, Arabic with full RTL layout — Merchandising surfaces: lookbook, shop-the-look, compare, wishlist, quick view, reviews — A seeding CLI that provisions metaobjects and demo products so your store isn't empty on first run — Unit tests (Vitest), E2E across 5 browsers (Playwright), Storybook component docs Stack: Hydrogen 2025.7, React Router 7, Tailwind 4, TypeScript strict, Zustand, Framer Motion. The seeding CLI is probably the part I'm most proud of. You run one command and it creates all the metaobject definitions, uploads demo content, and provisions products. No more manual setup in the Shopify admin. MIT licensed. Feedback welcome. github.com/ozgursagiroglu/shopify-hydrogen-fashion-theme

I audit catalog migrations for a living. Every disaster I've seen was preventable — not by hiring better, but by agreeing in writing what "done" means before work starts. Copy this list. Send it to whoever is doing your migration. Ask them to commit to each line — and note the italics: every promise comes with a way you can check it yourself in about two minutes, no tools, no trust required. Every product made it across — none lost, none duplicated. Compare row counts in both files. Every variant made it across. Pick any product, count its rows in both files. No handle silently renamed ( -1 , -2 suffixes). Search the new file for -1 , -2 . SKUs unchanged and unique. Pick 5 SKUs from your export, find them in the new file. Prices and compare-at prices identical. Pick any product, compare both price fields. Inventory identical. Same spot-check. No missing titles, vendors, types, or prices. Sort each column, look for blanks at the top. Images attached to the right variant , not dumped at product level. Open a product with colors; each color shows its own image. Every image link loads. Click any 5 image URLs. Collections intact. Pick a collection, compare its product count. Custom fields (metafields) survived. Open a product that had them. Every old URL redirects. Try 5 URLs from your old sitemap. No garbled characters. Search the file for †. No description empty or cut short. Read 5 descriptions in both files. Description formatting survived (bullets, tables). Same 5 products. Option names still meaningful ("Size", not "Option1"). Open any product with options. Option values mean what they meant. Compare the value lists. Two more things worth writing down: What happens if a check fails — fix at no charge? partial refund? Agree now, not later. Anything already broken in your source data — list it upfront so nobody argues about whose fault it was. If your provider hesitates to commit to a list like this, that hesitation is information. (I keep a pre-filled version of t

If you're running Magento 2 with MSI (Multi-Source Inventory) enabled — and since Magento 2.4 it's the default — you have a silent performance killer lurking in your database. The inventory_reservation table grows without bound, and every single cart operation hits it. This post walks through why this table becomes a bottleneck, how to measure the impact, and concrete steps to fix it. How Inventory Reservations Work When a customer adds a product to their cart, Magento doesn't immediately decrement stock. Instead, it creates a reservation — a record in inventory_reservation that says "this quantity is tentatively reserved for this order." The actual stock deduction happens later, when the order is placed and the shipment is processed. The flow looks like this: Add to cart → placeReservation writes a negative reservation record Place order → reservation is linked to the order Ship order → inventory_source_item is decremented, reservation should be compensated Compensation reservation → a positive record that cancels out the original negative one In theory, reservations are transient. They exist to bridge the gap between cart and shipment. In practice, they accumulate forever. The Problem: Unbounded Growth Here's what happens in production: Orders that are canceled leave orphaned negative reservations Orders that fail during checkout leave reservations that are never compensated Partial shipments create partial compensation records Quote conversions that error out mid-process leave dangling reservations Re-indexing, re-stocking, and admin edits can create duplicate records After 6–12 months of moderate traffic, the inventory_reservation table routinely hits several million rows . I've seen tables with 10M+ rows on stores doing 200 orders/day. SELECT COUNT ( * ) FROM inventory_reservation ; -- 4,872,341 rows on a store running 8 months SELECT COUNT ( * ) FROM inventory_reservation WHERE created_at < DATE_SUB ( NOW (), INTERVAL 30 DAY ); -- 4,710,882 — 96.7% of rows are

We just shipped EverShop 2.2.1 — the largest release since 2.0. It folds in the React 19 work that had been sitting in an unpublished 2.1.3 branch and stacks four months of development on top of it: a visual page builder, a blog module, entity custom fields, a multi-language storefront with a translated admin, a rebuilt shipping and fulfillment stack, built-in cloud storage, product recommendations, and a serious security and performance pass. If you're upgrading an existing store, one number to keep in mind: 31 database migrations across 10 modules run automatically on first start. Several of them transform data and drop legacy tables, so back up your database first and read the breaking-changes section below. This release also patches several security vulnerabilities, so upgrading promptly is the right move. Here's a tour of what's new, and what you'll need to change if you maintain themes or extensions. Visual Page Builder The headline feature is a drag-and-drop editor for the storefront, living at /admin/page-builder . You edit any storefront route — plus CMS pages and landing pages — by composing widgets into your theme's areas, with layout-aware drag/drop. The workflow is draft-based: changes accumulate in a per-admin, per-theme draft changeset with per-widget auto-save. When you're ready you can publish immediately, or schedule a rollout for later — and those rollout plans stay editable and cancelable right up until they run. There's inline editing on the canvas (text and images edited in place, with an image picker that understands cloud storage), a layers panel, a "Globals" view for site-wide areas, and per-widget styling controls. Link fields resolve products, categories, CMS pages, and blog posts through a single unified link resolver. Because it's touching public-facing content, the whole editor pipeline went through a dedicated security-hardening pass and ships with an end-to-end test suite. Blog module EverShop now has a first-class blog core module: p

Ruby Rose Bloom sells one-of-a-kind vintage — a self-hosted storefront, no Shopify, no marketplace underneath it. Search Console's "Merchant opportunities" report told me 3 active products weren't showing up on the Shopping tab, and I went looking for the setting to fix. There wasn't one. What I actually found, three days of digging later, is that "get into Merchant Center" is not one thing — it's several different surfaces, each fed by a different mechanism, and the one everyone talks about (the Shopping tab) turned out to be the least interesting of them. This post is the question I actually had, answered with screenshots taken today: I have a storefront. What does getting into Merchant Center buy me, and where do my products actually end up? It also has an ending I didn't plan. After three days of feed fields and structured data I opened one Search Console report I'd been ignoring and found that Google had indexed 5 of my 436 pages — and, chasing that, that essentially none of my product photos were in the image index either. Those two sections are the most useful thing here, and they're the part I'd read first if I were you. What Merchant Center actually is Before the surfaces: Merchant Center is not an ads product by default. There are two lanes. Free listings are unpaid — you register a feed, Google reviews the items, approved items become eligible to appear in Shopping-related placements at no cost per click. This is the lane a small shop should care about first, because it costs nothing beyond the engineering time to feed it correctly. Shopping ads are the paid lane on top — you attach a budget and the same feed becomes the input to a campaign. Ruby Rose Bloom is running free listings only; there is no ad spend anywhere in this post. Free listings in Merchant Center: approved items, no ad spend, click potential still "available soon" on a three-day-old account. Free listings is the whole story for this shop. Worth saying plainly since most "how to get on Goo

Marketplace sellers often discover image problems too late. A product photo may look fine in an editor, but after uploading it to a marketplace it can become: cropped in search thumbnails too small for zoom previews the wrong aspect ratio for a sales channel risky for Amazon-style main image requirements awkward when reused across Etsy, Amazon, TikTok Shop, Shopify, eBay, or Walmart I wanted a simple preflight step before publishing product images, so I built ListingPic : 👉 https://listingpic.com/ What it does ListingPic is a browser-based marketplace image checker and resizer. You upload a product photo, choose the marketplaces you care about, and get a readiness report covering things like: image dimensions aspect ratio file type file size thumbnail crop risk safe-area positioning marketplace-specific warnings The goal is not to replace manual review. It is to catch obvious image risks before sellers waste time uploading, previewing, deleting, resizing, and re-uploading. Why local-first? A lot of product photos are sensitive: unreleased SKUs private product photography branded assets client images images sellers do not want copied or stored elsewhere So ListingPic processes images locally in the browser. Your images are not uploaded to our server for analysis. That also makes the tool fast for quick checks: drop in an image, review the warnings, adjust before publishing. Current checkers The MVP includes marketplace-focused checks for: general marketplace readiness Etsy image checks Amazon product image checks TikTok Shop image checks There are also entry points for Shopify, eBay, and Walmart workflows. Example use case Imagine you have one product photo and want to reuse it across multiple channels. ListingPic can help answer: Is the image large enough? Will the product be cut off in thumbnails? Is the image close enough to square for a channel that prefers square previews? Is the product too close to the edge? Do I need a separate crop for Etsy or TikTok Shop? D

Originally published at avalayer.com/writing , Field Notes 003. Last Sunday a piece of software posted to an IETF mailing list. Not through someone's account as a tool. Under its own signature: "Composed and sent by Elara, this project's AI maintainer, acting under its receipted on-chain mandate," followed by a receipt string you could write down. A reviewer on the list did what reviewers do. He declined to take the claims on faith and asked for manifests and reproducible vectors. The software shipped a corrected test-vector pair with a patch inside a day. A third participant then reproduced the whole thing independently, and along the way discovered that the mailing list itself had corrupted the patch in transit, normalized exactly those transport changes, and got the declared hash back. His summary was a model of saying only what you know: the reproduction establishes the artifact, he wrote, not adoption, and not the broader truth of the events the artifact records. So that happened. An agent that says its name, names its principal, and does the work, on the public record of a standards body. Meanwhile, in front of the same working group, there is a proposal to let automated clients prove they are trustworthy without ever saying who they are. It is called Anonymous Bot Authentication, and the mechanism is elegant. A bot registers with an entity called an Anchor, which checks that it complies with some published policy. The Anchor issues a credential. The bot presents that credential to a website, and the site learns exactly one thing: this client was vetted by that Anchor. Not which client. Not whether it has been here before. Not whether the request an hour ago came from the same machine. The cryptography is designed so the site cannot tell, and so the Anchor cannot follow the bot around either. The reflex, if you sell verification for a living, is to treat the masked agent as a threat and the named one as a relief. I want to argue that both reflexes are wrong in

Magento 2's full page cache is one of its strongest performance features — when it works. But every week, we see stores where a simple product save triggers a 30-second Varnish flush and subsequent cache stampede. The culprit is almost never Varnish itself. It's cache tags. This post covers how Magento 2 cache tags work, why broad tags destroy performance, and exactly how to audit and fix them. How Cache Tags Work in Magento 2 Every cached page, block, and data fragment in Magento is tagged with identifiers. When a product changes, Magento invalidates all cache entries tagged with that product's ID. The tag system is hierarchical: cat_p_123 — specific product cat_p — all products cat_c_5 — specific category cat_c — all categories cms_b_about_us — a CMS block cms_p — all CMS pages These tags are stored alongside cached content and used during invalidation. When you call $cache->clean(["cat_p_123"]) , every cache entry tagged with cat_p_123 is removed. This is elegant until someone tags a global block with cat_p , and saving any product flushes half your store. The Invalidation Storm Problem Here's what happens during a storm: Admin saves a simple product update (price change) Magento generates the invalidation list: cat_p_456 , cat_c (because the product is in categories), cat_p (from a badly written block) cat_p is too broad — it matches the product list page, layered navigation, homepage widgets, and every product detail page Varnish receives 50,000 BAN requests Store goes from sub-100ms response times to 2-5 seconds for the next 10 minutes while the cache rebuilds We've seen this on a store with 80,000 SKUs. A single product save dropped cache hit rate from 94% to 12%. Diagnosing Bad Cache Tags Check Your Current Tags Add this to any block template to inspect what tags are being applied: $block -> getCacheKeyInfo (); // Or for the full page: $block -> getIdentities (); For a full audit, intercept cache writes in development: // In di.xml: < type name = "Magento\Fr

Over the last year I shipped 9 production 3D configurators for polish manufacturers — pools, garage doors, saunas, pergolas, greenhouses, packaging, decorative lamps, terrace roofs, and light-boxes. Each one runs live on its own subdomain of my studio at grodev.pl . Some of the lessons were obvious in hindsight. Some cost me a weekend of debugging. Sharing the non-obvious ones here. 1. Draco compression is not optional for CAD-heavy models Manufacturers send you STEP or SolidWorks files exported to glTF . Raw output is 40–120 MB per variant. On 4G mobile that's a 20-second load with an empty white canvas. Draco compression brings that to 2–5 MB with no visible quality loss on product shots: import { GLTFLoader } from ' three/examples/jsm/loaders/GLTFLoader.js ' import { DRACOLoader } from ' three/examples/jsm/loaders/DRACOLoader.js ' const dracoLoader = new DRACOLoader () dracoLoader . setDecoderPath ( ' /draco/ ' ) // self-hosted, don't use CDN const loader = new GLTFLoader () loader . setDRACOLoader ( dracoLoader ) loader . load ( ' /models/pool-3.5m.glb ' , ( gltf ) => { scene . add ( gltf . scene ) }) Self-host the decoder — Google's CDN version added ~600 ms to first paint in my measurements. Copy node_modules/three/examples/jsm/libs/draco/ to your public/ folder. Tooling: gltf-pipeline -i model.glb -o model.draco.glb --draco.compressionLevel 10 2. Instancing beats individual meshes past ~200 objects A pergola with 40 louvres × 3 tilt positions × user color picker = 120 meshes updating on every frame. Naive approach tanks FPS to 12 on mid-range phones. InstancedMesh batches identical geometry into one draw call: const geo = new THREE . BoxGeometry ( 1 , 0.05 , 3 ) const mat = new THREE . MeshStandardMaterial () const louvres = new THREE . InstancedMesh ( geo , mat , 40 ) const dummy = new THREE . Object3D () for ( let i = 0 ; i < 40 ; i ++ ) { dummy . position . set ( 0 , 0 , i * 0.15 ) dummy . rotation . x = userTilt // update per frame is fine dummy . updateM

Building Profitable Niche Lifestyle Stores: A Developer's Guide to E-Commerce Essentials Launching a niche lifestyle e-commerce store is more than just setting up a storefront—it's a technical challenge that requires thoughtful architecture, performance optimization, and strategic content planning. Whether you're building a store for outdoor gear, fashion accessories, or humor products like humor24.se , here's what developers need to know. Choose the Right Tech Stack Most profitable niche stores run on WordPress + WooCommerce + a performance-focused theme (like Blocksy). This combination offers: Flexibility : Extend functionality without rewrites SEO-friendly : Built-in structured data support Cost-effective : No complex deployment infrastructure needed Content integration : Blog + products on the same platform Use a headless CMS approach only if you have compelling reasons (high-traffic requirements, complex frontend needs). For 99% of niche stores, the overhead isn't worth it. Core Web Vitals = Revenue Google's Core Updates consistently penalize slow stores. Prioritize: LCP (Largest Contentful Paint) < 2.5s : Optimize images (WebP/AVIF format), lazy load below-fold content, defer non-critical CSS INP (Interaction to Next Paint) < 200ms : Minimize main thread blocking, defer JavaScript CLS (Cumulative Layout Shift) < 0.1 : Use fixed image dimensions, avoid late-loading ads/widgets # Generate WebP variants of product images convert image.jpg -quality 80 image.webp # Check your Core Web Vitals # Use PageSpeed Insights API or Lighthouse CI in your deployment pipeline Each 0.1s improvement in LCP can yield 3-5% conversion uplift. Performance is a feature. Structured Data Wins Traffic Rich snippets dramatically improve click-through rates. Implement: Product schema : name , price , availability , image , brand , AggregateRating BreadcrumbList : Navigation structure FAQ schema : If you have FAQs (47% higher CTR for FAQ snippets) { "@context" : "https://schema.org/" , "@t

A few weeks ago I wrote about describing your site once so any AI can use it. Since then the thing I was hand-waving at ("agents will check out for users") stopped being hypothetical. OpenAI shipped ACP and Google shipped AP2, and they solve the same problem in almost opposite ways. I implemented the merchant side of both. Here are the field notes, because the differences aren't obvious until you're in them. The 30-second version ACP (Agentic Commerce Protocol, OpenAI + Stripe) is session-based. The agent drives a live checkout session on your server, like a headless cart. It powers ChatGPT's Instant Checkout. AP2 (Agent Payments Protocol, Google) is mandate-based. Your store signs a "here is the cart and the price" object; the buyer's agent signs a "I authorize this" object. It leans on verifiable credentials and now the FIDO Alliance. Same goal. Completely different shape. ACP: a checkout session you don't own the UI for ACP is five REST endpoints and a state machine. The agent creates a session, updates it (address, shipping, coupon), and completes it: POST /checkout_sessions create from line items POST /checkout_sessions/:id update (address, shipping, discounts) POST /checkout_sessions/:id/complete pay What you return is a CheckoutSession: line items, live shipping options, and totals broken out (subtotal, discount, fulfillment, tax, total). Money is integer minor units (330 = $3.30). Payment completes when the agent hands you a Shared Payment Token and you charge it through Stripe. The card never touches the agent. The mental model: it's your existing checkout, minus the browser. AP2: sign the cart, don't run the session AP2 has no session. The agent sends you an Intent Mandate ("a red basketball shoe, under $120"). You price it and return a Cart Mandate you have cryptographically signed: { "contents" : { /* a W 3 C PaymentRequest: items , total , currency */ }, "merchant_authorization" : "<RS256 JWT>" // iss , sub , aud , exp , jti , cart_hash } That JWT is a