Slow WordPress? The 2026 Guide to Hit 100% on Google PageSpeed

If your Google PageSpeed score is in the red, it is generally a sign of an overloaded server, a fragmented database or poorly optimized JavaScript resources holding back your growth. This slowdown is not inevitable: a WordPress site becomes slow through technical tinkering, an accumulation of resource-hungry plugins, or hosting that no longer keeps up with your traffic.

In this complete guide, I will explain exactly why your site is crawling and give you the technical keys to fix every Google alert so you can aim for the perfect 100/100 score.

🚀 No time to tinker? I take care of everything.

I analyze the slowdowns and carry out the optimizations included in the quote. Performance is monitored in a way suited to your site; no PageSpeed score or SEO ranking is guaranteed.

• ✅ Complete optimization (Cache, Images, Code)

• ✅ Monthly monitoring of performance

• ✅ Interventions according to the quote, within the agreed monthly volume

It’s not just for fun. Since Core Web Vitals, Google uses speed as a ranking factor. The equation is simple:

• Slow site = Bad SEO + High bounce rate + Frustrated customers
• 
  Fast site = Better ranking + Higher conversions + Satisfied visitors

This client went from 6842/100 to 100/100 in 3 weeks.

Result: +35% organic traffic and a loading time divided by 3.

Before rushing at PageSpeed’s technical alerts, you need to understand the root causes. A WordPress site rarely slows down because of a single problem. It is usually an accumulation.

The main reason for a slow site is often a hosting plan that no longer matches your needs. At first, everything is fine. But as soon as you install plugins, upload images, or traffic increases, the server saturates.

The warning signs:

• Server response time (TTFB) above 600ms
• 500 or 503 errors during traffic peaks
• WordPress back office that crawls even for you

The solution: Ask your host for your CPU/RAM usage statistics. Be wary of automatic upgrade recommendations: often, optimizing the site is enough. If you really have to switch, I recommend o2switch for my French clients. Their servers are sized to handle peaks and their technical support replies in 10 minutes, not 48 hours.

If you regularly see this specific code, I invite you to read my guide to understand and fix the 503 error. It’s the typical sign that your o2switch (or other) server is at the end of its capacity.

Other common server problems:

• No CDN (Content Delivery Network) enabled
• Server geographically too far from your visitors
• Outdated PHP version (7.4 or lower)
• HTTP/1.1 protocol instead of HTTP/2 or HTTP/3

If your site slowed down suddenly overnight, that’s often suspicious. Look no further, you have probably been attacked.

The most common attacks:

DDoS attack: Thousands of fake visits saturate your server. The goal is to make your site inaccessible. In general, it calms down after a few hours if the attackers give up.

Malware or malicious script: An infected file runs in the background to mine cryptocurrency, send spam, or redirect your visitors to fraudulent sites. It’s more insidious because it can last for weeks without you noticing.

The immediate action: Scan your site with Wordfence (free plugin) or Sucuri (free online interface for a quick scan). If an infection is detected, don’t try to clean it up yourself: one forgotten file and the attack starts again. In my security plans, I manually clean the infected files and harden the site to prevent recurrences.

Even before looking for the origin of the problem, remember to run a security audit of your WordPress site : a complete diagnostic scanner reveals the vulnerabilities, suspicious files and active infections in a few minutes.

WordPress’s default themes (Twenty Twenty-Four, etc.) are light but limited in features. So people turn to premium themes.

The problem: Some themes are real bloatware. They load dozens of CSS and JavaScript files on every page, even if you only use 10% of their features.

The worst offenders:

• Multipurpose themes with 50+ ready-made demos (Flatsome, BeTheme…)
• Themes coupled with heavy page builders (Divi, Elementor in its free version)
• Nulled themes downloaded from dubious sites (often infected as a bonus)

The themes I recommend:

• Astra : Ultra-light (under 50 KB), compatible with all page builders
• GeneratePress : Developers’ favorite for its clean code
• Kadence : Perfect balance between lightness and features

