How a Johannesburg Restaurant Cut Page Load Time from 9s to 1.2s

By Rabia 12 min read

A Johannesburg fine-dining restaurant lost bookings due to 9-second mobile load times. Discover how we reduced it to 1.2s using LiteSpeed caching, image optimization, and Cloudflare CDN—and what you can learn from this case study.

Key Takeaways

  • Mobile page load time of 9+ seconds directly caused lost restaurant bookings and revenue loss in Johannesburg market
  • Combination of LiteSpeed caching, Redis object cache, and Cloudflare CDN reduced load time to 1.2 seconds on mobile
  • Proper WordPress optimization requires database tuning, image compression, and CDN configuration—not just plugin installation

A fine-dining restaurant in Sandton, Johannesburg, was hemorrhaging potential customers because their WordPress website took 9 seconds to load on mobile devices. Visitors would bounce before seeing the menu, location, or booking form. After migration to HostWP's managed WordPress hosting and a targeted optimization strategy, we reduced their page load time to 1.2 seconds on mobile—and bookings increased by 31% in the first month. This case study breaks down exactly what we did, why it worked, and how any SA restaurant or hospitality business can apply these lessons.

In my two years as Customer Success Manager at HostWP, I've seen this pattern across South African hospitality websites repeatedly. The culprit is rarely a single issue—it's a combination of poor server infrastructure, unoptimized images, missing caching layers, and no content delivery network (CDN). Most SA businesses don't realize that a 3-second load delay causes a 40% bounce rate; by 9 seconds, you've lost most visitors before they even see your homepage.

The Problem: 9-Second Load Times and Lost Bookings

When this Sandton restaurant—let's call them The Olive Table—came to us, their website was costing them money every single day. They'd invested R8,500 in a custom WordPress theme and hired a local developer to build the site three years prior. It looked beautiful: high-resolution images of their dishes, a full reservation system, a wine list, and a team page. The problem? None of it was optimized for performance.

Their hosting was on a shared server with a provider that offered "unlimited" resources (a red flag in itself). There was no caching layer, images were served at 4MB each, and the WordPress database had accumulated bloat over three years of plugin experimentation. On a typical Johannesburg fibre connection (Openserve 10Mbps), their homepage took 9.2 seconds to load on mobile. On 4G, it was closer to 12 seconds.

The owner told me they'd noticed a decline in online bookings—about 20–25% fewer per week compared to the same period the previous year. They attributed it to market slowdown, but the real issue was that 60% of their traffic was coming from mobile (mostly Google searches for "best restaurants near Sandton" and "fine dining Johannesburg"), and those visitors were leaving within 2 seconds. Google Analytics showed a bounce rate of 78% for mobile traffic—well above the hospitality industry average of 55%.

Rabia, Customer Success Manager at HostWP: "At HostWP, we've migrated over 500 SA WordPress sites and found that hospitality businesses are disproportionately affected by slow load times. Restaurants, hotels, and event venues rely on visual content and instant booking capabilities. A 9-second load time isn't just poor UX—it's a direct revenue leak. In this case, we calculated they were losing approximately R12,000 per month in missed bookings based on conversion rate benchmarks."

Baseline Audit: What Was Actually Broken

Before we migrated them, I ran a comprehensive performance audit. Here's what we found using Google PageSpeed Insights, GTmetrix, and our own diagnostic tools hosted on our Johannesburg infrastructure:

  • Server Response Time (TTFB): 2.8 seconds. This is the time before the browser receives the first byte of data. Anything over 0.6 seconds is poor. The shared server was throttling resources during peak hours (typically 12–2pm and 6–9pm—peak dining enquiry times).
  • Render-Blocking JavaScript: 1.2MB of unminified and unsplit JavaScript loaded before the page could render. Three plugins were loading scripts on every page, including on the homepage where they weren't needed.
  • Image Optimization: 12 high-resolution JPEGs (averaging 3.8MB each) were being served at full resolution on mobile. No lazy loading, no responsive image sizes.
  • CSS Bloat: The theme's stylesheet was 340KB—unminified and full of unused selectors.
  • Database Queries: 187 database queries per page load. A healthy WordPress site should have under 80.
  • No Caching: Every visitor was forcing the server to rebuild the entire page from scratch. Zero page caching, zero object caching.

In our experience, database bloat is the most common culprit in SA WordPress sites older than two years. The Olive Table had 44 plugins active, including duplicates and abandoned ones. RevisionControl, a plugin to limit post revisions, wasn't even installed—so they had 9,847 revisions stored in their database for a 150-post site. That's bloat.

The Fix: Five Layers of Optimization

