A live chat for your website runs on ordinary PHP shared hosting. It needs no WebSocket server and no Node.js. It asks the server for new messages every few seconds. That sounds old-fashioned, but on shared hosting it is the approach that works everywhere.

Most guides to a PHP live chat start with WebSockets. That fits a server of your own. On a shared hosting plan it usually does not, and this article explains why and what to do instead.

Why WebSockets are hard on shared hosting

On a shared hosting plan, PHP runs only as long as a request lasts. The page is built and sent, and the process ends. A WebSocket server is the opposite: a program that keeps running and holds connections open. On shared hosting you usually cannot start a service like that.

Server-sent events are the middle ground. A PHP script keeps the connection open and pushes messages as they arrive. But every open chat then occupies one PHP process, and many plans limit how many can run at once. If that limit is low, a few open chats are enough to slow down your whole site.

Short polling

That leaves the simple answer. The browser asks every few seconds whether anything new has arrived. Each request is short, and the PHP process is free again right after. This runs on any host that runs PHP.

Three things keep the load low. First, the chat starts asking only after the visitor has written something. Someone who just reads the page triggers no request at all. Second, polling pauses while the tab is in the background and catches up as soon as it is shown again. Third, each request fetches only the messages after the last known number, not the whole conversation.

With a four-second interval, a reply appears about four seconds after it was sent, often sooner. For a support chat that is enough.

Where the conversations live

A chat has to store the conversation, or it is gone after a reload. You do not need to set up a MySQL database for that. SQLite ships with many PHP installations and keeps everything in a single file. If SQLite is missing, a plain file works, locked while writing so that two messages arriving at once do not overwrite each other.

That file does not belong in the web root. One level above it, no URL can reach it. Visitors type names, email addresses and order numbers into a chat, so the file should also be encrypted and readable only by PHP.

Spam and unwanted access

An open chat box attracts bots. A hidden form field that people never see and bots fill in catches a good share of them. Add a limit per IP address on how many conversations and messages are possible within a few minutes.

The view where you answer needs its own protection. A key that the server stores only as a hash, plus a lockout after several failed attempts, stops guessing.

What to check first

Your hosting needs PHP 7.0 or later with the openssl and curl extensions. PHP must be allowed to create a folder one level above the web root. You can see whether that works in your host's file manager: if your site lives in a subfolder such as public_html or httpdocs, there is usually room above it.

How wg_chat does it

Our support chat wg_chat is built exactly this way. It polls every four seconds, starting with the first message and never while the tab is hidden. Conversations are stored AES-256-encrypted in SQLite or a file, in the folder wgdata/wg_chat above your web root. If PHP may not create that folder, the chat names the path during setup. Each IP address can open 6 conversations and send 20 messages within 5 minutes, and the answering view locks for 15 minutes after 8 failed attempts. The visitor's browser holds nothing but a signed conversation id.

You add it with one line of PHP, as described in Rendering widgets server-side in PHP. It costs €4.99 once, no subscription. The demo on the widgets page stores nothing and shows what it feels like for visitors.