Load-Test Your Burnaby Shop Site and AI for Black Friday

Black Friday is about six weeks out. If your shop runs a sale, a few hundred people might hit the same product page in the same five minutes. Most small sites have never seen that. The time to find out what breaks is now, on a quiet Tuesday, not at 9 a.m. on November 27.

This post walks through a practical load test for a small online store, and it covers a piece most guides skip: the AI chat assistant or AI order bot you may have bolted onto your site this year. It has limits too, and they behave differently from your web server.

What a load test actually tells you

AWS describes load testing as measuring "the performance of cloud workload under realistic conditions with expected user load," using a production-like environment, real load tools, and metrics you decide on ahead of time (AWS Well-Architected, PERF05-BP04). The same page lists the classic mistakes: testing parts of the site but not the whole thing, testing on infrastructure that doesn't match production, and only testing to your expected load instead of past it.

That last one matters for a sale. You don't want to learn your ceiling is 1.2 times a normal Saturday.

Grafana's k6 documentation breaks testing into types that build on each other (Grafana k6, Load test types):

• Smoke test: a few users, seconds or minutes, just to prove your script works.
• Average-load test: normal traffic for 5 to 60 minutes.
• Stress test: load above your average, also 5 to 60 minutes.
• Spike test: a sudden, short, massive jump over a few minutes. This is your "email blast just landed" scenario.
• Soak test: average load held for hours, which catches slow memory leaks and full disks.
• Breakpoint test: keep ramping until something gives.

The k6 docs say to start with a smoke test and keep load shapes simple: ramp up, plateau, ramp down. Good advice for a shop owner with one afternoon to spare.

Step 1: Know what you're allowed to test

Before you fire thousands of requests at anything, check who owns it. If you host on AWS, the Amazon EC2 Testing Policy allows sending "a large volume of legitimate or test traffic to a specific intended target application," but it explicitly prohibits volumetric network DDoS simulations. AWS's own best practice page warns that skipping the testing policy can make your test look like a denial of service attack.

If you're on a hosted platform like Shopify, Squarespace or Wix, you don't run the servers. Rules differ by platform and plan, so read your terms or get a written answer from support before you load test their infrastructure. What you can measure freely on a hosted platform is your own front end: the theme, the apps, and the scripts you added.

Step 2: Fix page weight first

On hosted shops, slow pages usually come from apps and theme code, not the platform. Shopify measures how apps affect storefront speed with Lighthouse, weighting the collection page at 43%, product details at 40% and home at 17% (Shopify Dev, Storefront performance). That weighting is a useful hint for you too. Shoppers spend their time on collection and product pages, so test those first.

Shopify also notes that "Lighthouse scores can vary between runs" and recommends averaging several runs. Do the same.

For targets, Google's Core Web Vitals give clear numbers: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads on mobile and desktop separately (web.dev, Web Vitals). If you're failing those on a calm day, a sale will only make it worse.

Step 3: Script a real shopper path

A load test that only hammers the home page tells you almost nothing. Write a script that browses a collection, opens a product, adds to cart, and starts checkout. Use test data. AWS says load tests "must be run using synthetic or sanitized versions of production data," which also keeps you clear of privacy trouble with real customer records.

Then run the sequence: smoke, average, spike, stress. Watch three things on each run: response time, error rate, and what your monitoring shows on the server or database. Write down the load level where errors start. That number is your planning ceiling.

AI coding assistants are genuinely handy here. They can draft a k6 script from a plain description of your checkout path in minutes. Read it before you run it, though. A script that loops on "place order" against your live payment processor is an expensive typo.

Step 4: Load test your AI assistant separately

Here's where 2026 shops differ from 2020 shops. If you've added an AI chat agent that answers sizing questions or checks order status, every customer message becomes a call to a model provider's API. That API has rate limits and spend caps that have nothing to do with how big your web server is.

