Website Performance Optimization Services

Website performance optimization is the work of making every request faster – from the first byte the server sends to the moment a visitor can actually tap a button. Slow pages cost money in ways that rarely show up on an invoice: shoppers abandon carts, ad budgets buy clicks that bounce, search engines crawl less, and servers that should cope with a traffic spike fall over instead.

At CodeWiz we treat performance as an engineering problem, not a plugin you install. We profile the application, the database, the server and the network path, then fix the real bottlenecks with full-page caching in Varnish, optimized code, tuned queries and a properly configured CDN. Our own site, codewizdev.com, scores 100/100 in all four PageSpeed Insights categories on both mobile and desktop – we apply the same discipline to client projects.

This service is for online stores that slow down under load, content sites and WordPress installations that have grown plugin by plugin, SaaS products and APIs whose response times creep up as data grows, and agencies that need a reliable partner to rescue client sites before launch. If your hosting bill keeps rising while pages keep getting slower, the problem is almost never “not enough server”.

Measure First: Where Website Performance Optimization Starts

Every optimization we make starts with a baseline. Guessing wastes budget: teams buy bigger servers when the real cause is a single unindexed query, or minify CSS while a chat widget blocks the main thread for a full second. We combine lab data (repeatable, controlled tests) with field data (what real visitors experience on real devices and networks).

Tool	Data type	What it tells us
PageSpeed Insights and CrUX	Lab and field	Lighthouse diagnostics plus 28-day real-user Core Web Vitals at the 75th percentile
WebPageTest	Lab	Waterfalls, filmstrips, TTFB from different locations, throttled mobile connections
Chrome DevTools Performance panel	Lab	Long tasks, layout shifts, render-blocking resources, which script delays interaction
web-vitals library (RUM)	Field	LCP, INP and CLS per page template, device type and country from your own visitors
Server profilers (SPX, Xdebug, Blackfire, Clinic.js)	Backend	Which function, query or external call consumes the request time
Slow query logs, pg_stat_statements	Database	The queries that cost the most in total, not just the slowest single one

The output of this phase is a short, prioritized report: what is slow, why, how much each fix is likely to help and how much effort it takes. Google’s Web Vitals documentation defines the targets we work toward – LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 – but for us they are a floor, not the finish line. We describe the front-end side of that work in detail in how CodeWiz achieves perfect 100/100 page vitals.

Varnish Caching for Dynamic Websites and Online Stores

Varnish is an HTTP reverse proxy that keeps fully rendered pages in memory and serves them in microseconds, without touching PHP, Node.js or the database. For a WordPress, WooCommerce, Magento or Laravel site with mostly anonymous traffic, it is often the single biggest server-side improvement available: the origin renders a page once, and Varnish serves the next thousands of requests for it.

We have written a dedicated deep dive on why Varnish Cache is the secret weapon behind fast websites, so here we focus on what makes a Varnish setup work in production rather than just in a benchmark.

What we configure

Cookie hygiene: Varnish will not cache requests that carry cookies by default, and analytics or consent cookies are on almost every request. We strip the cookies the backend does not need and keep only session and cart cookies.
Clean cache keys: tracking parameters such as utm_source, gclid and fbclid are removed, so a campaign does not fragment the cache into thousands of copies of the same page.
Grace mode: stale content is served while a fresh copy is fetched in the background, and keeps the site online if the backend briefly fails.
Precise invalidation: purges and bans – or tag-based invalidation with the xkey module – triggered by the CMS when a product, price or article changes.
TLS in front: open-source Varnish does not terminate HTTPS, so we place Nginx or Hitch in front and Varnish between them and the application.

vcl 4.1;
backend default { .host = "127.0.0.1"; .port = "8080"; }

sub vcl_recv {
  if (req.url ~ "^/(wp-admin|wp-login|cart|checkout|my-account)") {
    return (pass);
  }
  if (req.http.Cookie !~ "wordpress_logged_in|woocommerce_items_in_cart") {
    unset req.http.Cookie;
  }
  set req.url = regsuball(req.url, "(utm_[a-z]+|gclid|fbclid)=[^&]*&?", "");
  set req.url = regsub(req.url, "[?&]+$", "");
}

sub vcl_backend_response {
  set beresp.grace = 24h;
}

We then watch the hit ratio with varnishstat and find the remaining misses with varnishlog. A healthy setup for a content site serves the large majority of anonymous page views straight from memory. The official Varnish documentation is the reference for VCL itself.

Performance: Laptop with source code on screen next to a coffee cup on a desk

Code Optimization: Faster Backends and Leaner Front-Ends

Caching hides slow code for anonymous visitors, but logged-in users, carts, checkouts, dashboards and APIs still hit the application on every request. Code optimization makes those uncached paths fast, and it also makes cache misses cheaper.