Each plugin adds code to load. Even when deactivated, a plugin can sometimes leave traces in the database.

The golden rule: Delete (don’t deactivate, delete) everything you don’t use. If you haven’t used a plugin for 3 months, get rid of it.

Plugins that often drag performance down:

• Animated sliders (Revolution Slider, etc.): Prefer a simple header image
• Social sharing plugins with counters: They make external requests on every load
• Heavy form builders: Gravity Forms loads 300 KB of JS even on pages without a form
• Server-side statistics plugins: Google Analytics is more than enough

My essential (and optimized) plugins:

• WP Rocket : Cache, minification, lazy loading all-in-one
• Imagify : Automatic image compression to WebP
• Wordfence : Security and firewall without slowing the site down

Your database stores everything: posts, settings, comments, but also thousands of invisible bits of junk.

What accumulates:

• Post revisions : WordPress saves every edit. A 2-year-old post can have 150 stored revisions
• Spam comments : Even when deleted, they stay in the trash
• Expired transients : Temporary plugin data that never gets cleaned up
• Autoloaded options : Settings from uninstalled plugins that load on every page
• Orphan tables : Deleted plugins that leave their MySQL tables behind

The result: A 500 MB database can often be reduced to 50 MB after a good cleanup.

The basic solution: You can use WP-Optimize for automatic cleanup (revisions, spam, transients).

⚠️ Warning: Always make a backup first.

Expert cleanup: For a deep cleanup (orphan tables, useless autoloaded options), it’s a delicate operation. I do it manually in SQL during monthly maintenance, precisely targeting the parasitic data without risking breaking the site.

Before fixing Google’s technical alerts, you need to lay solid foundations. Without that, you’ll spend your time plugging leaks.

We talked about it above, but here is the complete method:

Step 1: Limit future revisions

Add this line to your wp-config.php file:

define('WP_POST_REVISIONS', 3); This limits revisions to 3 per post instead of unlimited.

Step 2: Clean up what already exists

With WP-Optimize (free):

1. Go to Plugins → WP-Optimize
2. Check: Revisions, Drafts, Spam, Transients
3. Run the optimization

Step 3: Schedule an automatic cleanup

WP-Optimize lets you schedule a weekly cleanup. Enable it so you can forget about it.

The trap to avoid: NEVER touch the wp_options or wp_postmeta tables manually if you don’t know what you’re doing. One line deleted by mistake and your site no longer starts.

If you’re still on PHP 7.4, you’re losing 30 to 40% performance. PHP 8.2 (or 8.3) is up to 2x faster thanks to deep engine optimizations.

How to check your version:

1. Go to Tools → Site Health
2. “Info” tab → Look for “PHP version”

How to change it:

1. Log in to your cPanel (or Plesk)
2. Look for “Select PHP Version” or “MultiPHP Manager”
3. Choose PHP 8.2 (or the most recent version recommended by your host)
4. ⚠️ Test your site afterwards: some old plugins are not compatible

HTTP/3 protocol: The invisible turbo

HTTP/3 lets you load several files in parallel without blocking. It’s particularly effective on mobile with an unstable connection.

How to enable it: Contact your host to check whether HTTP/3 is available. On o2switch, Cloudways, or Kinsta, it’s often enabled by default. Otherwise, ask for it to be enabled.

The problem with the “dynamic” site

By default, WordPress rebuilds every page on every visit. If you have 100 simultaneous visitors, the server has to generate the same page 100 times. It’s pure waste.

The solution: Caching

The cache saves a “frozen” version of your page (in pure HTML) and serves it to the following visitors. Result: the server only works once instead of 100 times.

WP Rocket handles this perfectly:

• Page cache : Enabled by default
• Browser cache : CSS/JS files are stored in the visitor’s browser (it doesn’t re-download them on every page)
• Cache preloading : WP Rocket “visits” all your pages in the background to generate the cache before a visitor even arrives

The CDN: Offloading your server