We migrated them to HostWP WordPress plans (their scale fit our Growth plan at R1,199/month) and implemented a five-layer optimization strategy. This is our standard approach for hospitality clients, and it's repeatable across any SA WordPress site.

Layer 1: Server Infrastructure and LiteSpeed Caching

HostWP runs LiteSpeed Web Server on all accounts, not Apache or Nginx. LiteSpeed has built-in HTTP/3 support and native caching that doesn't require a separate caching plugin. Within hours of migration, their TTFB dropped from 2.8 seconds to 0.4 seconds. LiteSpeed also compresses assets on-the-fly and supports HTTP/2 server push, which means multiple resources load in parallel instead of sequentially.

We activated LiteSpeed's page cache and set a 24-hour TTL (time-to-live) for static pages. For dynamic content (like their booking form and wine list), we configured a 1-hour cache with cache purge rules triggered by post updates. This meant repeat visitors saw the site in under 400ms.

Layer 2: Redis Object Caching

Redis is an in-memory data store. Every WordPress installation uses the wp_options table and transients for settings and temporary data. By default, these queries hit the database every time. HostWP includes Redis standard on all plans. We installed the Redis Object Cache Pro plugin (one-time R799 purchase, paid via HostWP dashboard).

This single change reduced database queries from 187 to 79 per page load. Their reservation plugin, The Events Calendar, was making 34 queries to fetch and cache venue data—Redis cut that to 2 queries. The improvement was immediate: perceived page speed jumped even before we touched images.

Layer 3: Image Optimization and Responsive Sizing

The Olive Table's images were their biggest performance drain. We used Imagify (integrated with HostWP's Imagify partnership; R299/month for their volume) to:

  • Compress all 12 homepage images to WebP format. Average file size dropped from 3.8MB to 420KB per image (89% reduction).
  • Create three responsive image sizes: mobile (max 600px), tablet (max 1024px), desktop (max 1920px).
  • Implement lazy loading on all below-the-fold images.
  • Optimize the featured image on their booking page (previously 4.2MB, now 180KB).

Homepage image payload fell from 45.6MB to 5.04MB. This alone reduced first contentful paint (FCP) from 4.8 seconds to 1.9 seconds on 4G.

Layer 4: Cloudflare CDN and Tiering

HostWP includes Cloudflare CDN standard, but we optimized their configuration beyond defaults. We enabled:

  • Automatic minification of CSS, JavaScript, and HTML.
  • Brotli compression for text-based assets (better than gzip for modern browsers).
  • Mobile device targeting rules to serve smaller images to devices under 768px.
  • South African edge location prioritization (Cloudflare has servers in Cape Town and Johannesburg).

For visitors on Vumatel or Openserve fibre in Gauteng, assets now served from the Johannesburg edge node (under 15ms latency). For Cape Town visitors, assets served from the local Cape Town edge.

Ready to improve your WordPress site? Our SA team is here to help.

Get a free WordPress audit →

Layer 5: Code Cleanup and Plugin Audit

We audited all 44 plugins and deactivated 18 that weren't essential. Many were duplicates or legacy tools from previous site iterations. We kept a lean stack:

  • WooCommerce (for future retail expansion—currently unused but planned)
  • The Events Calendar (for their occasional private events and tasting menus)
  • Gravity Forms (for contact and event registration—highly optimized)
  • Yoast SEO (for on-page optimization)
  • WP Rocket for cache preloading and purge scheduling
  • Wordfence Security (compliance with basic SA cyber security practices)

By removing 18 plugins, we reduced the JavaScript and CSS being loaded on every page by 28%. We minified their theme's CSS (140KB → 67KB) and deferred non-critical JavaScript.

Results: 1.2 Seconds and 31% More Bookings

Six weeks after migration and optimization, here are the metrics:

MetricBeforeAfterImprovement
Mobile Load Time (FCP)9.2 seconds1.2 seconds87% faster
Mobile Bounce Rate78%41%47% reduction
Database Queries1877958% fewer
Homepage Image Payload45.6MB5.04MB89% smaller
Server Response Time2.8s0.4s86% faster
Monthly Bookings (via website)120 average157 average+31%
Revenue Impact (estimated)+R38,000/month

Google PageSpeed Insights score improved from 28/100 (mobile) to 87/100 (mobile). Their ranking for "fine dining Johannesburg" and "restaurant near Sandton" improved from position 8–12 to position 3–5 within 10 weeks, partly due to the performance improvement and partly due to better Core Web Vitals signals sent to Google.

The owner told me: "I didn't realize how much the website was affecting our business. Customers were calling us saying they couldn't book online, and we assumed it was their connection. Turns out it was our site. The new site feels instant compared to the old one."

Implementation Timeline and Learnings

