The CrowdHandler JavaScript Integration is the quickest and simplest way to add a waiting room to a website—but it has some limitations. In this article, we will walk through some use cases of the JavaScript Integration, explain some key limitations, and suggest next steps.
Your key takeaways
The page where the user lands on your site needs to stay up for the JavaScript integration to work.
The JavaScript Integration is great for:
Learning more about the CrowdHandler product by getting hands-on with our dashboard as quickly as possible
Developing a waiting room proof of concept or internal demo
The JavaScript Integration is not ideal for:
Projects where the server load is the primary consideration
Projects where the security and fairness of the queue is critical
When the JavaScript Integration is not appropriate, we have alternative integrations available.
JavaScript Integration Use Cases
We have developed the JavaScript Integration to be a simple and accessible way of adding a waiting room to a website. This allows product teams and site owners to get CrowdHandler up on their site quickly and efficiently. For many teams, CrowdHandler can be up and running in minutes without the need to raise a ticket to a developer or an engineering team.
Here are some perfect use cases for the JavaScript Integration
I need to set up a basic waiting room without securing other dependencies first (no need to raise a ticket to Engineering!)
I want to pitch using CrowdHandler to the team—I need a low effort way of developing a demo to show them
I want to get up and running so I can learn the platform—we’ll do a full integration later
We just need to slow some of the users down a little—we’re OK with people being able to bypass the Waiting Room as this isn’t a sensitive queue
Limitations of the JavaScript Integration
The JavaScript Integration will only work if:
Users can access the webpage (the server has to stay up)
The JavaScript can run
We are fully behind our JavaScript Integration and have built it to deliver the best waiting room possible, but we want to be transparent about some important limitations. These limitations aren’t unique to CrowdHandler—they are fundamental issues with using JavaScript for waiting room software.
The JavaScript Integration only works if your website stays up
The JavaScript Integration actually needs the server to be able to handle the first hit to the website before the redirection to the waiting room can happen. CrowdHandler can manage access to pages beyond the landing page but if the traffic to the landing page itself causes the webserver to be unresponsive, then you won’t have a waiting room at all.
We’re aware that managing traffic peaks is a key reason why you want to invest in our Waiting Room–and we strongly encourage you to explore our other integrations to have the best success with CrowdHandler in these scenarios.
The JavaScript Integration only works if our JavaScript can run
When using the JavaScript Integration, if the JavaScript can’t run then the user will bypass the Waiting Room. Of course, page load is the biggest barrier to the JavaScript loading. Here are some of the other reasons why the CrowdHandler JavaScript may not run:
Some web users turn off JavaScript in their web browser. We believe the number of users who disable JavaScript to be low but significant. Whilst we can’t find a number we are confident in, various online sources have quoted figures of between 0.2% and 2.0%. The figures seem to vary by country and again by type of users. For example, users of Tor are thought to be more likely to run with JavaScript disabled and some workplaces might enforce a no JavaScript policy.
Tech-savvy users may be able to bypass your Waiting Room. There are a variety of techniques which could be used to work around the JavaScript Integration if a tech-savvy user doesn’t wish to be held in the Waiting Room
The JavaScript Integration is susceptible to being blocked by third-party applications. Many users run various helper applications and plug-ins which can interrupt JavaScripts or block them completely. These services tend to be privacy and security focussed. They will act on scripts which are already known to them or which have certain generic qualities. Users might also be able to add services to blocklists in these apps. Whilst we don’t know of any specific services which would block CrowdHandler by default, this remains a possibility and it is worthy of consideration.
Whilst we would expect only a small number of users to skip the Waiting Room based on these scenarios, the fact is that each scenario breaks the fairness of your queue. This is why we offer our other integrations.
Your next steps
If the security and fairness of the queue are crucial to your project, the JavaScript Integration is not the best way to run CrowdHandler—consider one of our other integrations.
If you have to run the JavaScript Integration for your project, invest time in optimizing your website for high traffic demand:
We recommend that entry points to your site are well cached; you can even consider specific landing pages which funnel users into the Waiting Room.
Be aware that some campaign links, which you may be using to drive traffic, can work against caching strategies if they add unique user tracking parameters.
For the best results, the CrowdHandler JavaScript should load early—and this means it should be placed early in the page source.
If loading via Google Tag Manager, be aware of when the GTM calls are being made; many developers place the GTM container last, so it can be worth manually installing the CrowdHandler script in these cases.
Use the Waiting Room link in your marketing communications rather than the page on your website—this ensures the load stays off your page until the user has been queued.
Keep in mind that the key metric in terms of directing users to the Waiting Room is TTFB (Time to first byte)—this is the time it takes for your webserver to send the user the webpage.