Measure before optimizing
Performance work should start with evidence. Test representative pages on mobile and desktop, then look at real bottlenecks such as slow server response, oversized images, render-blocking CSS, large JavaScript bundles, or third-party scripts.
A fast homepage does not guarantee that service, blog, login, or contact pages are fast. Test the templates that users actually visit and repeat tests after changes.
- Measure more than one page.
- Test on a slower mobile connection as well as broadband.
- Record a baseline so you know whether a change helped.
Optimize images for the displayed size
Images are often the largest assets on a business site. Serving a multi-megabyte photo where the layout displays a small card wastes bandwidth and delays the useful content.
Use modern formats when appropriate, resize source images close to their display dimensions, provide responsive variants for large hero images, and lazy-load images that begin below the fold. The main above-the-fold image may need eager loading instead.
- Do not lazy-load the main hero image if it is the largest visible element.
- Set width and height attributes to reduce layout shifts.
- Compress images before upload rather than relying only on browser scaling.
Keep CSS and JavaScript intentional
Every stylesheet and script has a cost: bytes must be transferred, parsed, and potentially executed. Remove libraries that are no longer used, avoid loading admin code on public pages, and defer non-critical JavaScript.
Be especially careful with duplicate navigation scripts, sliders, trackers, chat widgets, and multiple font requests. Small scripts can still create main-thread work when many of them run at startup.
- Load page-specific code only where needed.
- Defer non-critical scripts.
- Avoid loading the same CSS file more than once on a page.
Configure browser caching and compression
Static files such as CSS, JavaScript, fonts, and versioned images can usually be cached for longer periods. HTML and dynamic pages should be handled more carefully so visitors do not see stale forms or personalized data.
Compression such as Brotli or gzip reduces text transfer size. On shared hosting, Apache or LiteSpeed rules can often control caching, but directives must match the server environment.
- Use long cache lifetimes for versioned static assets.
- Do not aggressively cache pages with CSRF tokens or session-dependent content.
- Change asset version strings when deploying a new file.
Server and database work still matters
Front-end optimization cannot hide a slow server query. If time to first byte is poor, inspect database queries, repeated external calls, PHP work, and hosting resource limits.
Indexes can improve database lookup performance, while unnecessary queries inside loops can make a page slow even on strong hosting. Cache expensive results only after confirming that stale data will not cause problems.
- Profile slow dynamic pages separately from static pages.
- Avoid SELECT queries for data the page does not use.
- Add indexes based on real query patterns rather than indexing every column.
Treat third-party scripts as a budget
Analytics, chat, ad platforms, social widgets, external fonts, and logo services can add network requests and execution time. Some are valuable, but they should earn their place on the page.
Load optional widgets after initial interaction or idle time where possible, and periodically remove tags that are no longer used.
- Audit third-party requests every few months.
- Delay support widgets that are not required for first paint.
- Use local assets for essential branding where practical.