Uncached routes · Property Management Sites
Web hosting for property managers — The half of your site that no cache will ever help
Your public pages are cached and quick; your resident portal, document area and maintenance form are none of those things, and they are what people actually use.
The short answer
Measure the authenticated half of the site, because that is where a property management site actually lives. Resident logins, maintenance reporting, service-charge documents and owner areas are all logged-in traffic, and logged-in traffic is uncacheable by design — every request boots PHP, runs your queries and occupies a worker until it finishes. A Lighthouse run on your public homepage tells you nothing about any of it.
The layer that helps there is object caching plus a shorter plugin list, not a page cache that cannot apply. Underneath, every tier runs NVMe storage with free SSL, free migration, mailboxes on your own domain and support at any hour.
By the HostingFast team · Reviewed 24 August 2026
NVMe
Disk class on all plans
Free
First-year name on annual plans
99.9%
Availability commitment
Flat
Renewal price behaviour
Property management is judged on responsiveness, and the website is where residents form that judgement first. That places the performance requirement in an awkward spot: on the pages behind a login, which are the hardest to cache and the least likely to be measured.
There is a second requirement that is not a speed metric at all. A maintenance report with three photographs attached has to complete — on a phone, on a landing's worth of signal, from somebody standing next to the leak. Upload reliability is a performance characteristic even though no page-speed tool reports it.
Both are testable. Below: how to time the authenticated routes, how to make uploads survive a bad connection, and what to watch over a weekend when nobody is at a desk.
Time the logged-in routes as themselves
Log in as a resident, open DevTools, and record how long the portal home, the document list and the maintenance form take. Those numbers are your real performance figures. They will be materially worse than your public pages and that is expected — the page cache is not applied to authenticated requests, so nothing is cushioning them.
What moves them is different from what moves a public page. An object cache holding repeated query results helps immediately, and the managed WordPress tiers ship Redis object caching and AccelerateWP for exactly this. Beyond that, look at how many plugins load their own assets on every portal page: membership plugins are frequently the heaviest thing on a site that otherwise has no heavy pages.
Make the upload survive the landing
A maintenance form with photo upload is the most failure-prone request on the site. It is large, it is slow, it is being sent from a phone with poor signal, and it is the one thing a resident will not attempt twice. Check the practical limits before anything else: maximum upload size, script execution time and the form plugin's own cap, because a mismatch between them produces a failure with no useful message.
Then reduce what has to travel. Client-side resizing before upload turns a 6 MB photograph into a few hundred kilobytes without any visible loss for the purpose, which is the single most effective change available. Test the whole flow on a throttled connection rather than on office wi-fi, and confirm the resident sees a clear result whether it succeeded or failed.
Weekends, and what a monitor can see
The reports that matter most arrive when nobody is at a desk, so the site has to be observably up rather than assumed up. Point an uptime check at a route that cannot be served from cache and assert on content as well as status — a cached public page will keep returning a healthy 200 while the portal behind it is unreachable, which is precisely the outage you need to know about.
Then confirm the notification path. A maintenance report that is stored but never emailed is functionally a report that never happened. Send a real test through the live form, read the received headers to confirm SPF and DKIM pass, and repeat after any DNS change. Domain mailboxes come with every plan and outbound goes through MailChannels.
Keep the timestamped trail
This trade runs on documented correspondence, which makes the reliability record part of the product. Keep a short monthly note: the portal response times you measured, the month's uptime figure from your own monitor, and any failed submission you know about. It takes minutes and it is the difference between a defensible account and a recollection.
We target 99.9% uptime, monitored around the clock, and if a month falls short through a fault on our side the terms provide a pro-rated credit. Daily backups restore from the panel in minutes when the cause turns out to be something that shipped on a Friday.
Where a page cache stops helping
Public pages are cached by LiteSpeed inside the web server and cost almost nothing. Everything behind a login is uncached by design, which is why NVMe storage on every tier matters more here than on a brochure site.
Object caching, a current PHP runtime and a shorter plugin list are the levers that move authenticated routes. Staging and daily restores let you pull a membership plugin apart safely.
- NVMe storage under every tier for uncached routes
- Domain mailboxes with MailChannels on outbound
- A 99.9% availability target with monitoring behind it
- Daily backups you can roll back to from the control panel
Why HostingFast
Standard on every plan
Fast storage where it counts
Authenticated pages never see the page cache, so the disk and database path underneath them is the whole performance story. NVMe on every tier.
Object caching available
The managed WordPress tiers ship Redis and AccelerateWP — the layer that actually helps portal pages a page cache cannot touch.
Notifications with infrastructure behind them
Domain mailboxes plus MailChannels on outbound, so a maintenance notification has infrastructure behind it as well as a plugin.
Monitoring that sees the portal
Point a check at an uncacheable route with a content assertion and an outage stops being able to hide behind a warm public page.
A target with a credit behind it
99.9%, monitored around the clock, with a pro-rated credit under our terms if a month falls short through a fault on our side.
Recovery measured in minutes
Daily backups recover files, a database or both from the panel — the safety net for taking a membership plugin apart on a Tuesday.
Quick Start
From order to online
- 1
Measure while logged in
Portal home, document list, maintenance form. Those three numbers describe the site your residents use, and none of them appear in a public speed test.
- 2
Test the upload on a bad connection
Throttle the network, attach three photographs, and confirm limits agree with each other. Client-side resizing first if the sizes are large.
- 3
Prove the notification arrives
Real submission through the live form, then read the received headers for SPF and DKIM. Repeat after every DNS change rather than assuming.
Built In
Loaded onto every plan
- Portal home, document list and maintenance form timed while logged in
- Object caching considered specifically for the authenticated routes
- Plugins loading assets on every portal page identified and trimmed
- Upload size, execution time and form plugin caps checked for agreement
- Client-side image resizing applied before upload where possible
- The whole upload flow tested on a throttled mobile connection
- Uptime monitor pointed at an uncacheable route with a content assertion
- Maintenance notification delivery verified with SPF and DKIM passing
- 99.9% uptime target, monitored around the clock, credit if missed
- A short monthly record kept of response times and uptime figures
Frequently Asked
What people ask us most often
Why is our resident portal slower than the public site?
Because logged-in requests are excluded from the page cache by design — serving one resident's portal page to another would be far worse than serving it slowly. Every authenticated request therefore runs PHP and hits the database with nothing cushioning it. That is normal; what is fixable is the object cache, the PHP version and how many plugins load their assets on every portal screen.
A resident's photo upload keeps failing. Where do I start?
With the limits, because they usually disagree. Check the maximum upload size, the script execution time and the form plugin's own cap; a photograph that passes one and fails another produces a silent failure with no useful message. Then add client-side resizing so a 6 MB phone photograph becomes a few hundred kilobytes before it is ever sent.
Where should service-charge documents actually live?
Behind authentication on your own domain, so access is controlled and revocable, rather than on a shared link that gets forwarded. That does mean those pages are uncacheable, so measure them: a document list that queries per file will slow down as the archive grows. Paginate it, and time it again once there are two years of documents in there rather than two months.
How do I know the site was up over a weekend?
By having a check that could have seen it fail. Point an external monitor at a route excluded from the cache, run it every minute, and assert on a string that only appears when the page genuinely rendered. Then keep the monthly figure. Our platform is monitored around the clock against a 99.9% target, but the check that knows whether your portal is rendering has to be yours.
Keep reading
Streamers & Content Creators — Hosting Guide
Peaky traffic and logged-in pages: two workloads a page cache cannot smooth.
Taxi Firms — Hosting Guide
Dispatch systems, live tracking and the uncached requests behind a booking.
Best Hosting With Free SSL
Certificates that reissue themselves, and how to verify one from the shell.
Web Hosting — Built for Property Managers
What every tier includes, from storage class to the migration engineers run for you.
PHP Hosting
PHP runtime versions, OPcache and what they cost on authenticated routes.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Measure the pages behind the login.
NVMe on every tier for the uncached routes, domain mailboxes with MailChannels behind the notifications, and uptime monitored round the clock.
View Web Hosting — Built for Property Managers plans