The heavy lifting your WordPress membership site shouldn’t do

We have built membership and community sites on WordPress for years, and when one of them gets slow, it is nearly always the same few jobs. Not the pages themselves: those cache well. It is the work a community does in the background, all day, for every member who is signed in. Turn that community into a native app and the same work gets heavier.

This post is for people who run a membership or community site on WordPress, or build them for clients. It covers where the load comes from, what people usually do about it, where those fixes stop, and how Memberside’s services take that work off your server.

Where the weight comes from

Polling: the request nobody needed

Members expect a community to feel live. A new message should appear without a refresh, the notification bell should count up, and the activity feed should show the post that was made a moment ago.

On WordPress, most of that is built the same way: a JavaScript timer on the page sends an AJAX request every few seconds asking “anything new?”. The chat window does it, the notification counter does it, often the feed does too. It runs for every logged-in member, on every page they have open, for as long as the tab stays open, including the tab they forgot about an hour ago.

Each of those requests is a full WordPress request. PHP starts, WordPress loads, every active plugin loads, and the database is queried to find out whether anything changed. Nearly every answer is “nothing new”. And because the members are signed in, page caching does not help: a cache serves anonymous visitors, and a logged-in request goes straight to PHP.

So the cost grows with the number of members online, not with how much is happening. A quiet afternoon with three hundred people browsing can keep your server busier than a busy morning with thirty.

Polling and a held connection

Four members, the same minute, one new message

On the left every member's page asks WordPress for news on a timer. On the right each member holds one connection, and WordPress sends a signal when the message is sent.

Polling

Each member's page or app asks WordPress for news on a timer.

40 requests to WordPress. 2 find something new.

Realtime

Each member holds one quiet connection. WordPress sends a signal when something changes.

2 requests to WordPress, both with news, after 1 signal.

• A request that finds nothing new
• A request that finds the new message
• The signal: something changed
• The moment the message is sent

Push notifications sent from PHP

Push is how a community reaches the members who are not looking at it, which is most of them at any given moment. Sending it from WordPress means your site keeps a list of every member’s devices, sends to Apple and Google for each one, retries the ones that fail, and forgets the phones that were reset. That is a queue, a cron job and a growing table, all running inside the same PHP that serves your pages.

Photos: a directory is a hundred images

A member directory, a feed and a profile are mostly photographs of people. A directory page asks for a hundred avatars at once, and on your own host every one of them queues behind the PHP that is building pages. The bandwidth comes out of your hosting plan, and members on the other side of the world wait for the round trip to wherever your server happens to be.

Video: built for avatars, asked to stream

Members want to post video the way they do everywhere else. A minute recorded on a modern phone is often well over 100 MB, which is more than most WordPress hosts allow in one upload. Served straight from your server, a video plays at one size for everyone, too heavy for a member on mobile data, and every play comes out of your bandwidth.

View counters that write on every view

“How many people saw this?” is a fair question, and the usual answer is a plugin that writes to your database every time a page is viewed. Every view becomes a database write on the same database that serves your members, and the table holding them only ever grows.

A native app makes it heavier

A native app is the best thing you can give an active community, and it adds to all of the above.

• The app polls too. While a conversation is on screen, the app asks your site for new messages every few seconds, for every participant, in every open thread.
• More members stay signed in. People rarely sign out of an app, so the number of logged-in sessions your site serves goes up.
• Phones are photo-heavy. Feeds, galleries and directories are what people scroll on a phone, and every image is another request.
• Push becomes essential. An app that cannot reach members who closed it slowly stops being opened.

None of this means a site cannot have an app. It means the work around the app should not all land on the server that runs the community.

What site owners usually try

Every one of these helps with something. Here is where each one stops.

A bigger server. More CPU and memory buy headroom, and sometimes that is the right call. But the polling grows with the number of members online, so a bigger server buys time until the community grows into it, and you pay for the empty answers too.

