Category: Blog

A slow site doesn’t just frustrate users — it also hurts your SEO rankings, conversions, and credibility. Over the years, I’ve worked with clients who thought speed was all about installing a caching plugin. But real performance starts earlier — with architecture, development practices, and how you manage assets.

This is the checklist I personally follow to build fast WordPress sites that pass Core Web Vitals and perform well under real-world traffic.

---

1. 🧱 Use Lightweight Themes & Avoid Plugin Bloat

Speed starts with your foundation.

I always:

• Avoid multipurpose themes with 10 sliders and 30 demos
• Use lightweight themes like GeneratePress, Blocksy, or a custom-built base
• Audit every plugin — if it’s not needed, I remove it

👉 Rule of thumb: fewer plugins = fewer queries, scripts, and chances for conflict.

---

2. 📊 Optimize Database Queries (or Use Custom Tables)

Too many developers rely entirely on wp_postmeta and wp_options. That’s fine — until your site has 20,000 records.

I:

• Use custom tables when storing structured or repeatable data
• Optimize WP_Query with the right parameters (no_found_rows, fields => ids, etc.)
• Avoid autoloading unnecessary options

👉 A bloated wp_options table with too many autoloaded fields can drag down even simple pages.

---

3. ⚙️ Load Scripts Wisely (defer, async, conditionally)

Don’t load jQuery on every page. Don’t load your custom slider script when it’s not needed.

I:

• Enqueue scripts only when necessary (is_page() or is_single() conditions)
• Use defer and async where possible
• Minimize third-party embeds unless essential

👉 Less JS = faster TTI (Time to Interactive)

---

4. 🖼️ Image Optimization & Lazy Loading

I:

• Resize images before uploading (no need to use a 4000px photo on a 300px area)
• Use modern formats like WebP
• Add native lazy loading (loading="lazy" on <img> tags)

Bonus: I run assets through tools like TinyPNG or ShortPixel before they hit production.

---

5. 📦 Use Page Caching + Object Caching

While caching isn’t everything, it is essential.

I typically:

• Use LiteSpeed Cache (especially if hosted on LiteSpeed server)
• Enable object caching via Redis or Memcached for dynamic sites
• Set up server-level caching where possible (Cloudflare, hosting-level Varnish)

👉 Caching is the last 20% that makes your 80% work shine.

---

6. 🧼 Minify & Combine CSS/JS (Carefully)

I minify CSS and JS, but with caution — combining everything into one file doesn’t always help on modern HTTP/2 or HTTP/3 servers.

Instead:

• Use a smart build pipeline or a plugin like Autoptimize
• Minify only when assets are stable (no frequent changes)
• Exclude scripts that break with minification

---

7. 💡 Hosting Matters — Don’t Cheap Out

No amount of clean code can fix a $1/month shared hosting plan.

I recommend:

• Hostinger, Cloudways, or any VPS where you control server config
• Use object caching, PHP 8.x, and LiteSpeed or Nginx
• Don’t overpay for “WordPress-specific” features you don’t use

👉 Your site speed is only as good as your server response time.

---

🎯 Final Thoughts

Speed is more than a Lighthouse score — it’s about how the site feels to real users.

As a developer, I focus on writing lean code, minimizing server load, and ensuring assets are only loaded when they’re truly needed.

Want me to review your site or build a performance-optimized WordPress project from scratch?

👉 Let’s talk about your project →

After building dozens of custom plugins over the years — from simple feature toggles to complex admin dashboards — I’ve developed a checklist I follow in every plugin project. Whether the plugin is for client work, a white-label agency, or personal use, these five habits help ensure long-term maintainability, performance, and compatibility with other plugins and themes.

If you’re a WordPress developer (or hiring one), here’s what you should expect to see in quality plugin code.

1. 🏷️ Prefix Everything: Functions, Actions, Filters

WordPress loads everything into a global space, which means if two plugins use the same function name, filter hook, or even global variable — things break.

To avoid conflicts, I always prefix every:

• Function: function amit_prefix_save_data()
• Action or filter: add_action('init', 'amit_prefix_custom_init')
• Constant: define('AMIT_PLUGIN_VERSION', '1.0')

Why it matters:
WordPress plugins are often used together. Prefixing prevents clashes with core functions or other plugins — especially important in white-label or multisite setups.

---

2. 🧱 Use a Main Plugin Class or Namespace

Instead of cluttering the global space with dozens of functions, I organize everything inside a main class or use PHP namespaces.

namespace Amit\MyPlugin;

class Main {
    public function __construct() {
        add_action('init', [$this, 'init_hooks']);
    }

    public function init_hooks() {
        // Register post types, enqueue scripts, etc.
    }
}

I instantiate this class in the main plugin file and keep supporting code in separate files (includes/, admin/, etc.).

Why it matters:
This makes the plugin modular, testable, and scalable — especially when clients request new features later.

---

3. 🎯 Enqueue Scripts & Styles Properly (with filemtime for versioning)

I never hardcode <script> tags. Instead, I enqueue all assets using WordPress’s built-in hooks — like this:

function amit_enqueue_plugin_scripts() {
    $ver = filemtime(plugin_dir_path(__FILE__) . 'assets/script.js');
    wp_enqueue_script('amit-plugin-js', plugin_dir_url(__FILE__) . 'assets/script.js', [], $ver, true);
}
add_action('wp_enqueue_scripts', 'amit_enqueue_plugin_scripts');

This ensures:

• Scripts are loaded only when needed
• Versioning uses the actual file’s timestamp (helps with cache busting)
• Admin and front-end scripts can be handled separately

Why it matters:
Better performance, no stale scripts, and fewer cache-related bugs for end-users.

---

4. 🔐 Sanitize and Validate Everything

This one’s non-negotiable. Whether it’s a settings form, AJAX endpoint, or REST API handler — I always sanitize input and validate output.

$clean_name = sanitize_text_field($_POST['user_name']);
$email = sanitize_email($_POST['user_email']);

if (!is_email($email)) {
    wp_send_json_error('Invalid email.');
}

For repeatable fields, I use array_map() with sanitization callbacks. For textareas, I allow a safe subset using wp_kses_post().

Why it matters:
Poor validation opens up security risks like XSS, injection, or unwanted data loss. Sanitization protects both the plugin and the site it runs on.

---

5. 🚫 Avoid Unnecessary Autoloaded Options or Queries

When storing plugin settings, I avoid bloating the wp_options table with large autoloaded data. I either:

• Use autoload => no when adding options
• Store structured data in custom database tables (especially for large datasets)

add_option('amit_plugin_settings', $settings_array, '', 'no');

Or, I create custom tables with optimized indexes when needed:

CREATE TABLE wp_amit_plugin_data (
    id bigint NOT NULL AUTO_INCREMENT,
    user_id bigint,
    meta_key varchar(100),
    meta_value longtext,
    PRIMARY KEY (id),
    INDEX (user_id)
);

Why it matters:
Keeping the wp_options table lean improves performance across the entire site — not just the plugin.

👨‍💻 Final Thoughts

A well-structured plugin should be invisible to users — and easy to extend or debug for developers. These five practices help me keep my plugins clean, conflict-free, and optimized for the long haul.

If you’re a developer, I hope this helped you sharpen your workflow. And if you’re a business owner or agency — this is the level of care you should expect from any custom plugin you pay for.

Have questions or need help building your own plugin?
📩 Get in touch →