Christmas Mega Sale – Enjoy Up to 50% OFF on Every Plan! 
No one is checking your raffle website’s speed against your compliance obligations, but they should be. Most raffle website builder platforms do a decent job of making sure the free entry route is there and prominent, but what they don’t do is test it thoroughly enough to understand if it’s as resilient as the one requiring payment. It exists, it’s visible, and it works fine on a Tuesday afternoon on office wifi. Then draw night lands and six thousand people arrive inside forty minutes.
Equal prominence is a performance requirement, not a layout one
What’s the standard, then? This is the part that never appears on a raffle website builder feature list, so it’s worth being precise. There are two places to look.
What does the CAP Code say?
The CAP Code (the Advertising Standards Authority’s rules for ads in the UK) requires at rule 8.17.2 that a free entry route be explained “clearly and prominently”, which is a little vague on its own. It’s a starting point rather than a test you can measure yourself against.
And what does the Gambling Act add?
The Gambling Act 2005 is more explicit: the route has to be publicised in such a manner that it is “likely to come to the attention of each individual who proposes to participate”. Legal commentary on that test tends to put a second word next to prominent. Convenient.
What has convenience got to do with speed?
Convenience is where loading speed crosses from a marketing concern into legal territory. If your free entry form takes 9 seconds to fully load on 4G, or throws a 504 at 9:52pm while the card payment sitting next to it processes instantly, the two routes are not equally convenient. One of them is objectively less handy, and it happens to be the one the law is there to protect.
Has the ASA actually ruled on this before?
Not for load times specifically, but plenty of time spent on similar issues. In the April 2018 HMV Competitions ruling, the ASA found that the postal address was too far down the page from the prominent buy-now buttons, so entrants could easily miss it altogether. Then again in 2020, Elite Competitions drew complaints on the same ground, one of them from a solicitor who specialises in gambling regulation.
Four ways that speed presents an issue specific to compliance
Each of these is a place where a raffle website builder can pass every manual check a director runs and still leave you exposed.
1. The free entry route is giving up at the first hurdle
Because the free entry form doesn’t directly pay for anything, it’s far less likely to be optimised. It gets whatever the theme has baked in: large unoptimised images, blocking JavaScript, a form endpoint with no load testing. Someone waits 11 seconds and gives up, paying £5 instead. If that happens a few hundred times, your entry mix is being set by your hosting rather than by your entrants.
2. The skill question renders after the fact
A paid entry needs its skill question answered correctly before processing, which means it has to sit in front of the checkout rather than after it. If the page renders too slowly, or the script simply fails to execute, then the skill question isn’t actually gating the entry. Now you’re processing hundreds of entries that should’ve been rejected, simply because your raffle website builder failed a basic performance test.
3. The age check doesn’t record
Your age verification is logged somewhere, probably a write to a database. Under load, that write can fail to execute while the visitor moves on to the next step, believing their entry to be successfully recorded. It can take months before anyone notices, but then the records are inconsistent with the entry numbers. That’s a hole in your audit trail that nobody will be able to explain after the fact.
4. Your consents aren’t writing during the busiest time
Same issue, different regulatory body. GDPR consent logs need to record what each visitor was consenting to, and when. Again, the busiest time to visit your website is right at closing time. The same moment you’re gathering the most consents is also when those writes are most likely to fail. You can lose an hour’s worth of consent records if you’re not using a compliance-focused raffle website builder.
Draw night is the only test that counts
Whatever your raffle website builder promised at sign-up, the closing hour is where you find out whether it was true.
The failure is scheduled, not random
A competition website has a habit of working fine for three solid weeks and then collapsing with 400 concurrent visitors. You can predict almost exactly when it will happen, which is the awkward part. Traffic is front-loaded, often within the final hour before closing, and frequently within the closing ten minutes if you have a countdown clock and sent out a reminder email at eight o’clock.
Your quiet week tells you nothing useful
Your Tuesday numbers are averages, and averages give no information about that busiest hour. They say nothing at all about the two or three pages that were stress-tested least, which are usually the free entry form and whatever sits behind it.
Live ticket counts are cached for five minutes
Live updating ticket counts and odds are useful for marketing, but when a visitor’s money has been transferred, those cached figures are no longer accurate. The error is smaller than the free entry one, but it belongs to the same family: a raffle website builder caching these numbers is a performance optimisation that hides the fact that you’re giving out incorrect information to paying customers.
How to test your raffle website builder before a regulator does
Lighthouse and Core Web Vitals won’t help much. They’re meant to test single pages with a good connection and zero concurrent visitors, the complete opposite of what your closing hour looks like. Here are four additions to your pre-draw test suite:
Test the free entry route, not the homepage
Use something like k6 or Locust to load test the free entry route, aiming for twice the peak visitors you expect to handle. Measure response time, error rate and completed submissions, then watch which of the three gives way first as you turn the request rate up. Repeat for your paid route, skill question included. If the free route degrades first, that’s your fix.
Count your records after each draw
For each visitor that enters, there should be a corresponding entry in your database records. For a skills-based entry, there should be a log of the skill test result as well. If 6,200 visitors entered and your scripts only recorded 5,940, you have a 260-record gap that you can put a number on. Every decent raffle website builder should be able to report both these numbers.
Cache the marketing pages, not the numbers
Your prize page and about page can take aggressive cache headers without anyone suffering. Ticket counts and odds should be live figures, or short windows with a clearly visible timestamp, so that a stale number is at least an honest one. Accuracy matters more for the financial figures, and speed is nice for everything else your visitors will read.
Rehearse a complete entry every minute
This is still a synthetic transaction, but it covers the entire entry process. Load the page, answer the skill question, and submit a free entry, checking that the submission was successful. It’s worth running this every minute up until your closing hour, and watching it happen in real time. This is much more informative than a generic dashboard.
Speed should be in your compliance file
Two teams are responsible for this, which is why it tends to fall between them. The development team maintains the speed of the product, and the compliance team (or an executive with a spreadsheet) is responsible for its legal position. Neither has anything in their job description about ensuring that the free entry route still works at 9:58pm on draw night, so it falls through the cracks, and the raffle website builder sits in the gap between them.
The solution is unexciting. Run a load test on the free entry route, count your database records after each draw, keep your numbers honest. Then save that report with a date on it somewhere safe. A load test run on an appropriate day with appropriate traffic numbers makes a handy document to hand to a regulator who asks, “Well, how do you know the free entry route is just as accessible as the other options?”
If you don’t want to handle all of this yourself, a compliant raffle website builder puts the performance and compliance responsibilities in one place. Worth reading what a competition website actually needs before your next launch, particularly the parts that only ever get tested in public.
FAQs
Q1. Can a slow website actually breach UK competition law?
Not directly. Slower performance is less convenient, and it’s the combination of less convenient and less prominent that causes a problem. But a free entry route that takes noticeably longer to load than the one asking for £3 is harder to defend as equally accessible, and the Advertising Standards Authority has ruled on adjacent cases before. It’s a technicality, and it’s one most platforms have never thought about.
Q2. How quick does a free entry route need to be?
The law doesn’t specify, but you can use your own checkout as a reference. Whatever peak concurrent visitors your card payment processor is handling, the free entry route should be able to handle at least that many. Most raffle website builder platforms include both numbers somewhere, so that you can see the gap for yourself. If one route is measurably slower, that’s the gap worth closing.
Q3. What’s the most common speed-related reason for a compliance breach?
It’s the age verification and consent writing processes. They both suffer from failing silently at peak time, with no records being written at all. A free entry route simply timing out is a bigger problem, but it’s caught earlier, because someone complains about it. Missing records simply vanish without explanation, and that’s when things start getting interesting.
Q4. What should we test before a big draw?
The free entry route under realistic load, the skill question before checkout, age verification writing, and consent writing all need to be tested at the traffic level you expect to see. Once the draw has finished, you need to count the records in your database and reconcile them with the entries you received.
