Performance Improvements During a Redesign

1. Image strategy

Images are usually the single largest performance liability on a site. The typical Tampa SMB site we audit has hero images that are 1.5MB to 4MB, served as JPEGs at full desktop dimensions to every device, with no lazy-loading. On a phone over 4G, the hero image takes 4 to 8 seconds to render. That is the entire performance budget, spent on one image.

What we ship in a redesign:

Modern formats. WebP and AVIF where supported, with JPEG fallbacks. WebP is roughly 25-35 percent smaller than JPEG at the same visual quality. AVIF is another 20 percent smaller than WebP. For a hero image, that’s the difference between 1.5MB and 350KB.

Right-sized assets. A hero image that needs to display at 1200 pixels wide on desktop should not be served at 4000 pixels wide to a phone. We use the srcset and sizes attributes to serve the right size to the right device. The phone gets the 800-pixel version. The desktop gets the 1600-pixel version. The retina-display 5K monitor gets the 2400-pixel version. Nobody downloads pixels they cannot see.

Compression. Lossy compression at 75-85 percent quality for photographs. Lossless for graphics with sharp edges. Tools like ImageOptim, Squoosh, or automated WordPress plugins (ShortPixel, Imagify, EWWW) do this at upload time.

Lazy-loading. Images below the fold get loading="lazy". The browser doesn’t download them until the user scrolls toward them. This is a free attribute that ships with every modern browser. It is genuinely free performance.

Dimensions declared. Every image has width and height attributes. This prevents the layout shift (CLS) that happens when images load and push content around.

Decorative images use SVG or CSS. Icons, illustrations, and simple graphics should be SVG. SVG is text — it compresses well, scales perfectly, and stays sharp on retina displays.

Typical before-and-after on a Tampa SMB redesign: total image payload drops from 6-8MB per page to 600KB-1.2MB per page. LCP drops from 4-6 seconds to 1.5-2 seconds.

2. JavaScript reduction

JavaScript is the second-largest performance liability and usually the harder one to fix. The typical Tampa SMB site has accumulated layers of third-party scripts over the years — Google Analytics, Google Tag Manager, Meta pixel, a chat widget, a review widget, a popup builder, a heatmap tool, a CRM tracker, and three plugins that each load their own JavaScript whether the page needs it or not.

What we audit and cut:

Plugin bloat. Every WordPress plugin loads CSS and JavaScript on every page by default, even pages that don’t use the plugin. A contact form plugin loading its assets on every blog post is a common culprit. We audit which plugins load globally and either replace them, configure them to only load where needed, or remove them entirely.

Third-party scripts. Each third-party script gets a question: what is this earning? A chat widget that produces 2 leads a month is not worth 400KB of JavaScript and 600 milliseconds of main-thread time. Either we move it to async/deferred loading, replace it with a lighter alternative, or remove it.

Render-blocking scripts. Scripts in the without async or defer attributes block the page from rendering. We move what we can to the bottom of the page, add defer to non-critical scripts, and async to scripts that don’t depend on the DOM.

Custom JavaScript audit. The site’s own JavaScript — sliders, animations, accordions — gets reviewed. A jQuery slider with three plugins layered on top can usually be replaced with 30 lines of modern vanilla JavaScript or a CSS-only solution.

Tag manager hygiene. Google Tag Manager is a useful tool that becomes a performance disaster when nobody prunes it. We audit the tags, remove the dormant ones, and set firing triggers that don’t fire on pages where the tag isn’t needed.

Typical result: total JavaScript payload drops from 1.5-3MB per page to 400-800KB. INP drops from 300-600ms to under 150ms. The improvement in perceived responsiveness is usually the thing users notice most.

3. Caching

Caching is the boring, unglamorous, highest-ROI lever in performance. A page that gets cached at the server, the CDN, and the browser only renders once and then serves a saved version to every subsequent visitor.

Three layers of caching we configure:

Server-side page caching. WordPress generates the HTML for every page on every request by default — running the database, executing PHP, assembling the page. A page cache (WP Rocket, W3 Total Cache, or built-in caching from managed hosts like Kinsta, WP Engine, or Cloudways) saves the rendered HTML and serves it directly. Page load drops from 800-1500ms to 80-200ms.

Object caching. For dynamic queries that can’t be page-cached — logged-in users, dynamic content — object caching saves the database query results. Redis or Memcached at the server level. This matters more for WooCommerce sites and membership sites than for static service-business sites.

Browser caching. HTTP headers tell the browser “this CSS file hasn’t changed in a month, don’t bother re-downloading it.” Repeat visitors load the site dramatically faster because they already have most of the assets in their browser cache. We set cache-control headers correctly during build and verify them at launch.

4. CDN

A Content Delivery Network serves your assets — images, CSS, JavaScript, fonts — from servers physically close to the user. For a Tampa business serving Tampa Bay customers, this matters less than for a national site. But it still matters, and most CDNs cost $5-20/month for SMB-scale traffic.

What a CDN does:

• Serves assets from a server in the user’s region (closer = faster)
• Handles traffic spikes without the origin server collapsing
• Provides image optimization on the fly (Cloudflare Polish, BunnyCDN Optimizer)
• Adds an extra layer of caching
• Often includes free SSL, basic DDoS protection, and bot filtering

What we use most often for Tampa SMB redesigns:

• Cloudflare — free tier is enough for most SMB traffic, paid tier ($20/month) adds image optimization and additional speed features
• BunnyCDN — pay-per-bandwidth, typically $1-5/month for SMB traffic, very fast, includes image optimization
• WP Engine’s built-in CDN — included with hosting, no extra setup, works well

We avoid CDNs that require complex DNS gymnastics or break SSL renewal workflows. Setup should take 30 minutes, not 3 hours.

Performance is not a separate workstream — it’s a design constraint. The wireframing phase makes performance-relevant decisions about hero image use, video, and embedded widgets. The staging environment is where the performance numbers get verified before launch. The pre-launch checklist includes a final Core Web Vitals check.

If the redesign produces a faster site that converts more leads and ranks better, the budget was earned. If the new site is prettier than the old one but loads in 5 seconds, the project failed regardless of what the design looks like.