Backend profiling and fixes

We profile real requests rather than reading code and guessing. SPX or Xdebug for PHP, Clinic.js and the built-in --cpu-prof flag for Node.js, py-spy for Python. The usual findings are predictable:

N+1 queries – one query for a list and one more for every row in it, the most common problem in ORMs such as Eloquent, Doctrine, Sequelize and Prisma.
Synchronous work that belongs in a queue – sending email, generating PDFs, calling payment or shipping APIs and resizing images during the request.
Repeated expensive computations that should be cached in Redis with a sensible expiry.
Runtime misconfiguration – PHP OPcache disabled or too small, opcache.validate_timestamps left on in production, PHP-FPM pools sized for the wrong amount of memory, or a Node.js event loop blocked by synchronous file and crypto calls.

// N+1: one query for orders, then one per customer
$orders = Order::latest()->take(50)->get();
foreach ($orders as $order) {
    echo $order->customer->name;
}

// Fixed: two queries in total, regardless of list size
$orders = Order::with('customer')->latest()->take(50)->get();

// Fail loudly in development when lazy loading slips back in
Model::preventLazyLoading(! app()->isProduction());

Front-end delivery

In the browser, we reduce what has to be downloaded, parsed and executed before the page is usable: inlined critical CSS, unused JavaScript removed, responsive AVIF or WebP images with explicit dimensions, self-hosted fonts with font-display: swap and a preload for the hero image. Third-party scripts – chat widgets, tag managers, heatmaps – get special attention, because they are the most frequent cause of poor INP.

Database Optimization for MySQL, MariaDB and PostgreSQL

Most applications that “need a bigger server” actually need better queries. Database optimization usually delivers the largest gains per hour of work, because a single missing index can make a query hundreds of times slower as a table grows – and that slowdown appears gradually, so nobody notices until checkout starts timing out.

How we find the expensive queries

MySQL and MariaDB: the slow query log with a low long_query_time, summarized with pt-query-digest from Percona Toolkit.
PostgreSQL: pg_stat_statements to rank queries by total time, and auto_explain to capture plans of slow ones.
EXPLAIN and EXPLAIN ANALYZE on each candidate to see full table scans, filesorts and temporary tables.

-- Before: full table scan plus filesort
EXPLAIN SELECT id, total FROM orders
WHERE customer_id = 4821 AND status = 'paid'
ORDER BY created_at DESC LIMIT 20;

-- After: one composite index that matches the filter and the sort
CREATE INDEX idx_orders_customer_status_created
  ON orders (customer_id, status, created_at);

Beyond indexes

Server configuration: InnoDB buffer pool sized to the working set, sensible work_mem and shared_buffers in PostgreSQL, connection limits that match the application.
Connection pooling with PgBouncer or ProxySQL for applications that open many short-lived connections.
WordPress specifics: bloated autoloaded options, oversized wp_postmeta lookups, expired transients and WooCommerce’s move to High-Performance Order Storage.
Read replicas for reporting and search, so heavy analytics never compete with checkout.
Archiving old data, and when a single table truly outgrows one server, partitioning or sharding – see our guide on database sharding vs. partitioning.

Abstract close-up of glowing fiber optic strands carrying light

CDN Configuration That Actually Speeds Things Up

A CDN puts copies of your content in data centres close to your visitors, which cuts latency for an international audience and takes load off your origin. But simply switching a CDN on often delivers far less than expected: HTML is not cached at all, cache keys are polluted by cookies and query strings, and hit ratios stay low. CDN configuration is where that difference is made.

What a performance-focused CDN setup includes

Cache rules for static assets with long lifetimes and fingerprinted filenames, so you can cache for a year and still deploy instantly.
Edge caching of HTML for anonymous visitors where it is safe, with bypass rules for sessions, carts and admin areas.
Tiered caching or origin shielding, so a cache miss in one location does not mean a request to your server from every location.
Brotli compression, HTTP/3 and TLS 1.3, plus Early Hints where the platform supports it.
Image resizing and format conversion at the edge, so every device receives an appropriately sized file.
Correct purge integration with your CMS or deployment pipeline.

We work most often with Cloudflare, and we cover its settings in depth in our article on professional Cloudflare configuration strategies. Bunny CDN and Amazon CloudFront are good alternatives depending on budget and existing infrastructure.

How the Caching Layers Fit Together

Varnish, a CDN and an object cache are not competitors – they solve different parts of the problem. The right combination depends on your audience, how personalized your pages are and how often content changes.

