Begin with your workload, not a hosting plan
List the journeys that create value or risk: first visit, search, sign-in, product detail, form submission, checkout, editor update, or API call. For each, record peak requests or concurrent users, payload, personalization, dependencies, and visitor regions. Include scheduled and admin work because it consumes the same resources.
Turn the list into acceptance measures. Largest Contentful Paint, or LCP, measures main-content loading; Interaction to Next Paint, or INP, responsiveness; and Cumulative Layout Shift, or CLS, unexpected movement. Google describes good targets as LCP within 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. Add route completion, server response time, and error-rate targets.
Do not let a fast cached page stand in for an authenticated or database-backed transaction.
Define peak period, expected growth, campaign spikes, and overlapping batch work.
Mark whether the host, your team, or a third party controls each likely bottleneck.
Compare capacity, limits, and scaling behavior
Ask for limits behind the offer: compute and memory, storage performance, database connections, worker limits, network charges, request controls, and shared-neighbor constraints. “Unlimited bandwidth” does not show whether the app can perform enough uncached work at a peak. Ask which metrics are visible and how long they remain available.
Scaling matters only when its trigger, delay, ceiling, and price are known. Confirm whether it is automatic, whether sessions and jobs remain safe, and what happens at the ceiling. Prefer a test at the expected peak and beyond it to a theoretical capacity claim. Headroom is a business decision, not a universal percentage.
Compare p95 or p99 response time, not only an average.
Collect database, queue, and upstream API timing during the test.
Estimate scale, delivery, backup, and second-region costs before committing.
Place the origin deliberately and validate delivery
Choose an origin region using audience location, application dependencies, data-location needs, and operating access. Test from representative geographies and network conditions. A content delivery network, or CDN, is a distributed cache that can serve eligible assets nearer visitors and reduce origin work; it does not replace a healthy origin, database, or application.
Inspect headers and behavior, not only a dashboard setting. Versioned static assets can usually have longer lifetimes because an update has a new URL. Dynamic and personalized responses need explicit rules. HTTP distinguishes shared from private caches; account details must not become reusable by another customer. Rehearse a cache purge and rollback.
Capture a first visit and a return visit because cache states differ.
Verify Cache-Control and cache keys for pages, assets, cookies, parameters, and locale.
Document how authorized staff disable a harmful rule without exposing sensitive content.
Treat recovery evidence as a performance requirement
Ask what is backed up, where copies live, retention, restore authority, and whether backups cover databases, uploads, code, configuration, and infrastructure. Define recovery point objective, or RPO, as acceptable data loss in time, and recovery time objective, or RTO, as acceptable restoration time. Set both from business consequences, not a package default.
A successful backup is not recovery proof. CISA recommends scheduled recovery tests, and AWS says disaster recovery should be assessed and tested. Restore a recent copy in isolation, check important records and media, use the documented sequence, and record elapsed time. An alternate region can reduce some risks but adds cost and complexity.
Recover one file or record without overwriting current data.
Limit restore access and keep recovery credentials and runbooks available to authorized responders.
A database snapshot may not recreate settings, application versions, or delivery rules.
Evaluate support and shared responsibility before you need it
Compare support scope, hours, channels, escalation, and the difference between platform incidents and application troubleshooting. Get written responsibility for patches, managed databases, TLS, firewall rules, backups, and restoration. A support promise is useful when it names the owner and next action in a realistic scenario.
Review access roles, multi-factor authentication, audit logs, secret handling, and account isolation. For payment cards or sensitive regulated data, hosting features alone do not establish compliance. Use this comparison as technical input and obtain qualified security, legal, or compliance review of the payment architecture and applicable obligations.
Ask how the provider handles a failing restore, saturated database, or harmful cache rule.
Check who can change production, read backups, view logs, and create credentials.
Service credits and managed coverage can have material conditions.
Run realistic, safe comparison tests and keep the scorecard
Use the same release, configuration intent, and test script for every candidate. Run a baseline, expected peak, short spike, sustained period, and safe recovery or deployment exercise. AWS recommends production-like environments, defined scenarios, architecture-wide monitoring, sanitized or synthetic data, and regular retesting. Get provider approval and follow its testing policy.
Combine controlled lab tests with field data after launch. Lab tests are repeatable for debugging; field data reflects real devices, networks, geography, cache state, and behavior. Revisit the scorecard after major releases or dependency changes. SIU can turn findings into pre-launch hardening, owner-assigned remediation, and rollback-ready improvements.
Keep locations, concurrency, cache state, and payloads consistent.
Save route timings, errors, resource metrics, versions, costs, and observations.
Select the option meeting documented needs at a sustainable operating cost.