A CDN (Content Delivery Network) stores your images, CSS and JS on servers all over the world. Result: a visitor from Tokyo loads your images from a Japanese server, not from your server in France.

The free solution: Cloudflare (CDN + DDoS protection included). It takes 10 minutes to set up.

Handling a load peak (promo, viral post)

You get 1,300 visitors at once following a Facebook ad? If you’re not ready, the 500 error is guaranteed.

My anti-crash checklist:

1. Cache enabled : WP Rocket must serve static HTML pages
2. CDN enabled : Your images must not hit your server
3. Temporarily disable : Heavy stats plugins, live chats, complex forms (keep only the essentials)
4. Warn your host : If they are good, they can temporarily allocate more resources

Technical monitoring can report downtime. Requests are handled Monday to Friday from 9 am to 6 pm, Paris time, excluding public holidays in France, with an indicative first-response target within 24 working hours. No on-call duty or guarantee of zero lost sales is provided.

You ran an analysis and Google shows you a red list of technical errors? These terms may seem barbaric, but they correspond to precise problems. Here is the detailed analysis of the most frequent alerts and how to fix them.

What’s the problem?

By default, WordPress uses JPEG or PNG. These formats date back to the 90s and are heavy. A 200 KB JPEG image could be 60 KB in WebP with the same visual quality.

Why does Google insist on this?

Because images represent 50 to 70% of the total weight of a web page. It’s the most impactful lever.

The solution:

Don’t try to convert your images manually before uploading. Use Imagify or ShortPixel. These plugins scan your media library and automatically create a WebP version of each image. Your old images stay intact, but the browser loads the WebP version if it supports it.

Imagify configuration:

1. Install the plugin
2. Choose the “Aggressive” level (the quality loss is imperceptible)
3. Enable “Create WebP images”
4. Run the bulk optimization

In 10 minutes, all your images are converted. On a site with 500 images, you can gain 5 to 10 seconds of loading time.

What’s the problem?

When the browser loads your page, it doesn’t know how much space to reserve for images. Result: the text suddenly jumps down when the image appears. This is what’s called a bad CLS (Cumulative Layout Shift).

Concrete example:

You’re on mobile, you start reading an article, and suddenly BAM, the text drops 300 pixels because an image has just loaded above it. Annoying, isn’t it? Google finds it annoying too.

The solution:

WP Rocket automatically adds the missing width and height attributes to your HTML code. Enable the option in “Media” → “Add missing width and height attributes”.

If you don’t use WP Rocket, make sure your theme properly declares these dimensions. Otherwise, change your theme (seriously).

What’s the problem?

WebP is good, but AVIF is even better. This very recent format (2021) compresses 30% more than WebP. The problem: it is not yet supported by all browsers.

The solution:

For now, stick with WebP. AVIF will become standard by 2026. Imagify will start supporting it automatically when it becomes relevant.

What’s the problem?

By default, your browser loads ALL the images on the page, even those at the bottom that the visitor may never see (90% of people don’t scroll all the way down).

The solution:

Lazy loading loads images only when the visitor scrolls down the page. Since WordPress 5.5, it is enabled by default for images in the content. But not for those in sidebars, widgets, or the footer.

With WP Rocket:

1. “Media” tab
2. Enable “Lazy load” for images AND iframes (YouTube videos)
3. Exclude your header image (logo, banner) so that it loads immediately

What’s the problem?

You load your contact form’s code on pages where there is no form. You load your slider’s script on pages where there is no slider. It’s pure waste.

Concrete example:

Contact Form 7 loads 150 KB of JavaScript on ALL the pages of your site, even those without a form. On a 50-page site, that’s 7.5 MB of code loaded needlessly.

The easy-level solution:

In WP Rocket, enable “Load JavaScript deferred” and “Remove unused JavaScript”. The plugin sorts it out automatically.

The expert-level solution (what I do in maintenance):

I use Asset CleanUp to manually disable scripts plugin by plugin on each page. It’s surgical and carries no risk of bugs.

Example rule:

