Why Your Website Is Slow — And What's Actually Causing It
A one-second delay in page load time reduces conversions by 7%. That number comes from a Deloitte study on retail sites, but it holds across industries. If your website takes four or five seconds to load on mobile, you’re not just losing visitors — you’re paying to acquire them and then watching them leave before they see anything.
The frustrating part is that most business owners don’t know their site is slow. It loads fine on their work laptop over fiber. They check it once, it looks okay, and they move on. Meanwhile, someone on a mid-range Android phone in Surabaya hits the same URL over LTE and waits six seconds staring at a blank screen.
So what’s actually causing it?
Unoptimized Images
This is the single most common culprit. A designer exports a hero image at 4000×2500 pixels, 3.2 MB, JPEG. That file gets uploaded directly to the CMS with no compression, no resize, no format conversion. The browser downloads the whole thing before it can render anything useful on screen.
The fix isn’t complicated — images should be served in WebP or AVIF format, sized to the actual display size, and lazy-loaded below the fold. A hero image should rarely exceed 200 KB. Most sites are serving 10× that.
Render-Blocking JavaScript
Modern websites load a lot of JavaScript — analytics, chat widgets, cookie banners, marketing pixels, A/B testing libraries. Each one of these can block the browser from rendering the page until it’s finished loading and executing.
The browser has to stop, fetch the script, parse it, run it, then continue building the page. If you have five of these in your <head>, you’ve stacked five sequential blocking operations before the user sees a single pixel of content.
The right approach is deferring non-critical scripts so they run after the page is visible. Most sites don’t do this.
WordPress Plugin Bloat
WordPress has 60,000+ plugins, and agencies love to use them. Need a contact form? Plugin. Need SEO? Plugin. Need social sharing? Plugin. Each plugin adds JavaScript, CSS, database queries, and sometimes additional HTTP requests on every page load.
A typical WordPress site built by a generalist agency runs 30–50 active plugins. Each one adds overhead. Some conflict with each other. Many load resources on pages where they’re not needed. The result is a site where the hosting provider is fast but the site itself is slow — because you’re loading half of npm on every page.
This isn’t an argument against WordPress. It’s an argument against lazy WordPress implementations.
Cheap Shared Hosting
Shared hosting means your site lives on a server with hundreds of other sites. When your neighbors get traffic spikes, your server resources get squeezed. Time to First Byte (TTFB) — the time from the browser sending a request to receiving the first byte back — can spike to 800ms or more on busy shared hosts.
TTFB should be under 200ms. Some premium hosts hit 50ms consistently. On cheap shared hosting, you’re starting every page load with a 600–800ms penalty before any assets are transferred.
No CDN or Caching Layer
If your server is in Singapore and a visitor is in Jakarta, that’s a short hop. If a visitor is in Surabaya, Medan, or Makassar — or anywhere outside Southeast Asia — the physical distance adds real latency for every asset.
A CDN (Content Delivery Network) caches your static assets at edge nodes distributed globally and serves them from the closest location. Without one, every image, every font file, every CSS file travels from your origin server for every visitor.
What Good Performance Actually Looks Like
A well-built site should score 95+ on Lighthouse (Google’s performance audit tool). More concretely:
- LCP (Largest Contentful Paint): under 1.5 seconds — this is how long until the main content is visible
- FID / INP: under 100ms — responsiveness to user input
- CLS (Cumulative Layout Shift): under 0.1 — no elements jumping around as the page loads
Reaching these numbers isn’t about obsessive optimization. It’s about building correctly from the start: serving optimized assets, minimizing render-blocking resources, using a CDN, and choosing the right architecture for the use case.
Static-first approaches — where pages are pre-built at deploy time rather than generated on every request — eliminate server-side rendering time entirely. A static page served from a CDN edge node is the fastest possible web architecture.
The Business Case
Faster sites rank better in search (Google explicitly uses page speed as a ranking signal). They convert better. They retain visitors longer. On mobile — which is the majority of web traffic in Indonesia — the difference between 2 seconds and 6 seconds is the difference between a potential customer and a bounce.
Performance isn’t a technical luxury. It’s a business metric.
At Pelita Studio, performance is baked into how we build — not something we bolt on afterward. Every site we ship is tested against Lighthouse, optimized for mobile, and served from infrastructure designed to keep load times under two seconds regardless of where the visitor is.
If your current site is slow and you’re not sure why, we can audit it and show you exactly what’s causing the problem.