A slow website is rarely one bug. It is a stack of small delays: DNS, TLS, origin CPU, database queries, unoptimized assets, third-party scripts and an undersized plan. This post is a field checklist you can walk in order—distinct from our three-second UX psychology piece and from broad “future of performance” essays. Goal: find the bottleneck, then pick the right EuroVDC product in Sofia (EU).
When the checklist points to shared limits, start or migrate on web hosting. When you need root, workers or reserved RAM, size a cloud server.
Checklist layer 1 — Measure before guessing
- Capture TTFB, LCP and a simple waterfall from a location near your users (TR/SEE → Sofia often wins).
- Test logged-out homepage and one heavy template (shop category, search, dashboard).
- Note whether slowness is global or only on admin/API paths.
Without numbers you will “optimize” the wrong layer for weeks.
Checklist layer 2 — DNS and TLS
- High DNS TTL after a host move can leave clients on the old IP—lower TTL before cutover, raise after stability.
- Missing or mis-chained HTTPS adds redirects and browser warnings that feel like hang time.
- Mixed content blocking can stall critical scripts; fix origins to HTTPS end-to-end.
Checklist layer 3 — Origin and application
- CPU pegged: Plugins, uncached PHP, chatty cron—or neighbours on shared.
- RAM pressure: Swap thrash feels like random multi-second pauses.
- Database: Missing indexes, N+1 queries, oversized autoload options in CMS tables.
- Disk: Full inodes or slow disk I/O on oversized media libraries.
If metrics show sustained CPU/RAM saturation on shared, upsizing the same noisy neighbourhood rarely helps as much as moving to isolated cloud capacity in Sofia.
Checklist layer 4 — Front-end weight
Uncompressed images, render-blocking CSS/JS, tag managers and carousels often dominate LCP even when the server is fine. Compress media, defer non-critical scripts, and kill tags you cannot name an owner for. Server upgrades do not shrink a 4 MB hero PNG.
Checklist layer 5 — Product fit
| Symptom | Likely fit | Next step |
|---|---|---|
| Brochure site, panel OK, mild traffic | Web hosting | Cache, image diet, PHP version |
| Woo/admin slow, need Redis/workers | Cloud (KVM) | Reserved resources + root tuning |
| Good TTFB, bad LCP | Either | Front-end first, not bigger SKU |
| Only distant continents slow | Either + CDN | Sofia origin stays; edge for static |
Sofia EU context
EuroVDC origins in Sofia help Central/South-Eastern Europe and Turkey latency. That improves the network hop; it does not excuse unindexed queries or megabyte scripts. Use location as an advantage after the checklist clears application debt.
Work the list top-down once per incident: measure → DNS/TLS → origin → assets → product. Document what changed so the next slowdown is faster to triage.
Frequently asked questions
Is slow always a hosting problem?
No. Many sites have healthy TTFB and terrible front-end weight. Measure both before buying a bigger plan.
When should I move from hosting to cloud?
When you need isolation, root, Redis/workers or reserved CPU/RAM that shared limits cannot deliver.
Will Sofia alone make my US visitors fast?
It helps regional users most. Distant audiences may still need CDN for static assets.
How is this different from the three-second rule article?
That piece covers UX psychology and bounce risk. This page is an ordered diagnostic checklist and product path.
Do caches replace correct sizing?
Caches hide load until miss storms or admin traffic hit the origin—size for peaks you care about.
Where do I start on EuroVDC?
Run the checklist, then choose web hosting or cloud server based on root and resource needs.