• Contact Form 7: Disabled everywhere EXCEPT on the Contact page
• WooCommerce: Disabled everywhere EXCEPT on the shop, the cart, and the checkout
• Google Maps: Disabled everywhere EXCEPT on the Contact page

Result: You can save 500 KB to 1 MB per page. It may seem small, but on mobile with average 4G, that’s 2 to 3 seconds saved.

What’s the problem?

Your JavaScript files contain spaces, comments, line breaks… everything that is readable for a human but useless for a computer.

The solution:

WP Rocket → “File Optimization” tab → Check “Minify JavaScript files”. The plugin automatically compresses all your JS files.

Warning: JavaScript minification can sometimes break features (drop-down menus, sliders). If that happens:

1. Identify the problematic file in the browser console (F12)
2. Exclude it from minification in WP Rocket

What’s the problem?

A JavaScript script blocks the whole browser while it runs. During that time, your visitor can neither click, nor scroll, nor do anything. The site is frozen.

Translation into plain English:

The “main thread” is your browser’s processor. If a script monopolizes that processor for more than 50 milliseconds, Google considers it a “long task”.

The usual culprits:

• Animated sliders (Revolution Slider, LayerSlider)
• Live chats (LiveChat, Tawk.to)
• Complex JavaScript animations
• Poorly configured Google Analytics

The solution:

1. Identify the culprit with Query Monitor (free plugin that lists all loaded scripts)
2. Defer the loading of this script with WP Rocket (“Load JavaScript deferred” option)
3. If it’s a heavy plugin, replace it with a lighter alternative

Example: A Revolution Slider can be replaced with a simple header image. You lose the “wow” effect but you gain 800 KB and 2 seconds of loading time.

What’s the problem?

Your browser has to download certain CSS and JavaScript files BEFORE it can display anything. The visitor therefore stays in front of a blank page for precious seconds.

The solution: Deferred loading (Defer/Async)

You need to tell the browser to load the visuals first, and the scripts in the background.

Two techniques:

1. Critical CSS: You need to extract the CSS needed only for the top of the page (“above the fold”) and load the rest later. WP Rocket does this automatically with the “Optimize CSS delivery” option.

2. Deferred JS: Non-essential scripts (analytics, chat, sliders) must be loaded with the defer attribute so they don’t block rendering. WP Rocket handles it with “Load JavaScript deferred”.

Warning: Deferred loading can break some scripts that must run immediately (jQuery, some plugins). If it breaks, exclude those files in the WP Rocket settings.

What’s the problem?

Your theme loads a 300 KB CSS file with 10,000 style rules. But your page only uses 500 of them. The other 9,500 are dead weight.

Why does this happen?

Because your theme is designed to handle dozens of different page types (blog, shop, portfolio, etc.). So it loads ALL the CSS on ALL pages, even if you only use some of the features.

The solution:

WP Rocket → Enable “Remove unused CSS”. The plugin analyzes each page and loads only the CSS that is really needed. You can save 100 to 200 KB per page.

Warning: This feature can sometimes break the layout of some pages (drop-down menus, popups). If that happens, exclude those pages in the settings.

Two quick levers to test: switch your images to WebP format and choose a good cache plugin.

To go further, you can check out Google’s PageSpeed Insights tool.

What’s the problem?

As with JavaScript, your CSS files contain useless spaces and comments.

The solution:

WP Rocket → “Minify CSS files”. Typical gain: 20 to 30% weight reduction.

What’s the problem?

Your site loads 15 different CSS files (one per plugin, one for the theme, one for the fonts, etc.). Each file requires an HTTP request. 15 requests = 15 server round trips.

The solution:

WP Rocket → Enable “Combine CSS files”. The plugin merges all your CSS files into one. Result: 1 request instead of 15.

Warning: Combining can sometimes create style conflicts (an element that displays badly). If that happens, disable the option for that specific file.

What’s the problem?

You use a Google Fonts font (Roboto, Open Sans, etc.). While this font loads, the text is invisible. The visitor sees a blank page even though the content is already there. This is called FOIT (Flash Of Invisible Text).

