WordPress websites

WordPress has the best content editing experience of any available platform, which is why it runs a huge share of the web. Its reputation for being slow doesn’t come from WordPress. It comes from what people install on top of it.

This site is the demo

The page you’re reading runs on WordPress. It has a custom theme, no page builder, no jQuery on the front end, and a single CSS file and a single JavaScript file.

The metrics at the top of the homepage aren’t from a case study. They’re read in your browser, right now, through the browser’s own Performance API. It’s the most direct proof we can offer that the problem was never WordPress.

Where a slow WordPress site gets its weight

The page builder

Elementor, Divi and similar tools generate HTML with many layers of divs and enqueue the CSS for every widget you might ever use. A simple page ends up loading forty stylesheets. Each one is a request, and on a mobile connection a request costs more than a byte.

Overlapping plugins

The pattern we see most: two caching plugins installed at the same time, two WebP converters fighting over the same image, an SEO plugin and a schema plugin both outputting duplicate structured data. Each was installed to fix a symptom, and together they create a new problem.

Plugins for what CSS already does

Accordions, tabs, counters, carousels, a floating WhatsApp button. Each of these usually comes in as a plugin with its own JavaScript library. Modern HTML and CSS deliver all of them without a single script.

What we do differently

• A hand-written theme, with one template per page type. No generic widget library.
• Self-hosted fonts in a single variable font file, preloaded. No call to Google Fonts. That improves performance and settles the data-transfer question under the LGPD (Brazil’s data protection law).
• Inline critical CSS, with the rest loading without blocking rendering.
• Hand-picked plugins. Each one has to justify doing something the theme doesn’t.
• Structured data in the theme, in a single graph. Each entity declared once, not two competing versions.

You edit the content. We take care of the structure.

That split is what keeps the site fast after launch. You write in the WordPress block editor, the same one as always: publish posts, swap images, edit copy, create pages. What you can’t do is break performance, because the visual structure doesn’t live in the content.

In a page builder, content and layout live in the same place. That’s why a site built that way degrades with use: everyone who edits it adds a section, duplicates a block, drops in a widget. Three months later the homepage weighs twice what it did at launch.

Maintenance and security

Outdated WordPress is the most common way sites get hacked on the Brazilian web, and the entry point is almost always an abandoned plugin, not WordPress core, which is well maintained.

Fewer plugins means a smaller attack surface. On top of that, in what we deliver: core and plugins up to date, XML-RPC disabled, user enumeration through the API blocked, automated backups with tested restores, and an activity log of who changed what in the admin.

We can handle this under a maintenance contract, or hand it over documented to your team. What we won’t do is deliver a site that needs twelve plugins to work and call it done.

When WordPress isn’t the answer

It’s worth saying where it isn’t the best choice, because recommending WordPress for everything would be selling a tool instead of solving a problem.

• High-volume e-commerce. For a small catalog, WooCommerce works. For an operation with thousands of SKUs, multichannel inventory and marketplace integrations, a dedicated platform costs less overall.
• Applications with complex state. Dashboards with granular permissions, real-time calculations, simultaneous collaboration. That’s a custom web application, not a website.
• A single page with no editorial content. If nobody will edit anything after launch, the CMS is weight with no purpose.