Based on comprehensive analysis of server response, rendering path, asset delivery, and WordPress configuration.
The gymbox.com website is experiencing severe performance issues across multiple layers of the technology stack. The site is built on WordPress 6.9.1 with the Hello Elementor theme, which is generating significant frontend bloat. The server response time (TTFB) is averaging 1.9 seconds — nearly 10x slower than the recommended 200ms target. The browser must download 24 CSS files and 21 JavaScript files before the page can render, of which 22 CSS files are Elementor-generated and 21 JS files are render-blocking. jQuery appears to be loaded five times. WordPress emoji scripts are still active despite not being used. Cloudflare is present but page caching is not enabled (cf-cache-status: DYNAMIC), meaning every request hits the origin server. These issues compound to produce an estimated PageSpeed mobile score of approximately 34/100.
The good news: every one of these issues is fixable. Based on our analysis, we estimate that comprehensive optimisation could achieve a PageSpeed mobile score of 95-100, with load times under 1.5 seconds and all Core Web Vitals passing. The site has strong content and design — it just needs the technical foundation to match.
Core Web Vitals are Google's page experience ranking signals. Failing these metrics directly impacts your search visibility.
These issues are causing the most significant performance impact and should be addressed first.
Every JavaScript file on the page is render-blocking, meaning the browser cannot paint any content until all 21 scripts have been downloaded, parsed, and executed. This alone adds an estimated 2-3 seconds to the initial render time. Scripts should be deferred or loaded asynchronously, with only critical above-fold scripts remaining synchronous.
Time to First Byte is averaging 1.9 seconds, with one test hitting 3.4 seconds. The industry target is under 200ms. This means the server is taking nearly 2 seconds just to start sending HTML — before a single CSS file, image, or script begins downloading. This is likely caused by a combination of no effective page caching (Cloudflare shows DYNAMIC, not HIT), unoptimised PHP execution, and potentially slow database queries.
The Hello Elementor theme combined with Elementor Pro is generating 22 separate CSS files. Each file is a separate HTTP request that must be downloaded before the page can render. The majority of CSS in these files is unused on this specific page — typically 60-80% of Elementor's CSS is not needed. This should be consolidated into a single optimised stylesheet with unused CSS removed.
jQuery (87KB minified) appears to be loaded multiple times by different plugins or theme components. This wastes bandwidth, increases parse time, and can cause JavaScript conflicts. jQuery should be loaded exactly once, and ideally removed entirely from the frontend if no critical functionality depends on it.
Cloudflare is active on the domain but is not caching HTML pages at the edge. Every request hits the origin server, which is why TTFB is so high. Enabling Cloudflare's page caching (via APO or page rules) would serve the entire HTML from Cloudflare's edge network, reducing TTFB to under 50ms for cached requests.
WebP images are 25-35% smaller than equivalent JPEG files and 60-80% smaller than PNG. Converting all images to WebP with proper compression would significantly reduce page weight and improve LCP (Largest Contentful Paint), especially on mobile connections.
WordPress loads emoji detection and rendering scripts on every page by default. Unless the site specifically uses WordPress emoji (unlikely for a gym website), these scripts add unnecessary JavaScript parsing time and an additional HTTP request. They should be removed.
The HTML document is nearly 3x larger than recommended. This is likely due to Elementor's inline styles, excessive DOM nesting, and potentially inlined SVGs or base64 images. A leaner HTML structure would improve initial parsing speed and reduce TTFB.
Four images on the page don't have the loading="lazy" attribute. Below-fold images should be lazy loaded to prevent them from competing with critical above-fold content for bandwidth.
The WordPress version is publicly visible, which is a minor security concern. Removing the generator tag, REST API link, and oEmbed discovery links from the head reduces HTML size and removes unnecessary information disclosure.
The site loads scripts from 6 different third-party domains. Each domain requires a DNS lookup, TCP connection, and TLS handshake before the script can download. Consider self-hosting critical scripts, deferring non-essential third parties, and evaluating whether all six are necessary.
A step-by-step implementation plan specific to gymbox.com, ordered by impact.
Configure Cloudflare to cache the full HTML at the edge via APO or custom page rules. This single change will reduce TTFB from 1.9s to under 50ms for the majority of visitors. Set proper cache-control headers and bypass rules for logged-in users and dynamic pages.
Audit all 21 JavaScript files. Defer every non-critical script. Consolidate jQuery to a single load (or remove entirely). Eliminate render-blocking resources so the browser can paint content immediately while scripts load in the background.
Extract critical above-fold CSS and inline it in the document head. Consolidate Elementor's 22 CSS files into a single stylesheet. Remove the 60-80% of CSS that's unused on each page. Load the remaining CSS asynchronously.
Verify PHP 8.3 OPcache is properly configured. Implement Redis object caching for database queries. Configure proper cache headers. Enable Brotli compression. Ensure HTTP/2 is active for parallel resource downloading.
Convert all 13 non-WebP images to WebP format. Implement responsive srcset attributes. Add lazy loading to all below-fold images. Preload the LCP image with fetchpriority="high". Configure automatic WebP conversion for future uploads.
Remove emoji scripts, generator tag, oEmbed links, and REST API discovery. Audit all active plugins and remove those not contributing to frontend functionality. Clean the database of post revisions, expired transients, and bloated autoloaded options.
Based on our experience optimising 150+ WordPress sites with similar technology stacks.
| Metric | Current | After VeloPress |
|---|---|---|
| PageSpeed Mobile | ~34 | 95–100 |
| TTFB | 1.9s | < 200ms |
| Largest Contentful Paint | ~6.2s | < 1.5s |
| Cumulative Layout Shift | ~0.18 | < 0.05 |
| Interaction to Next Paint | ~580ms | < 150ms |
| HTML Size | 134KB | < 50KB |
| CSS Files | 24 | 1–2 |
| JS Files | 21 | 3–5 |
| Render-Blocking Resources | 21 | 0 |
| Image Format | PNG/JPEG | WebP/AVIF |
| Page Cache | None | Edge (Cloudflare) |
| Total Load Time | ~3.4s | < 1.2s |
Every site is different. Our pricing is based on your current score and site complexity — enter your URL to get an instant quote with a performance guarantee.
Free audit. Instant quote. No obligation. Score guarantee included.