Page caching. Excellent for visitors who are not signed in. A membership site’s members are signed in, and their requests go straight past the cache to PHP.

Object caching. Keeping query results in memory makes each request faster. It does not make there be fewer requests: WordPress still starts and every plugin still loads for each one.

Slowing the timers down. Plugins that throttle WordPress’s Heartbeat, or a chat setting that polls every thirty seconds instead of every five, cut the load. They also make the community feel slower, which is the thing the timer was there to prevent.

Running your own WebSocket server. This is the right shape: hold a connection open and push the change when it happens. It is also another server to run, secure and scale, a separate process to keep alive next to WordPress, and the plugins you use have to be wired to it one by one, on the website and in the app.

A separate service for each job. A push service, a media offload plugin with a CDN, a video host, an analytics tool. Each one helps, and each one is another account, another integration, another bill and another dashboard. None of them knows your app, and most of them do not know your community’s plugins: which avatar belongs to which member, who may watch a video in a private group, or what counts as a view of a member’s post.

Taking the work off your server

Realtime: no more polling

Realtime replaces the “anything new?” timers in the app and on your website. Each member holds one quiet connection to our network, no matter how many screens or features use it: one connection per person, not one per window. When a message is sent or a notification is raised, WordPress sends one short signal, fire and forget, so it never slows the page the member is waiting on. Every open app and browser in that conversation updates at once and fetches the message from your site.

The signal says only that something changed. The message itself is still fetched from your WordPress, over your own API, under your own permission rules, so your members’ content never passes through us. And your server answers when something has actually happened, instead of every few seconds for everyone. Anyone not connected carries on exactly as before, and if the connection drops, the app falls back to polling rather than to an error.

Push Notifications: the delivery, not the queue

Your site tells our network what happened. We work out which devices belong to that member, send to each one, retry a failure, remove a phone that was reset, and keep count. Notifications are sent with your own Apple key and your own Firebase project, held on your WordPress and never uploaded: your site signs a short-lived token, and only that token reaches us.

Media CDN: photos from nearby, not from your host

Avatars, cover photos and the photos members post in albums, chat and activity are stored and served from a global network as members upload them. Image requests stop reaching your host, so the bandwidth and CPU that went on photographs go back to the pages that need them. Every original stays on your own server as well, so turning the service off puts you back where you started.

Video: converted and streamed for every connection

Members post video in feeds, albums, forums and chat, in the app and on your plugins’ own pages. Every upload is converted into a range of qualities, and each member’s player picks the one their connection can carry. Plays are checked against who may watch, so a video in a private group stays private. Optionally, the copy on your WordPress server is removed once a video is streaming, which keeps your hosting disk small.

Insights: views counted off your database

Insights counts post, profile, group, job and video views, reactions, forum activity and chat reply times, for you in WordPress and for each member on their own things. In the app, each member’s device sends its views straight to Memberside. On your website, the view is sent after the page has gone to the browser. Your WordPress database does not write a row per view. We store member ids and item ids, plus gender, country and age range only if you map a profile field to each: never the post, never an IP address, never a device.

The jobs, side by side

What it costs

Each service has its own monthly tiers, and even the smallest covers 5 of your domains. Every tier is a hard cap rather than a meter, so there are no surprise invoices. The Pro and Unlimited plans include a starting allowance of each, enough to try them on your real community.

The full tiers are on the pricing page, and each service has its own page under Products with the details and an FAQ.

Coming next: Advertise

A sixth service is on its way. Advertise lets you run your own campaigns in your community: in the feed, in forums and groups, as a scheduled push and inside your notification emails, with no ad network involved. Unlike the five above, it runs on your own site, and it will be free on every plan. We will write about it properly when it ships.

The short version

A membership site slows down because of the work it does around its pages: asking for news that is not there, sending pushes, serving photos and video, and counting views. Bigger servers and caches help at the edges, and a separate service for each job helps one job at a time. Memberside’s services take those jobs off your WordPress, with the same plugins your app uses, so your site can get back to being the community.