Useful speed work starts with a slow visitor task, not a list of switches to enable. Choose a page people actually use, such as an article, product listing or contact form, and measure it before changing anything.
Make a repeatable baseline
Record the URL, device, network conditions and test time. Run the same test several times and distinguish a first visit from a cached visit. Check available real-user results as well as a laboratory report; a perfect score on one computer does not describe every customer’s experience.
Our metrics guide explains loading, interaction and layout stability. Use those measurements to choose the next change.
Fix the largest avoidable work first
- Images: resize source images for their actual use, choose an appropriate compressed format and provide responsive sizes. Reserve image dimensions to reduce layout movement. Do not lazy-load the main image a visitor needs immediately.
- Styles and scripts: remove features you no longer use before minifying their files. Defer scripts only after checking their dependencies and interactive behavior.
- Third-party services: review each widget, tracker and embedded player. Load optional tools when needed and test the page when a provider responds slowly.
- Fonts: use only the families and weights the design needs. Check fallback text while the font loads.
Cache carefully
Page caching can reduce repeated work for public pages. Account screens, carts, checkout and other personalized responses need deliberate exclusions. Test an anonymous visitor and a signed-in user separately; a faster page is not an improvement if it exposes another person’s information.
A CDN can bring eligible content closer to visitors. It does not automatically fix slow database queries or every uncached request. Likewise, combining every CSS and JavaScript file can make caching and loading worse in some applications. Measure instead of enabling every optimization at once.
Verify the result and the workflow
After one change, repeat the baseline and complete the original visitor task. Check menus, search, forms, image loading, mobile layout and browser errors. Keep the change only if the result improves without breaking the task.
For a slow initial response, investigate application work and database queries before assuming a hosting upgrade is the answer. Keep a short before-and-after record so a future editor can understand which changes helped.
Applying this checklist on MyLightHost hosting
The MyLightHost shared-hosting page describes LiteSpeed and LSCache on supported hosting. Confirm the stack and enabled features for your selected service; a VPS or another product does not automatically have the same configuration. The hosting layer can help, but large images, slow database queries and third-party scripts still need attention.
For a WordPress site using a supported LiteSpeed cache service, follow the official beginner’s guide. Start with a known-good backup and conservative settings. Confirm that the page is actually being cached rather than assuming that installing the plugin activates server caching. LiteSpeed distinguishes its optimisation functions from caching features that need a supported cache engine.
Test public pages and personalised pages separately after each change. Check sign-in, cart, checkout and account areas so one visitor never receives another visitor’s content. Keep a short before-and-after record: tested URL, device, time, loading experience and whether the real action still works. Do not promise a particular score or speed increase from enabling a feature.
If the site repeatedly reaches application limits, compare measured usage with the hosting resource checklist. Ask Technical Support about the exact service with an affected URL, timing and redacted error details; do not send credentials.
MyLightHost-specific section reviewed 14 September 2026 against the linked product page and official LiteSpeed documentation. Features remain plan-specific.