Layer	What it stores	Typical tools	Best for	Watch out for
Browser cache	CSS, JS, fonts, images	`Cache-Control`, hashed filenames	Repeat visits and multi-page sessions	Stale assets without fingerprinting
CDN edge	Static assets, optionally HTML	Cloudflare, Bunny CDN, CloudFront	International audiences, offloading the origin	Cookies and query strings in the cache key
Varnish	Full HTML pages at the origin	Varnish with Nginx or Hitch for TLS	Dynamic CMS sites with fine-grained VCL control	Logged-in users, purge strategy
Object cache	Query results, computed fragments	Redis, Memcached	Logged-in users, carts, APIs	Invalidation logic, memory sizing
Bytecode cache	Compiled PHP	OPcache	Every PHP application	Resetting it on every deploy

Server and Hosting Tuning

The fastest code still needs a well-configured server. We tune Nginx (keep-alive, compression, microcaching where Varnish is overkill), PHP-FPM process management based on measured memory per worker, and Node.js clustering with PM2 or systemd. We also right-size the infrastructure: sometimes moving from shared hosting to a modest NVMe VPS gives more than any code change, and sometimes the honest answer is that your server is already oversized.

Performance Budgets and Continuous Monitoring

Performance degrades quietly: a new plugin, a marketing tag, a heavier hero image. We set performance budgets (maximum JavaScript weight, LCP target per template) and enforce them with Lighthouse CI in your deployment pipeline. In production, real-user monitoring reports Core Web Vitals per template, while Prometheus and Grafana track response times, cache hit ratios and slow queries, with alerts before customers or rankings notice.

Common Website Performance Optimization Mistakes

Stacking several caching plugins on top of each other, each partially undoing the others.
Loading every script and stylesheet on every page, including sliders, forms and maps that appear on one page only.
Lazy-loading the hero image, which delays LCP instead of improving it.
Upgrading the server plan to compensate for an N+1 query or a missing index.
Caching pages for logged-in users or carts by mistake and showing one customer’s data to another.
Optimizing for a lab score while real users on mid-range phones still wait.

Close-up of a silver sports stopwatch dial on a white background

How We Work

Audit: we collect lab and field data, profile the backend and database, and review server, CDN and caching configuration.
Prioritize: you receive a report ranking each fix by expected impact and effort, so the budget goes to the changes that matter most.
Optimize: we implement the agreed fixes – caching layers, code and query changes, CDN rules, server tuning – on a staging copy first.
Verify: we load-test, compare before and after metrics, and check that carts, logins and personalized pages behave correctly with caching enabled.
Launch: changes go live gradually, with cache hit ratios, error rates and response times monitored closely.
Monitor: performance budgets and real-user monitoring keep the gains in place, and we can continue with ongoing maintenance.

Why CodeWiz

Proven on our own site: codewizdev.com scores 100/100/100/100 on PageSpeed Insights on mobile and desktop.
Full-stack depth: we write Laravel, Node.js and WordPress code ourselves, so we fix slow code at the source instead of only adding caches in front of it.
The whole chain in one team: code, database, server, Varnish and Cloudflare – no hand-offs between vendors blaming each other.
Open-source first: Varnish, Redis, Nginx, PgBouncer and Prometheus mean no licence fees and no lock-in.
Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally – read more about CodeWiz.

Frequently Asked Questions

How much does website performance optimization cost?

It depends on the platform, the size of the codebase and how many layers need work. A focused audit with quick wins is a small project; reworking caching, queries and infrastructure for a large store is a bigger one. We give you a clear estimate after the initial audit, before any work starts.

How quickly will I see results?

Server-side changes such as Varnish, CDN rules and database indexes take effect immediately. Lab scores improve as soon as changes are deployed, while field data in PageSpeed Insights and Search Console is based on a rolling 28-day window, so it catches up over the following weeks.

Do I need Varnish if I already use Cloudflare?

Not always. Cloudflare can cache HTML at the edge, and for some sites that is enough. Varnish adds value when you need fine-grained control over what is cached, tag-based invalidation, grace mode or protection for an origin that receives a lot of uncached traffic. We recommend the simplest combination that meets your goals.

Can you speed up a WordPress or WooCommerce site without rebuilding it?

Yes, in most cases. Removing heavy plugins and scripts, fixing database bloat, adding Redis object caching, configuring full-page caching and a CDN, and tuning PHP usually bring large improvements without a redesign.

Will caching break my cart, checkout or member area?

Not when it is configured correctly. We exclude sessions, carts, checkouts and account pages from shared caches and test every personalized flow on staging before anything goes live.

Ready for a Faster Website?

Send us your URL and tell us where speed hurts most – landing pages, checkout, search or the admin area – and we will show you what is slowing it down and what it takes to fix it. Contact us to start with a performance audit, or explore our performance optimization services.

Website Performance Optimization Services

Contents