Why is it serious?

On a 3G connection, a Google Fonts font can take 2 to 3 seconds to load. During that time, the visitor sees NOTHING. 40% of them will leave.

The solution:

Option 1 (easy): WP Rocket → Enable “Optimize Google Fonts delivery”. The plugin uses the font-display: swap attribute, which first displays a system font (Arial) and then replaces it with your custom font once it has loaded.

Option 2 (optimal): Host your fonts locally via your theme or with the plugin OMGF (Optimize My Google Fonts). Instead of downloading the font from Google’s servers, it is stored directly on your server. Typical gain: 200 to 500ms.

What’s the problem?

Your browser discovers that you use a custom font only AFTER having downloaded and parsed your CSS. It’s too late, it adds a delay.

The solution:

Tell the browser to download your font AS A PRIORITY with a “preload”. WP Rocket does it automatically if you enable “Preload fonts”.

GZIP compression lets your site load faster by reducing the size of the files sent to the browser.
You can enable it in three ways.

Via a cache plugin
If you use WP Rocket, WP Super Cache or W3 Total Cache, compression is already handled from their interface. In WP Super Cache, check the box “Compress pages so they are served more quickly to visitors” in the advanced settings. In W3 Total Cache, enable it via the “Browser Cache” section.

Via .htaccess
If you’re a fan of doing things by hand and hate overloading your site with loads of plugins, add this block to your .htaccess file at the root of your site:


AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
AddOutputFilterByType DEFLATE text/javascript application/javascript
AddOutputFilterByType DEFLATE application/json application/xml


Via your server configuration
If you don’t know what you’re doing, avoid digging around in your server.
To check that it’s active, use GiftOfSpeed or Check GZIP Compression. You paste your site’s URL and it confirms whether compression is in place.

What’s the problem?

Your page contains more than 1,500 HTML elements (divs, spans, paragraphs, etc.). Google considers that too many. The more elements there are, the longer the browser takes to build the page.

Why does this happen?

This is often the case with page builders like Elementor that generate extremely heavy code. To make a simple text block with a button, Elementor can generate 15 nested divs when 2 would be enough.

Example: An average Elementor page: 2,500 DOM elements. The same page hand-coded: 600 elements.

The solution:

1. Simplify your layout (fewer sections, fewer widgets)
2. Limit the number of widgets in your sidebar (5 maximum)
3. Favor Gutenberg: It’s WordPress’s native editor. It generates extremely clean and light code, which makes it the no. 1 choice for pure performance. Switch to Bricks or Oxygen: If you need an advanced visual builder, these tools are designed for developers and produce a much smaller DOM than Elementor or Divi.
4. For very long pages, consider pagination

What’s the problem?

The browser does too many calculations (JavaScript parsing, layout, rendering). Beyond 2 seconds of “work” on mobile, Google considers it too much.

The usual culprits:

• Complex CSS animations with transitions on 50 elements
• Constant layout recalculations (because of CLS)
• JavaScript that massively manipulates the DOM

The solution:

1. Disable heavy CSS animations (parallax effects, particles.js)
2. Use a light theme (Astra, GeneratePress)
3. Limit the number of DOM elements (<1500 ideally)

What’s the problem?

Google Analytics, Facebook Pixel, live chat, ads… All these little external scripts add up and drag down your performance.

Why is it serious?

To load these scripts, your site has to connect to external servers (those of Google, Facebook, etc.). If these servers are slow or overloaded, YOUR site slows down.

The solution:

Option 1: Delay their loading by 5 seconds with Flying Scripts (free plugin). During those 5 seconds, your main content loads first.

Option 2: Use Perfmatters (paid) to manually defer each third-party script and choose precisely where they load.

Option 3 (expert): Centralize all your tracking scripts in Google Tag Manager. Instead of loading 5 different scripts, you load only one that manages the others.

What’s the problem?