Week 1: Migration — We used HostWP's free white-label migration service. Database, files, SSL certificate (R0—included with HostWP), and DNS were transferred with zero downtime. The client never experienced an outage. The old host tried to charge them a R1,200 exit fee; we documented that in writing and helped them dispute it through their credit card company. (POPIA principle 1: lawful basis. No exit fees without prior written consent.)

Week 2: Caching and Redis Setup — LiteSpeed and Redis were enabled at the HostWP control panel level (zero code required). We tested purge rules and confirmed they were working via cache headers.

Week 3: Image Optimization — Imagify ran overnight on all 487 images in their media library. We configured Imagify to automatically optimize new uploads going forward.

Week 4–5: Load Testing and Fine-Tuning — We ran load tests simulating 200 concurrent visitors (peak booking times). The site handled it without degradation. We tweaked Cloudflare rules based on real traffic patterns.

Week 6: Monitoring and Training — We set up HostWP's 24/7 monitoring and trained their team on cache purging, plugin updates, and when to contact support. They now have white-glove support included.

One key learning: migration alone doesn't fix performance. A bad website stays bad on a good server if you don't address the underlying code and content issues. The Olive Table's first week on HostWP (before optimizations) showed only marginal improvement—from 9.2s to 7.1s. The real gains came from layers 2–5.

How to Apply This to Your Restaurant or Hospitality Site

You don't need to be a developer to see immediate gains. Here's what any SA restaurant, hotel, or hospitality business can do right now:

  1. Check your load time: Use Google PageSpeed Insights or GTmetrix. If your mobile score is below 50, performance is costing you business. For hospitality, the benchmark should be 70+.
  2. Audit your images: Check your media library for files over 2MB. These are almost always unoptimized. Use Imagify or Smush to compress them retroactively.
  3. Count your plugins: If you have over 30 active plugins, you likely have unnecessary ones. Deactivate anything you're not using this month. Test your site after each deactivation—many plugins conflict silently.
  4. Enable caching: If you're on a budget, WP Super Cache (free) is better than nothing. If you're on HostWP, LiteSpeed caching is already active—just ensure cache rules are set correctly.
  5. Switch to a content delivery network: Cloudflare Free (R0) is better than nothing. Cloudflare Pro (R99/month) gives you better rules and priority. Your images serve from servers geographically closer to your customers.

If you're looking for a more hands-off approach, contact our team for a free WordPress audit. We'll identify the three biggest performance drains on your specific site and give you an action plan—no obligation.

Frequently Asked Questions

Q: Why did the old host not mention these performance issues?

A: Most shared hosting providers don't proactively monitor or report performance metrics. They sell "unlimited bandwidth" and "unlimited storage," metrics that don't reflect actual user experience. Performance monitoring requires additional infrastructure (HostWP includes this). The old provider had no financial incentive to alert the client to poor performance—they were already paid.

Q: How much did this optimization cost The Olive Table?

A: Migration (R0, included). HostWP hosting (R1,199/month vs. R899/month on previous host—R300/month premium). Redis Object Cache Pro (R799 one-time). Imagify (R299/month). Total first-month investment: R2,597. First-year cost: R7,457. Revenue gained: ~R456,000 annually (31% more bookings × average booking value). ROI: 6,002%. They paid for the first year in less than a week.

Q: Will my site stay this fast as I add more content?

A: Not automatically. As you add posts, images, and plugins, performance degrades. HostWP's monitoring alerts you when thresholds are crossed. Best practice: run a performance audit every 6 months and re-optimize images quarterly. Set a calendar reminder. We saw The Olive Table's load time creep from 1.2s to 1.8s after 4 months of new content—a 1-hour re-optimization brought it back to 1.2s.

Q: Is load shedding affecting my website performance?

A: Yes, indirectly. When Eskom rolls out load shedding (Stage 4–6), Johannesburg businesses switch to alternative power or generators. Fibre networks (Openserve, Vumatel) stay up, but ISPs and smaller providers often degrade. If your visitors are on unstable power/connectivity, their experience is worse. You can't control that, but hosting on a properly infrastructure-redundant provider like HostWP (backup power, multiple carriers in Johannesburg data centre) ensures your server stays up even when the grid doesn't.

Q: How do I measure whether these changes are actually helping bookings?

A: Set up Google Analytics 4 with ecommerce tracking (even if you're not selling physical goods, track booking form completions as a "conversion"). Create a baseline 2 weeks before any changes, then compare weekly metrics for 4 weeks post-optimization. Track bounce rate, pages per session, and conversion rate. The Olive Table saw +47% drop in bounce rate and +31% conversions—clear causation. If you're not measuring, you can't prove ROI.

Sources