Take Anthropic's Claude API as one example. As of October 2026, its rate limits page says limits are measured in requests per minute, input tokens per minute and output tokens per minute, and that going over returns a 429 error with a `retry-after` header. A few details that matter for a sale:

The page says a limit of 60 requests per minute "might be enforced as 1 request per second," so short bursts can trip the limit even when your per minute average looks fine. It also describes acceleration limits: a "sharp increase in usage" can trigger 429s, and the advice is to "ramp up your traffic gradually." A Black Friday spike is the exact opposite of gradual.

Spend caps are the other trap. As of October 2026 the same page lists a monthly spend cap of $500 USD on the Start tier and $1,000 USD on Build. Hit it and API usage pauses until the first of the next month, and the 429 you get back has no `retry-after` header, so automatic retries just keep failing. For a shop that hits the cap on November 28, that could mean days with a dead chat widget.

Illustrative example only: say your assistant averages four model calls per conversation and 300 shoppers open the chat in the first ten minutes of a sale. That's roughly 1,200 calls in ten minutes, but they won't be spread evenly. Check your tier, your current spend, and your per model limits in your provider console, and request an increase well before the sale if you need one. Other providers publish their own limits, so check the page for whichever one you use.

Two practical fixes. First, the Anthropic page notes that for most current models, cached input tokens don't count toward the input token limit, so caching your long system prompt and product FAQ raises your effective headroom. Second, build a fallback: if the AI gets a 429, show a friendly "we're busy, here's our FAQ and email" message instead of a spinner.

Where this doesn't apply

Be honest about whether you need any of this.

If your shop does mostly in person sales and the website is a brochure, a full load test is probably overkill. Statistics Canada data reported by the Nova Scotia Department of Finance puts 2025 Canadian e-commerce at $50.77 billion, or 6.1% of annual retail trade. Online matters, but for plenty of Burnaby and New Westminster retailers the real Black Friday risk is a long line at the till, not a crashed server.

Load tests also have blind spots. A test from one cloud region doesn't reproduce real shoppers on spotty mobile data around Metro Vancouver. It won't catch a third party payment or shipping app failing on its own. And on a hosted platform you mostly can't test the platform at all, only your pieces of it.

Finally, if you haven't added an AI assistant yet, don't rush one live the week before Black Friday just because competitors did. A new bot with untested limits is a bigger risk than no bot. Launch it in January, when a mistake costs less.

A simple six week plan

Week one, measure Core Web Vitals on your top collection and product pages. Week two, cut or defer slow apps. Week three, write and smoke test a shopper path script. Week four, run average, spike and stress tests and note your ceiling. Week five, check your AI provider limits and spend cap, add caching and a fallback message. Week six, freeze changes.

Sources

• Amazon Web Services. "PERF05-BP04 Load test your workload." AWS Well-Architected Framework, Performance Efficiency Pillar. Accessed October 2026. https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/perf_performing_architecture_load_test.html
• Amazon Web Services. "Amazon EC2 Testing Policy." Accessed October 2026. https://aws.amazon.com/ec2/testing/
• Grafana Labs. "Load test types." Grafana k6 documentation. Accessed October 2026. https://grafana.com/docs/k6/latest/testing-guides/test-types/
• Anthropic. "Rate limits." Claude Platform documentation. Accessed October 2026. https://platform.claude.com/docs/en/api/rate-limits
• Shopify. "Storefront performance." Shopify Dev documentation. Accessed October 2026. https://shopify.dev/docs/apps/build/performance/storefront
• Google. "Web Vitals." web.dev, last updated October 31, 2024. https://web.dev/articles/vitals
• Nova Scotia Department of Finance, Statistics. Daily release on Canadian retail e-commerce, February 20, 2026, citing Statistics Canada Table 20-10-0056-01. https://novascotia.ca/finance/statistics/news.asp?id=21775

Want a second set of eyes before the rush? Autana Solutions is based in Burnaby and New Westminster, and we help Vancouver area shops set up AI assistants that hold up under real traffic. Book a free call and we'll walk through your site and your AI setup together.