Your CSS, JavaScript and image files are not cached in the visitor’s browser. Result: on every visit, it has to re-download everything.

The solution:

WP Rocket automatically enables browser caching with optimal durations (1 year for images, 1 month for CSS/JS).

Beyond the technical alerts, Google looks at 3 key indicators to evaluate your site’s user experience. These metrics have been official ranking factors since 2021.

What is it?

The time it takes for your largest visible element to display. It’s usually your header image, your banner, or your hero video.

Google’s thresholds:

• 🟢 Good : Less than 2.5 seconds
• 🟡 Needs improvement : Between 2.5 and 4 seconds
• 🔴 Poor : More than 4 seconds

Why is it important?

If your LCP is 4.2 seconds, it means the visitor waits more than 4 seconds before seeing your main content. On mobile, 40% of visitors will leave before even seeing anything.

How to identify it?

Run a PageSpeed analysis. Google tells you exactly which element is your LCP. It’s often:

• Your header image (hero image)
• Your logo if you don’t have a header image
• A text block if your page is very minimal

How to fix it?

1. Optimize your LCP image:

• Convert it to WebP (Imagify)
• Compress it as much as possible (under 100 KB ideally)
• Use the right dimensions (no need for a 4000px-wide image if it displays at 1200px)

2. Preload this image:

WP Rocket → “Preload” tab → Add the URL of your LCP image. It tells the browser to download it AS A PRIORITY before everything else.

3. Improve your TTFB (Time To First Byte):

It’s the time your server takes to start sending data. If your TTFB exceeds 600ms, your server is too slow.

• Enable the cache (WP Rocket)
• Switch to PHP 8.2
• Change host if necessary

Concrete example:

A client had an LCP of 5.1 seconds. Their header image weighed 850 KB as a PNG. After converting it to WebP (120 KB) + preloading, the LCP dropped to 2.1 seconds. Result: +28% conversion rate on mobile.

What is it?

A measure of visual “jumps” during loading. Every time an element moves on the screen, it increases your CLS score.

Google’s thresholds:

• 🟢 Good : Less than 0.1
• 🟡 Needs improvement : Between 0.1 and 0.25
• 🔴 Poor : More than 0.25

Why is it important?

You’re on mobile, you start reading an article, and suddenly BAM, everything drops 300 pixels because an ad has just loaded above. You have to scroll again to find where you were. It’s exasperating.

The most frequent causes:

1. Images without dimensions:

The browser doesn’t know how much space to reserve. When the image loads, everything shifts.

Solution: WP Rocket automatically adds the missing width and height attributes.

2. Web fonts that load late:

Your text first displays in Arial, then “jumps” when your Google Fonts font loads.

Solution: Use font-display: swap (WP Rocket does it automatically) or host your fonts locally (OMGF).

3. Ad banners:

You have Google AdSense ads that have no fixed size. When they load, they push your content down.

Solution: Reserve a fixed space for your ads with CSS:

.ad-container { min-height: 250px; width: 300px; }

Banners, notifications, popups that appear AFTER the initial load and push the content.

Solution: Display these elements as an overlay (on top of the content) instead of inserting them into the flow.

How to detect the culprit elements?

PageSpeed lists the elements that cause CLS. You can also use the “Performance” tab of Chrome DevTools to see in real time what moves.

Concrete example:

An e-commerce site had a CLS of 0.42 because of a promotional banner inserted at the top of the page 2 seconds after loading. By displaying this banner in a fixed position (sticky header) instead of inserting it into the flow, the CLS dropped to 0.06.

Important change: Google replaced FID (First Input Delay) with INP in March 2024. It is a more complete metric that measures responsiveness across ALL interactions, not just the first one.

The delay between the moment the visitor clicks a button / types text / opens a menu, and the moment something happens on screen.

Google’s thresholds:

• 🟢 Good : Less than 200ms
• 🟡 Needs improvement : Between 200ms and 500ms
• 🔴 Poor : More than 500ms

Why is it important?

