A fast store sells. A slow one loses customers.
In e-commerce, every second of loading time is a loss in conversion. If your store "lags" and the server crashes with higher traffic, you are losing money. I conduct comprehensive code, database, and server audits, eliminating bottlenecks.
Core Web Vitals
Load Time
Under 1 second
Technical debt holds back your business
Online stores "bloat" over time. Installing random plugins, lack of updates, heavy images, and code errors cause customers to flee to the competition, and Google lowers your positions in the search engine. An audit is also the natural starting point before signing an SLA contract - you know exactly what you're entrusting to ongoing care.
Higher SEO Rankings
Google officially promotes fast pages (Core Web Vitals). Code optimization is the cheapest way to improve organic visibility.
Higher Conversion
Amazon calculated that every 100ms delay causes a 1% drop in sales. A fast store builds trust and encourages purchases.
Data Security
Old PrestaShop versions, module vulnerabilities, and PHP errors are open doors for hackers. An audit allows detecting and patching holes before it's too late.
Order an audit if...
Your store takes more than 3 seconds to load
Google PageSpeed below 50, customers leave before the page loads, and ad campaigns don't pay off the way they should.
You don't know what is in your codebase
The store was built by a previous agency or several developers. Nobody knows why things work the way they do.
You are planning a campaign or peak season
Black Friday, a collection sale, a big ad budget. You don't want to lose traffic because of a slow store or a server crash under load.
You want SLA but want to check the state of things first
An audit is the natural starting point before monthly maintenance. You know what you are taking on instead of buying a pig in a poke.
You have had a breach or suspicious events
Customers reporting payment issues, Google warning about your site, hosting suspending the account. A security audit will explain what happened and why.
Scope of Optimization Work
Backend & Database Optimization
The problem of a slow store rarely lies in "large photos". More often it is slow SQL queries and lack of cache. I go deep into the code and server.
- MySQL query optimization (indexing)
- Server Cache implementation (Redis / Varnish)
- PHP version update (e.g., from 7.4 to 8.2)
- Cleaning the database of garbage (logs, stats)
$ mysql-slow-query-log analyze
! Found query taking 4.5s (join on `ps_orders`)
$ optimizing table indexes...
✓ Query time reduced to 0.02s
$ service redis-server start
✓ Cache Hit Rate: 95%
Lighter Frontend
Fewer scripts, faster loading.
Core Web Vitals (Frontend)
I improve results in Google PageSpeed Insights. I make the site load instantly on phones, which is crucial for the modern customer.
- Image format conversion to WebP / AVIF
- CSS and JavaScript file minification
- Lazy Loading (loading images on scroll)
- Removal of unused modules and scripts
Code Review & Refactoring
Was your store made by several developers and no one knows how it works? I perform a code quality audit. I remove "spaghetti code", fix security holes, and prepare the system for further development.
Why is this important?
Bad code hinders the implementation of new features. Fixing technical debt makes future changes cheaper and faster.
Maintainability Index: A
What do you get in the report?
Every finding has a priority, a root cause explanation and a concrete recommendation. No jargon — you know what to fix and why.
Loads an external Google Fonts stylesheet on every page
Dlaczego spowalnia: An additional DNS lookup to googleapis.com blocks page rendering and adds ~160ms to TTFB.
Rekomendacja: Self-host the font locally and add a preconnect hint in <head>.
N+1 SQL queries on the order confirmation page
Dlaczego spowalnia: Each product in the order fires a separate SELECT. 15 products = 15 queries instead of 1. Measured impact: +2.1s.
Rekomendacja: Rewrite as a single query with JOIN or cache the result in Smarty.
3 banners in JPEG format, 2.4 MB total, no compression
Dlaczego spowalnia: Transfer time on mobile 4G: ~3.8s. Blocks LCP (Largest Contentful Paint), a core Google metric.
Rekomendacja: Convert to WebP (~75% saving) and add loading="lazy" to slides 2 and 3.
CSS and JS loaded globally even though the widget only appears on product pages
Dlaczego spowalnia: Unnecessary 28 KB on every other page (home, category, checkout).
Rekomendacja: Conditionally load assets only on product page hooks. Saving: ~28 KB per page.
How do I conduct an audit?
Access & Analysis
I grant permissions to code and server. I create a store copy (Staging) to avoid working on a live organism.
Error Report
You receive a document with a list of problems, their priority (Critical/Recommended), and repair time estimation.
Fix Implementation
After acceptance, I implement optimizations. I clean the database, configure cache, and refactor code.
Verification
I compile "Before" and "After" results for you. I verify real loading times and new Google PageSpeed scores.
TTFB from 2.5s to 0.3s. Without changing the server.
A PrestaShop store on a typical shared hosting environment, no hardware changes. Three places in the code: a sitemap generated in real time, an N+1 SQL query problem, and 8,000 categories loaded into a UI widget. After fixing each one, the time to first byte dropped by more than 88%.
Read the full write-up on the blog
Technical details and discussion also on LinkedIn.
TTFB before and after
2.5s
przed
0.3s
po
TTFB · bez zmiany serwera
What next after the audit?
Technical debt needs a rebuild? Check my implementations. Code is stable? The natural next step is an SLA contract with guaranteed response times.
Questions and Answers (Audit)
Can optimization break the store?
No, because I perform all work first on a test copy (Staging environment). Only after testing changes do I implement them on the production store.
How much will my store speed up?
It depends on the starting point. In one documented case, TTFB dropped from 2.5s to 0.3s (over 88%) by fixing just three places in the code, with no server change. The scale of improvement differs for each store, but every audit ends with a before-and-after comparison.
Does the audit also include security?
Yes. I check the PHP version, installed modules against known CVE vulnerabilities (Friends of Presta and NVD/NIST databases), SSL configuration, debug mode and the default admin URL. If you suspect a breach or malware infection, I also offer a separate malware removal service.
How long does an audit take?
I usually prepare the report within 2-3 business days of receiving access. The time to implement fixes depends on the number of issues found and their complexity.
Do I have to fix all detected problems straight away?
No. The report uses priorities: Critical, Recommended and Optimisation. You can decide to tackle only the critical items first, and address the rest in a later phase or as part of an ongoing SLA contract.
What is the difference between a one-off audit and an SLA contract?
An audit is an X-ray: I diagnose the current state of your store and deliver a report with a list of issues. SLA is ongoing insurance: monitoring, backups, a guaranteed response time for incidents and regular updates. Many clients start with an audit and then move to SLA once the environment is stable.