If your INP is 600ms, it means there is a half-second delay between the moment the user clicks and the moment the menu opens. On an e-commerce site, that’s enough to frustrate and drive the customer away.

1. Too much JavaScript:

The browser is busy executing JavaScript code, so it can’t react immediately to the click.

Solution: Reduce unnecessary scripts, defer their loading, use minification.

2. Long tasks:

A script that monopolizes the processor for more than 50ms blocks all interactions.

Solution: Identify and defer heavy scripts (sliders, animations, analytics).

3. Slow server:

If an interaction requires a server call (form, filters, etc.) and your server takes 800ms to respond, the INP will be poor.

Solution:

• Switch to PHP 8.2 (30-40% boost)
• Enable object caching (Redis or Memcached)
• Optimize your database queries

How to test INP?

INP is hard to measure in the “lab” (artificial test). You need real user data. You can see your INP in:

• Google Search Console → Experience → Core Web Vitals (real data)
• Chrome DevTools → Lighthouse → “Navigation” mode

Concrete example:

A site with a complex mega-menu had an INP of 520ms. The menu loaded in JavaScript and required 400ms of computation. By pre-generating the menu in pure HTML (without JavaScript), the INP dropped to 110ms.

Don’t try to fix all 3 metrics to 100% immediately. Here is the order of importance:

1. LCP first (the most impactful)

• Optimize your main image
• Enable the cache
• Improve your TTFB

2. CLS next (the easiest to fix)

• Add image dimensions
• Fix the size of ad blocks
• Optimize font loading

3. INP last (the most complex)

• Reduce JavaScript
• Defer heavy scripts
• Optimize your server

Realistic goal:

A site with a score of 90-95/100 on mobile and Core Web Vitals all in the green (LCP < 2.5s, CLS < 0.1, INP < 200ms) is more than enough. Aiming for a perfect 100/100 can become counterproductive if it requires sacrificing features.

Reaching 100% on PageSpeed once is doable. Keeping it all year round is a profession.

Your site is alive. Every new article, every photo added, every plugin update can make your score drop again. A plugin that adds 200 KB of JavaScript, a theme that enables a new feature, an image uploaded at 4 MB because you were in a hurry… and poof, you’re back in the red.

The mistakes I see on 90% of sites:

1. The one-shot optimization

You optimize once, you’re happy with the result, and then you forget. 6 months later, you’re back to 45/100 without understanding why.

2. Updates that break everything

A plugin updates and re-enables JavaScript that you had disabled. Your theme adds a new Google Font. WooCommerce now loads its scripts everywhere instead of just on the shop.

3. The lack of monitoring

You don’t know that your site went from 2.1s to 4.8s loading time because nobody is watching.

That’s exactly where I come in.

In my maintenance plans, I don’t just optimize your site once. I monitor it continuously and step in as soon as it slows down:

• ✅ Automatic availability monitoring : it runs continuously; performance tracking depends on the measurements and scope agreed
• ✅ Optimization of new images : Every image you upload is automatically compressed to WebP
• ✅ Monthly database cleanup : I remove revisions, transients, orphan tables
• ✅ Tracked updates : backup and appropriate checks; testing arrangements and any staging environment are defined according to the site and the quote
• ✅ Server configuration : I make sure you stay on PHP 8.2+, HTTP/3, with the right extensions enabled
• ✅ Intervention volume defined in the quote : for a 3-hour-per-month plan, this volume covers all planned interventions, restores included. Unused hours are not carried over. Any foreseeable overrun is announced and subject to your approval

The result?

The aim is to limit slowdowns and to handle the problems identified within the agreed scope. Resolution times depend on the diagnosis; a Google ranking or perfect availability cannot be promised. The terms of sale and your quote specify the commitments.

Maintenance is not an expense, it’s an investment.

Every second gained = fewer visitors leaving = more conversions. On an e-commerce site making €10,000/month, gaining 2 seconds of loading time can generate €1,500 to €2,500 of additional revenue per month.

Do you want a fast site and peace of mind?