DEV Community: Abiodun Paul Ogunnaike

WordPress Performance Part 2: Crushing LCP & Mastering Image Optimization for Core Web Vitals

Abiodun Paul Ogunnaike — Mon, 12 Oct 2026 10:24:47 +0000

In Part 1, we walked through trimming megabytes of script bloat from your-website: stripping Gutenberg editor dependencies from public blocks, banishing @import font waterfalls, and deferring jQuery. Those architectural fixes slashed Total Blocking Time (TBT) and eliminated render-blocking delays.

However, resolving script bloat is only half the battle. When auditing mobile Core Web Vitals, the most visible metric remains Largest Contentful Paint (LCP).

In our Lighthouse audit, mobile LCP clocked in at an agonizing 6.8 seconds, accompanied by a stark recommendation: "Improve image delivery: estimated savings of 1,718 KiB."

In this article, we'll dive into the exact steps we implemented to accelerate hero image delivery, eliminate bandwidth competition, and bring LCP firmly into the green (<2.5s).

Why Images Destroy Mobile Core Web Vitals

Images frequently account for 60% to 80% of a webpage’s total weight. On mobile devices with CPU and network throttling, poor image delivery triggers severe performance bottlenecks:

Delayed LCP Discovery: When a hero banner image is loaded via JavaScript or dynamic sliders, the browser doesn't discover the image URL until after CSS and scripts have executed.
Bandwidth Cannibalization: Slider blocks that eagerly download all slides simultaneously force the browser to divide network bandwidth among hidden slides instead of prioritizing the visible hero image.
Missing Lazy Loading: Below-the-fold cards (event feeds, blog teasers, partner logos) loading eagerly at page initialization clog the network queue.
Oversized Assets: Delivering a 2500×1667 desktop image to a 400px mobile viewport wastes hundreds of kilobytes per image.

Here is the engineering strategy we used to fix these bottlenecks.

Step 1: Prioritize the Hero Banner with `fetchpriority="high"` & `loading="eager"`

On modern websites, the hero banner is almost always the Largest Contentful Paint (LCP) element. By default, browsers treat all images with equal priority, queueing them behind other resources.

The Problem: Carousel / Slider Cannibalization

In many custom slider components or carousel blocks, images are generated in a loop without differentiating the active first slide from offscreen slides:

// 🛑 Bad: All slides loaded with default priority
const slidesHtml = slides.map(s => `
  <div class="home-banner-slide">
    <img src="${s.img}" alt="${s.title}" class="home-banner-image" />
  </div>
`).join('');

This causes the browser to download Slide 2, Slide 3, and Slide 4 concurrently with Slide 1, delaying the rendering of the only slide the visitor actually sees.

The Solution: Smart Slide Attribute Splitting

Configure your slider component to treat Slide 1 as a critical asset, while deferring all subsequent slides:

// ✅ Good: First slide prioritized, remaining slides deferred
const slidesHtml = slides.map((s, i) => `
  <div class="home-banner-slide">
    <img 
      src="${s.img}" 
      alt="${s.title}" 
      class="home-banner-image" 
      ${i === 0 
        ? 'fetchpriority="high" loading="eager"' 
        : 'loading="lazy" decoding="async"'} 
    />
  </div>
`).join('');

fetchpriority="high": Informs the browser's preload scanner that this image has maximum network priority.
loading="eager": Instructs the browser not to delay fetching the image.
loading="lazy" & decoding="async": Ensures offscreen slides don't consume a single byte of bandwidth until the user starts navigating the carousel.

Step 2: Preload the LCP Hero Image in `<head>`

Even with fetchpriority="high", if your hero banner is rendered inside a Web Component or dynamic block, the browser must parse the HTML body before discovering the image URL.

To achieve lightning-fast LCP, the browser should start downloading the hero banner the instant the initial HTML document response arrives.

The Solution: Server-Side Preload Hint

In your theme's functions.php, extract the hero image URL from the page's block attributes and emit a <link rel="preload"> tag directly in wp_head:

add_action('wp_head', function () {
    // Only target the front page or home page
    if (!is_admin() && (is_front_page() || is_home())) {
        global $post;
        if ($post instanceof WP_Post && has_block('your-website/home-banner-block', $post)) {
            $blocks = parse_blocks($post->post_content);
            foreach ($blocks as $block) {
                if ($block['blockName'] === 'your-website/home-banner-block' && !empty($block['attrs']['slides'][0]['imageSrc'])) {
                    $hero_img = esc_url($block['attrs']['slides'][0]['imageSrc']);
                    echo '<link rel="preload" as="image" href="' . $hero_img . '" fetchpriority="high">' . "\n";
                    break;
                }
            }
        }
    }
}, 1);

Why this matters: This moves hero image discovery from step 15 in the browser waterfall directly to step 1. The image begins downloading before external stylesheets or JavaScript bundles are even evaluated.

Step 3: Enforce Native Lazy Loading Across All Below-the-Fold Blocks

A typical homepage contains multiple dynamic sections below the fold:

Upcoming Events
Community News
Impact Stories
Partner Logos & Grids

If these cards render standard <img> tags without explicit loading attributes, the browser queues up dozens of image requests during initial page load, choking the main thread.

The Solution: Audit Dynamic Block Templates

Audit your theme's PHP block render functions and add native loading="lazy" and decoding="async":

<!-- In your custom card or event block template -->
<div class="card__img-wrapper">
    <img 
        class="card__img" 
        src="<?php echo esc_url($image_url); ?>" 
        alt="<?php echo esc_attr($title); ?>" 
        loading="lazy" 
        decoding="async"
    >
</div>

Global WordPress Attachment Filter

To ensure that all standard WordPress media library images rendered via core functions also benefit from non-blocking decoding, add this hook in functions.php:

// Ensure non-blocking image decoding across all attachment images
add_filter('wp_get_attachment_image_attributes', function ($attr) {
    if (!isset($attr['decoding'])) {
        $attr['decoding'] = 'async';
    }
    return $attr;
}, 10, 1);

decoding="async": Allows the browser to decode image raster data off the main thread, preventing UI jank and reducing Total Blocking Time during scrolling.

Step 4: Responsive Image Sizing & Layout Stability (CLS)

Lighthouse often flags: "Image file is larger than it needs to be for its displayed dimensions."

Serving a 2000px wide image into a 300px mobile card wastes data and forces mobile CPUs to perform expensive client-side image downscaling.

1. Leverage WordPress Responsive `srcset`

Instead of using raw image URLs with 'full', always register and request appropriate WordPress image dimensions:

// In functions.php
add_image_size('card-thumbnail', 600, 400, true);
add_image_size('hero-banner-mobile', 768, 500, true);

// In your template: use wp_get_attachment_image for automatic srcset & sizes
echo wp_get_attachment_image($thumbnail_id, 'card-thumbnail', false, [
    'class'   => 'card__img',
    'loading' => 'lazy',
]);

2. Prevent Cumulative Layout Shift (CLS)

When images lack explicit dimensions or aspect ratios, the browser cannot reserve space for them before they load, causing jarring layout shifts as images pop into view.

Add modern CSS aspect ratio rules to your image containers:

.card__img-wrapper {
    position: relative;
    width: 100%;
    aspect-ratio: 16 / 9;
    overflow: hidden;
    background-color: #f0f0f0; /* Low-contrast placeholder */
}

.card__img {
    width: 100%;
    height: 100%;
    object-fit: cover;
}

By defining aspect-ratio, the browser reserves exact bounding boxes before the image binary arrives, locking CLS at 0.000.

Step 5: Adopt Next-Gen Image Formats (WebP & AVIF)

Traditional formats like PNG and JPEG are inefficient for web delivery:

WebP: Offers 25%–35% smaller file sizes than JPEG with identical visual quality.
AVIF: Provides up to 50% compression savings compared to JPEG and supports superior color depth and high dynamic range.

WordPress Native Modern Format Support

Starting in WordPress 5.8 (WebP) and WordPress 6.5 (AVIF), WordPress natively supports next-gen image uploads:

// In functions.php: Enable AVIF and WebP generation on upload (WP 6.5+)
add_filter('image_editor_output_format', function ($formats) {
    $formats['image/jpeg'] = 'image/webp';
    $formats['image/png']  = 'image/webp';
    return $formats;
});

For existing media libraries, automated image optimization or server-level rewrites can convert your legacy library to WebP/AVIF without changing media URLs in your database.

The Combined Impact of Phase 1 + Phase 2

Combining Phase 1 (Script & Cache Optimization) and Phase 2 (Image & LCP Acceleration) delivers a complete performance transformation:

Metric	Before Optimization	After Phase 1 & Phase 2	Impact
Mobile Score	35	85–95+	🟢 Massive Jump
Total Blocking Time (TBT)	9,660 ms	< 200 ms	⚡ Instant Main Thread
Largest Contentful Paint (LCP)	6.8 s	< 1.8 s	🚀 73% Faster Rendering
Total Page Weight	~4.2 MB	~1.2 MB	📉 Over 65% Bandwidth Saved
Cumulative Layout Shift (CLS)	0.001	0.000	🎯 Rock-Solid Layout

Summary Checklist for Your WordPress Project

[x] Preload the LCP hero banner in wp_head with fetchpriority="high".
[x] Set fetchpriority="high" and loading="eager" on the first carousel slide; set loading="lazy" on all remaining slides.
[x] Add loading="lazy" and decoding="async" across all below-the-fold custom blocks.
[x] Define aspect-ratio on all image containers to permanently prevent layout shifts.
[x] Serve responsive srcset sizes and leverage modern WebP/AVIF formats.

WebVitals #WebDev #FrontendDevelopment #PageSpeed

PART 1 - https://dev.to/abbeymaniak/a-practical-walkthrough-of-real-world-wordpress-performance-optimizations-46fm

How I Built an Autonomous AI Refund Decision Engine with FastAPI, React, and LiteLLM

Abiodun Paul Ogunnaike — Mon, 05 Oct 2026 15:55:38 +0000

Customer returns and refund requests are among the costliest operational friction points for modern e commerce platforms. Traditional solutions force businesses to choose between two undesirable extremes:

Rigid rule engines that deny valid edge cases, frustrating loyal shoppers.
Naive generative chatbots that can be easily manipulated through prompt injection, promising free money and unauthorized chargebacks.

To solve this, I designed and built an autonomous AI Customer Support Refund System. It balances instant automated decisions with deterministic policy checks, velocity safeguards, and a supervisor review loop.

Here is a full breakdown of how the platform is architected and built.

1. High Level Architecture and the Tracer Bullet Approach

Instead of building individual layers in isolation, we followed the Tracer Bullet build strategy. Every development milestone implemented a thin, working slice through the database, backend services, AI decision layer, and user interface.

                    +--------------------------------+
                    |   React 18 + TypeScript SPA    |
                    | (Tailwind, Lucide, TanStack)   |
                    +---------------+----------------+
                                    |
                    Session Cookies (HTTP Only, Lax)
                                    |
                                    v
                    +--------------------------------+
                    |       FastAPI REST Layer       |
                    |  (Clean Architecture Services) |
                    +---------------+----------------+
                                    |
            +-----------------------+-----------------------+
            |                                               |
            v                                               v
+-----------------------+                       +-----------------------+
|  PostgreSQL 16 Engine |                       |  LiteLLM Policy Core  |
|  (SQLAlchemy 2 Async) |                       | (Ollama, OpenAI, Gem) |
+-----------------------+                       +-----------------------+

The Technology Stack

Backend: Python 3.11 with FastAPI, Pydantic 2, SQLAlchemy 2 (asyncio with asyncpg), and LiteLLM.
Database: PostgreSQL 16 with normalized relational models for customers, orders, order items, refund claims, LLM providers, and audit logs.
Frontend: React 18, TypeScript, Vite, TanStack Query (React Query), and Tailwind CSS.
Infrastructure: Fully containerized multi stage Docker Compose environment with health checks.

2. Deterministic Guardrails Meet Generative AI

One of the biggest pitfalls when integrating large language models into fintech or support operations is unpredictability. An LLM should not make decisions in an unconstrained void.

Our engine applies a layered decision pipeline:

[Customer Claim Submission]
            |
            v
+-------------------------------+
|  1. Fast Path Validation      | -> Window checks (within 30 days)
|     (Pure Code & Database)    | -> Item condition and final sale tags
+---------------+---------------+ -> Velocity & sum limits (7 day caps)
                |
                v
+-------------------------------+
|  2. Risk Scoring & History    | -> Lifetime return rate calculations
|     (Customer Profile Metrics)| -> Fraud cluster anomaly detection
+---------------+---------------+
                |
                v
+-------------------------------+
|  3. Structured AI Reasoning   | -> Evaluates nuanced testimony
|     (LiteLLM Provider Engine) | -> Strict JSON output schema
+---------------+---------------+ -> Auto fallback (OpenAI to Ollama)
                |
                v
+-------------------------------+
|  4. Audit Trail & Disposition | -> Approved: Instant settlement
|     (Immutable Event History) | -> Escalated: Queued for supervisor
+-------------------------------+ -> Denied: Policy citation logged

Structured Policy Output

The AI decision engine produces typed outputs enforcing structured Pydantic schemas:

class PolicyEvaluationResult(BaseModel):
    decision: Literal["Approved", "Denied", "Escalated"]
    confidence_score: float = Field(ge=0.0, le=1.0)
    reasoning_summary: str
    policy_citations: list[str]
    detected_red_flags: list[str]
    matched_rules: list[str]

If a prompt injection attack is attempted (such as ignoring return windows or commanding the agent to approve high value claims), the deterministic validation layer flags anomaly markers and immediately forces an Escalated state for human review.

3. Scoped Customer Portal and Real Time Claims History

Customers interact with a dedicated three step refund wizard and history dashboard:

Order and Item Selection: Displays verified purchases fetched strictly from session cookies. Items already claimed are disabled to prevent duplicate abuse.
Reason and Testimony Input: Captures the customer return justification with character boundary validation.
Instant Evaluation: Invokes the engine and renders a transparent verdict card with confidence percentage and detailed policy reasoning.

+---------------------------------------------------------------+
| AutoRefund Portal              Sarah Jenkins [Customer badge] |
+---------------------------------------------------------------+
|  [ File a Refund ]    [ My Claims (3) ]                       |
|---------------------------------------------------------------|
|  Total Claims: 3  |  Approved: 2  |  Under Review: 1          |
|---------------------------------------------------------------|
|  Search: [ Filter by item or claim number... ]  [All] [Appr]  |
|---------------------------------------------------------------|
|  Claim ID      Order      Date         Status      Action     |
|  REF-9021      ORD-104    Sep 26 2026  Approved   [Inspect]   |
|  REF-8842      ORD-089    Sep 20 2026  Escalated  [Inspect]   |
+---------------------------------------------------------------+

Slide Over Inspection Drawer

Clicking Inspect on any claim row opens a slide over drawer containing:

Complete order and refund item breakdowns.
The verbatim customer statement quote.
The AI policy evaluation with natural language rationale and confidence meters.
Supervisor override justification alerts when manual human intervention occurred.

4. Human in the Loop: The Supervisor Review Desk

Autonomous systems must always provide an escape hatch for human judgment.

When claims exceed velocity thresholds or involve high value items, the system places the request in an Escalated queue on the Admin Dashboard. Human supervisors can:

Review customer historical risk scores and lifetime spend.
Inspect the initial AI decision and model explanation.
Apply a Supervisor Override to approve or deny the claim, accompanied by mandatory written justification notes.
Every override event is immutably recorded in the audit logs with the supervisor identifier and timestamp.

5. Testing and Verification Rigor

A financial decision engine demands comprehensive automated testing. We built an automated test harness covering backend and frontend layers:

137 Backend Pytest Tests:
- Unauthenticated access rejection (HTTP 401).
- Session scoping and strict tenant isolation (confirming Customer A never sees Customer B data).
- Order ownership verification and duplicate claim blocks.
- LLM fallback mechanisms and structured JSON response parsing.
121 Frontend Vitest Tests:
- Segmented tab switching and URL query parameter preservation.
- Client side search filtering and status pill filtering.
- Slide over inspection drawer focus trap, Escape key handling, and accessibility.
- Real time cache invalidation upon claim submission.

All tests execute inside Docker containers, ensuring complete parity between local development and production environments.

6. What I Learned

Never let an LLM run without guardrails: Generative models are fantastic at interpreting messy human explanations, but hard constraints (deadlines, return caps, duplicate detection) belong in deterministic code.
Multi provider resilience is essential: Using LiteLLM allowed us to seamlessly route requests between cloud providers like OpenAI and Gemini, falling back to local Ollama instances during outages.
Session scoped security beats client provided parameters: Never trust the frontend to pass a customer identifier. Deriving user identity strictly from secure, HTTP only cookies eliminates impersonation attacks at the root.

Check out the full repository and architecture specs on GitHub!

https://github.com/abbeymaniak/ai-customer-support-refund

A practical walkthrough of real-world WordPress performance optimizations

Abiodun Paul Ogunnaike — Thu, 24 Sep 2026 08:49:02 +0000

When running a Google PageSpeed Insights or Lighthouse audit on a custom WordPress website, seeing a low mobile / desktop score (such as 30–40) alongside warnings like "Eliminate render-blocking resources", "Reduce unused JavaScript", and "Serve static assets with an efficient cache policy" is frustratingly common.

Many developers assume the only remedy is installing another heavyweight caching plugin. However, true long-term performance gains come from fixing fundamental bottlenecks in the theme itself: eliminating script bloat, optimizing font delivery, utilizing modern script loading strategies, and conditionally loading assets.

In this article, we'll walk through the exact steps we implemented on your-website to trim megabytes of unnecessary scripts, eliminate render-blocking delays, and streamline WordPress asset delivery.

The Initial Audit: What Went Wrong?

Our initial Lighthouse speed test revealed several common anti-patterns:

Gutenberg Editor Dependencies Leaking to the Frontend: Public-facing custom blocks were pulling in entire WordPress admin and React libraries.
Cache Busting via time(): Styles and scripts had dynamic timestamps, entirely defeating browser and CDN caching.
Render-Blocking Web Fonts via CSS @import: Google Fonts were being pulled synchronously inside multiple stylesheets.
Synchronous jQuery & jquery-migrate: Core jQuery was blocking the critical rendering path.
Redundant & Global Plugin Overhead: Heavy plugin assets were loading globally across 100% of pages, even where completely unused.

Here is how we addressed each issue step by step.

Step 1: Strip Gutenberg Admin Dependencies from Frontend Block Scripts

WordPress custom blocks created with the Block API often share registration logic between the editor and the frontend. A common oversight is passing editor packages into the frontend dependency array:

The Problem

// Bad: Loading editor runtime on public pages
wp_enqueue_script(
    'your-website-banner-block',
    get_template_directory_uri() . '/assets/scripts/banner.js',
    ['wp-blocks', 'wp-element', 'wp-editor', 'wp-components', 'jquery'], // 🛑 Heavy bloat!
    YOUR_THEME_VERSION,
    true
);

When you specify 'wp-blocks', 'wp-element', or 'wp-editor' as dependencies:

WordPress automatically enqueues React, react-dom, lodash, and the complete Gutenberg block parser runtime.
It injects API fetch handlers and triggers blocking background requests (/wp-json/wp/v2/users/me and rest-nonce).
The payload sent to visitors increases by over 1.5–2.0 MB of unneeded JavaScript.

The Solution

Audit your frontend scripts. If a script only handles DOM manipulation, sliders, or UI toggles on the frontend, it does not need WordPress editor packages.

// Good: Only declare what the frontend script actually uses
wp_enqueue_script(
    'your-website-banner-block',
    get_template_directory_uri() . '/assets/scripts/banner.js',
    ['jquery'], // or [] if refactored to vanilla JavaScript
    YOUR_THEME_VERSION,
    [
        'strategy'  => 'defer',
        'in_footer' => true,
    ]
);

Key Takeaway: Reserve 'wp-blocks', 'wp-element', and 'wp-editor' exclusively for enqueue_block_editor_assets (the admin editor screen). Keep frontend enqueues lean.

Step 2: Stop Using `time()` for Asset Versioning

During development, it’s tempting to pass time() as the version argument to avoid caching while making frequent changes. However, leaving it in production is detrimental to performance.

The Problem

// Bad: Generates a new query string on every single request
wp_enqueue_style('your-website-style', get_stylesheet_uri(), array(), time());

This generates URLs like style.css?ver=1726312489. Because the version changes every second:

Browsers never cache your CSS or JS files.
Edge caches (Cloudflare, Fastly, etc.) treat every visit as a cache miss.
Repeat visitors must re-download the entire stylesheet and script bundle on every page view.

The Solution

Use a centralized, static theme version constant (or file modification time if strictly needed during staging):

// In functions.php
if (!defined('YOUR_THEME_VERSION')) {
    define('YOUR_THEME_VERSION', '1.0.4');
}

// In your enqueue functions
wp_enqueue_style('your-website-style', get_stylesheet_uri(), array(), YOUR_THEME_VERSION);

Whenever you deploy an update, increment YOUR_THEME_VERSION once. Browsers will cache assets indefinitely and only re-fetch them when you release a new version.

Step 3: Eliminate CSS `@import` & Modernize Font Loading

Loading web fonts via CSS @import declarations is one of the biggest contributors to slow Largest Contentful Paint (LCP) and First Contentful Paint (FCP).

The Problem

// In SCSS or CSS
@import url("https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap");

When a browser encounters @import:

It pauses CSS parsing.
It makes a blocking network roundtrip to fetch Google's CSS stylesheet.
Only then does it discover the actual font files (.woff2) and begin downloading them.
If multiple stylesheets include @import, this blocking waterfall repeats.

The Solution

Remove all @import url(...) rules from your stylesheets and SCSS files.
Add preconnect hints in your theme's functions.php to resolve the DNS and TLS handshake early:

add_filter('wp_resource_hints', function ($hints, $relation_type) {
    if ('preconnect' === $relation_type) {
        $hints[] = [
            'href'        => 'https://fonts.googleapis.com',
            'crossorigin' => 'anonymous',
        ];
        $hints[] = [
            'href'        => 'https://fonts.gstatic.com',
            'crossorigin' => 'anonymous',
        ];
    }
    return $hints;
}, 10, 2);

Enqueue the font centrally in <head> with display=swap:

wp_enqueue_style(
    'your-website-google-fonts',
    'https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap',
    array(),
    null
);

display=swap instructs the browser to immediately render text using a system fallback font, seamlessly swapping in the custom web font once loaded. This eliminates Flash of Invisible Text (FOIT).

Step 4: Defer jQuery and Strip `jquery-migrate`

Historically, WordPress loaded jQuery synchronously in the <head> to support legacy plugins that inject inline jQuery calls in the body. In modern setups, this severely delays page rendering.

1. Remove `jquery-migrate` on Frontend

jquery-migrate is only required for legacy plugins using deprecated jQuery 1.x APIs. Removing it saves unnecessary HTTP requests and ~10 KB of blocking script execution:

add_action('wp_default_scripts', function ($scripts) {
    if (!is_admin() && !empty($scripts->registered['jquery'])) {
        $scripts->registered['jquery']->deps = array_diff(
            $scripts->registered['jquery']->deps,
            ['jquery-migrate']
        );
    }
});

2. Defer Core jQuery (WordPress 6.3+)

WordPress 6.3 introduced native script loading strategies (defer and async). You can instruct WordPress to defer jQuery on non-admin pages:

add_action('wp_enqueue_scripts', function () {
    if (!is_admin()) {
        wp_script_add_data('jquery', 'strategy', 'defer');
        wp_script_add_data('jquery-core', 'strategy', 'defer');
    }

    // Defer your theme's custom scripts as well
    wp_enqueue_script(
        'your-website-global',
        get_template_directory_uri() . '/assets/scripts/global.js',
        ['jquery'],
        YOUR_THEME_VERSION,
        [
            'strategy'  => 'defer',
            'in_footer' => true,
        ]
    );
});

3. Safeguard Inline Event Handlers

If your theme renders inline scripts (such as reCAPTCHA or tracking handlers in wp_footer), avoid calling jQuery(document).ready(...) directly in raw <script> tags, because deferred jQuery will not have executed yet when the HTML parser hits that inline tag.

Instead, use standard Vanilla JavaScript:

// Instead of jQuery(document).on('submit', 'form', handler):
document.addEventListener('submit', function (event) {
    if (event.target && event.target.tagName === 'FORM') {
        // Execute form logic safely
    }
});

Step 5: Dequeue Redundant Third-Party Plugin Assets

As custom themes evolve, features originally handled by plugins (such as back-to-top buttons, social sharing buttons, or mobile drawers) are frequently rewritten as native, lightweight theme components.

However, inactive or redundant plugins often remain installed and continue injecting styles and scripts into every page.

add_action('wp_enqueue_scripts', function () {
    // Dequeue redundant general plugin assets handled natively by your-website
    wp_dequeue_style('redundant-plugin-style');
    wp_dequeue_style('redundant-plugin-fonts');
    wp_dequeue_script('redundant-plugin-script');
}, 100);

By auditing active plugins and dequeuing obsolete stylesheets and scripts, you remove duplicate network payloads without affecting user experience.

Step 6: Conditionally Load Heavy Plugin Assets (Forms & Anti-Spam)

Popular plugins like contact form managers and security/spam verifiers often enqueue their JavaScript and CSS across 100% of your website's pages, even on simple text articles and archive pages where no forms exist.

The Problem

A visitor reading a blog post or an about page is forced to download form validation scripts, styling bundles, and reCAPTCHA libraries that will never be used on that page.

The Solution: Smart Conditional Dequeuing

Instead of loading form assets globally, only keep them active on pages where forms are actually present.

add_action('wp_enqueue_scripts', function () {
    global $post;

    // Check if the current page actually has a form
    // (Be sure to check for custom popup banners or modals that embed forms!)
    $has_form = is_front_page() || is_home() || (
        is_a($post, 'WP_Post') && (
            has_shortcode($post->post_content, 'contact-form-7') ||
            has_block('contact-form-7/form', $post) ||
            has_block('your-website/notification-bar-block', $post) ||
            stripos($post->post_content, 'contact-form-7') !== false
        )
    );

    // If no form is present, dequeue the form assets
    if (!$has_form) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
        wp_dequeue_script('form-anti-spam');
        wp_dequeue_style('form-anti-spam-css');
    }
}, 99);

Important Pro Tip: If your homepage or header contains an interactive popup banner or modal with an embedded registration form, ensure your condition explicitly includes is_front_page() or checks for your banner block. Otherwise, selective dequeuing might strip the AJAX handlers from your popup form!

The Results

Applying these optimizations produced immediate, measurable improvements:

Payload Reduction: Over 1.5 MB of unnecessary JavaScript (React & Gutenberg editor dependencies) was eliminated from the public frontend.
Render-Blocking Clearance: Removing @import fonts, dequeuing jquery-migrate, and deferring core jQuery reduced initial render blocking by hundreds of milliseconds.
Effective Caching: Replacing time() with static versioning enabled proper browser caching and CDN hit ratios for all repeat visitors.
Zero Lost Functionality: Interactive blocks, form popups, and native animations continue to work seamlessly.

Conclusion

Optimizing WordPress performance doesn't require stripping away interactive features or relying solely on complex caching plugins. By auditing asset dependencies, modernizing script loading strategies, and delivering assets only where they are genuinely needed, you can deliver an ultra-fast experience to your visitors.

Have you audited your custom Gutenberg blocks and plugin enqueues recently? Let us know in the comments below!

Why I Added Tailscale to My VPS: Secure Access Without Relying on a Static IP

Abiodun Paul Ogunnaike — Tue, 08 Sep 2026 15:29:20 +0000

Managing a VPS from a home or office network sounds straightforward until your internet provider starts changing your public IP address.

That was one of the problems I ran into recently.

I had a VPS with some administrative resources restricted to specific IP addresses. The idea was simple: only my trusted IP should be able to access certain services.

The problem?

My ISP uses dynamic public IP addresses.

Every time my public IP changed, I potentially lost access to those IP-restricted resources.

Instead of continuously updating firewall rules whenever my IP changed, I decided to introduce Tailscale.

This article explains what Tailscale is, why it can be useful for VPS administration, and how to set it up on a Linux VPS and a Mac.

What is Tailscale?

Tailscale is a networking platform built around WireGuard that allows your devices and servers to communicate over a private network.

Tailscale calls this private network a tailnet.

Instead of relying on the public IP address of your VPS, devices connected to your tailnet can communicate using private Tailscale addresses, typically in the 100.x.x.x range.

For example:

Mac
  |
  | Tailscale
  |
  v
Private Tailnet
  |
  v
VPS
100.x.x.x

Tailscale describes itself as a zero-trust, identity-based connectivity platform, and it uses WireGuard for encrypted point-to-point connections.

The important part for me wasn't just encryption.

It was stable private connectivity between my devices and my VPS.

Why Would You Use Tailscale?

There are several reasons Tailscale can be useful.

1. Your ISP Uses Dynamic IP Addresses

This was my main reason.

Imagine you configure a firewall rule like:

Allow SSH
Source: 102.143.20.123/32

That means only that specific IP address can connect.

This is useful from a security perspective.

But if your ISP changes your public IP:

Yesterday:
102.143.20.123

Today:
105.131.95.49

your firewall rule is now outdated.

You have to manually update it.

With Tailscale, your Mac and VPS can communicate over your tailnet regardless of your ISP's current public IP.

Instead of depending on:

My ISP public IP
        ↓
      VPS

you have:

My Mac
   ↓
Tailscale
   ↓
Private tailnet
   ↓
VPS

This means I can maintain stable private access without constantly updating IP allowlists because my ISP changed my public IP.

2. Secure Access to Your VPS

SSH is already encrypted, but exposing SSH to the public internet means your server is continuously reachable by internet scanners and automated login attempts.

Tailscale provides another way to access your server over your private tailnet.

For example:

ssh root@100.89.121.90

instead of:

ssh root@your-public-ip

The 100.82.128.80 address is a Tailscale address in this example.

Tailscale's documentation specifically supports using Tailscale to SSH into Linux machines over the tailnet.

3. You Don't Need to Know Your Current Public IP

Before using Tailscale, I might need to check my current public IP before accessing an IP-restricted service.

With Tailscale, my devices have stable identities on the tailnet.

That makes remote administration much more predictable.

4. Access Services That Shouldn't Be Public

Not every service running on a VPS needs to be accessible from the entire internet.

For example, you might have:

Public
├── HTTP :80
└── HTTPS :443

Private
├── Admin dashboard
├── Database administration
├── Internal monitoring
├── Development tools
└── SSH administration

Tailscale can be useful for the private portion.

Instead of exposing every administrative service publicly, you can make certain services reachable only through your tailnet.

5. You Can Connect More Than Just Your Laptop

Tailscale isn't limited to:

Mac → VPS

You can connect:

Mac
Laptop
Phone
VPS
Home server
Cloud server
Development machine

and control which devices can communicate with which resources.

Tailscale's access-control system is designed around identity and least-privilege access, allowing policies to define which users and devices can access specific resources.

Setting Up Tailscale on a Linux VPS

Let's walk through a basic setup.

I'm using an Ubuntu-based VPS for this example.

Step 1: Install Tailscale

On the VPS:

curl -fsSL https://tailscale.com/install.sh | sh

This is the installation method documented by Tailscale for mainstream Linux distributions.

After installation:

tailscale version

You should see the installed version.

For example:

1.102.3

Step 2: Authenticate the VPS

Run:

sudo tailscale up

Tailscale will provide an authentication URL.

Open the URL in your browser and authenticate with your Tailscale account.

Once completed, the VPS becomes part of your tailnet.

Step 3: Check the Tailscale Connection

Run:

tailscale status

You should see your VPS and other devices connected to your tailnet.

You can also retrieve the VPS's Tailscale IPv4 address:

tailscale ip -4

For example:

100.89.121.90

That address is what you can use for private communication with the VPS.

Step 4: Install Tailscale on Your Mac

Install Tailscale on your Mac and sign in using the same Tailscale account.

After both devices are connected, you should have something similar to:

Mac
100.x.x.x
   |
   | Tailscale
   |
   v
VPS
100.89.121.90

Step 5: Test SSH Through Tailscale

From your Mac:

ssh root@100.89.121.90

You can also explicitly specify an SSH key:

ssh -i ~/.ssh/your-key \
    -o IdentitiesOnly=yes \
    root@100.89.121.90

The important part is that the connection is going through the VPS's Tailscale address rather than its public IP.

Tailscale's documentation also supports using MagicDNS, allowing you to connect using a machine hostname instead of remembering the 100.x.x.x address.

Making SSH Easier with ~/.ssh/config

Typing the entire SSH command every time isn't necessary.

On your Mac:

nano ~/.ssh/config

Add:

Host my-vps
    HostName 100.89.121.90
    User root
    IdentityFile ~/.ssh/your-key
    IdentitiesOnly yes

Now you can simply run:

ssh my-vps

This becomes particularly useful when you have multiple servers and multiple SSH keys.

Tailscale vs a Traditional VPN

Tailscale is often described as a VPN, but the experience is different from configuring a traditional VPN server yourself.

With a traditional VPN setup, you might have to manage:

VPN server
Certificates
Routing
Firewall rules
NAT
Client configuration
Key management

Tailscale handles much of the networking complexity for you.

It uses WireGuard underneath and provides identity and access-control features around the network.

That's one reason it is attractive for developers and infrastructure administrators who don't want to manually build and maintain a VPN infrastructure.

Tailscale and Firewalls

One important thing to understand is that Tailscale does not automatically replace your firewall.

You can still use:

Contabo Firewall
        ↓
UFW
        ↓
Tailscale
        ↓
Application

Tailscale is designed to work alongside existing firewalls, and its networking can often work without additional firewall configuration because of NAT traversal.

Your firewall should still be configured according to what your server actually needs.

Should You Close Port 22?

This depends on your architecture.

If you use Tailscale exclusively for SSH, you can potentially remove public SSH access and use Tailscale SSH or SSH over the Tailscale network.

Tailscale's documentation even recommends closing the public SSH port after verifying Tailscale SSH access when appropriate.

However, this isn't always practical.

For example, if you have a CI/CD system using GitHub-hosted runners that connects to your VPS over public SSH, closing port 22 would break that deployment workflow unless you redesign the deployment architecture.

In that situation, you can keep port 22 publicly reachable while still using Tailscale for your own administrative access.

Tailscale SSH

Tailscale also has a feature called Tailscale SSH.

Instead of relying on traditional SSH key management, Tailscale can manage SSH authentication and authorization using your tailnet identity and access policies.

You can enable it with:

tailscale set --ssh

However, I recommend understanding your existing SSH setup before switching to Tailscale SSH on a production server.

You don't necessarily need Tailscale SSH just to benefit from Tailscale networking.

You can simply use:

Tailscale networking
+
Traditional SSH

which is the approach I used for my VPS.

A Practical VPS Security Architecture

A setup I like is:

                    Internet
                       |
              +--------+--------+
              |                 |
           HTTPS             SSH :22
              |                 |
              v                 v
        Public Services      VPS Firewall
                                |
                                v
                              SSH
                                ^
                                |
                         Tailscale network
                                ^
                                |
                              My Mac

Then I can keep public services public while using Tailscale for private administration.

For example:

Public
├── 80/tcp
└── 443/tcp

Restricted / Administrative
├── SSH
├── Admin interfaces
├── Internal tools
└── Monitoring

What Tailscale Doesn't Solve

Tailscale isn't a replacement for general server security.

You should still consider:

SSH keys instead of passwords
Disabling SSH password authentication
Avoiding root for automated deployments
Using dedicated deployment users
Keeping the operating system updated
Configuring a firewall
Using least-privilege access
Monitoring authentication attempts
Using Fail2ban where appropriate
Protecting application credentials
Backups

Tailscale gives you a better networking and access layer; it doesn't magically make an insecure server secure.

My Main Takeaway

The biggest reason I added Tailscale to my VPS wasn't simply:

"I need a VPN."

It was:

"I need reliable private access to my infrastructure without depending on my ISP's changing public IP address."

That distinction matters.

If your ISP gives you a dynamic IP and you've built firewall rules around your current address, eventually you'll probably run into the same problem:

ISP changes IP
      ↓
Firewall rule becomes outdated
      ↓
Access breaks
      ↓
Update firewall
      ↓
ISP changes IP again

Tailscale changes the model:

Mac
 ↓
Tailscale identity
 ↓
Private tailnet
 ↓
VPS

Now my access doesn't depend on whatever public IP my ISP happens to assign me that day.

For anyone managing a VPS from a dynamic residential or office connection, Tailscale is worth considering.

It is particularly useful when you need private access to infrastructure without wanting to build and maintain a traditional VPN yourself.

Useful Resources

Mastering Zero-Downtime Deployments with Laravel Deployer

Abiodun Paul Ogunnaike — Wed, 26 Aug 2026 11:06:16 +0000

How I achieved zero-downtime deployments using PHP Deployer for my Laravel app, and the critical caching and Horizon worker issues I had to solve.

Deploying a Laravel application shouldn't mean taking your site offline. For a long time, I used simple git pull scripts or basic FTP, which often resulted in momentary downtime or broken states if a user visited exactly while composer install was running.

To solve this for my platform, CelebrateMe, I migrated to Deployer a powerful, PHP-based deployment tool that makes zero-downtime deployments incredibly easy.

However, the journey wasn't entirely smooth. I ran into a couple of frustrating issues regarding Deployer's Git caching and Laravel Horizon worker memory that had me pulling my hair out.

Here is how I set it up alongside GitHub Actions to automate the process, the issues I faced, and exactly how I fixed them.

Triggering Deployments with GitHub Actions

To fully automate the CI/CD pipeline, I connected Deployer to GitHub Actions. Instead of manually running dep deploy from my local machine, I configured a GitHub Actions workflow that runs whenever I push to the main or beta branch.

The workflow handles building my frontend assets and then securely triggers Deployer (via an SSH key and secret tokens) to pull the latest code and deploy it to the server. This means every push automatically triggers a zero-downtime deployment without any manual intervention!

How Zero-Downtime Deployment Works

Deployer achieves zero-downtime by maintaining a specific directory structure on your server:

/www/wwwroot/my-app/
├── current -> /www/wwwroot/my-app/releases/21  (Symlink to the latest release)
├── releases/
│   ├── 19/
│   ├── 20/
│   └── 21/  (The active release)
└── shared/
    ├── .env
    └── storage/

When you run dep deploy, Deployer does not overwrite your live code. Instead, it:

Creates a brand new folder in releases/ (e.g., releases/22).
Clones your GitHub repository into that new folder.
Runs composer install, npm run build, and php artisan migrate entirely in the background inside releases/22.
Finally, it updates the current symlink to point to releases/22 in a fraction of a second.

Because the web server (Nginx/Apache) points to the current symlink, the transition is instantaneous. Zero downtime!

The Problem: Deployer's Git Cache (`.dep/repo`)

By default, to make deployments faster, Deployer tries to cache your Git repository on the server inside a hidden .dep/repo directory. Instead of doing a full git clone every time, it fetches the changes into this cached repo and then copies them to the new release folder.

The Issue I Faced

After a few successful deployments, my deployments suddenly started failing mysteriously. Deployer would get stuck during the deploy:update_code step, complaining about uncommitted changes, corrupted git indices, or simply failing to pull the latest commits from the main branch.

Because the cached repository in .dep/repo had gotten out of sync or corrupted by a previous interrupted deployment, Deployer was completely locked up.

The Solution: The Clone Strategy

I realized that for my scale, a fresh clone takes only a few seconds anyway, and the reliability of a fresh clone far outweighs the slight speed boost of the Git cache.

I bypassed the cache completely by explicitly telling Deployer to use the clone strategy instead of the default cache strategy.

In my deploy.php file, I added this single line of configuration:

// Force Deployer to freshly clone the repository every time
set('update_code_strategy', 'clone');

Once I added this, Deployer stopped relying on the .dep/repo cache. It simply ran a fresh git clone into the new release directory every time. The deployments became 100% reliable and I never saw a Git cache corruption error again.

The Second Gotcha: Laravel Horizon and "Ghost" Code

Even after my deployments were succeeding perfectly and the current symlink was pointing to my new code, I noticed something terrifying in my error logs.

My queue workers (Laravel Horizon) were crashing with errors referencing line numbers and logic from old code that I had completely removed in my latest commit!

Why did this happen?

When Deployer updates the current symlink, your web server (Nginx) immediately starts serving the new PHP files for incoming HTTP requests.

However, Laravel Horizon (and queue workers) are long-running PHP daemon processes. They are started once and kept alive in memory. When you deploy new code, those long-running processes do not automatically know that the files on the hard drive have changed. They continue executing the old classes that were loaded into memory when the worker first started (potentially days ago!).

The Solution: Graceful Termination

To fix this, you must tell Horizon to gracefully terminate itself after a deployment finishes. If you are using a process monitor like Supervisor, it will instantly restart the Horizon process, and when it boots back up, it will load the fresh code from the new current symlink.

To automate this, hook into Deployer's lifecycle. In deploy.php, define a task to restart Horizon and run it right after the symlink is updated:

task('horizon:terminate', function () {
    run('cd {{release_or_current_path}} && php artisan horizon:terminate');
});

// Run this task automatically after the new code is live
after('deploy:symlink', 'horizon:terminate');

(Note: Don't use horizon:purge or queue:restart if you are specifically using Horizon. horizon:terminate is the official, safe way to instruct the master process to wrap up its current jobs and shut down).

Conclusion

Deployer is an absolute game-changer for deploying PHP applications, but understanding how it interacts with the server environment is crucial.

If you're setting up Deployer for a Laravel app, save yourself a headache and remember these two rules:

Use set('update_code_strategy', 'clone'); if you run into .dep cache corruption.
Always run php artisan horizon:terminate after your deploy:symlink step to ensure your background workers aren't running ghost code from memory!

Happy deploying!!!

How to Secure Your WordPress Dashboard and Prevent Clients from Breaking Their Sites

Abiodun Paul Ogunnaike — Mon, 10 Aug 2026 09:54:00 +0000

A guide on using Admin Extension Access Control to lock down WordPress plugins and prevent unauthorized changes.

How to Secure Your WordPress Dashboard and Prevent Clients from Breaking Their Sites

If you are a freelance web developer or run an agency, you have probably experienced the dread of a client accidentally bringing down their WordPress site. You spend weeks building a robust, performant website, only for an unauthorized user to log into the dashboard, start deactivating essential plugins, or install poorly coded extensions that break everything.

WordPress is fantastic because of its flexibility, but out of the box, any Administrator can touch everything.

To solve this problem, I want to introduce a lightweight solution: Admin Extension Access Control.

What is Admin Extension Access Control?

Admin Extension Access Control is a WordPress plugin designed to give you granular control over who can see, modify, install, or delete plugins on your site.

Built for modern environments (PHP 8.1+ and WordPress 6.0+), it allows you to configure strict role-based access rules without writing custom PHP functions in your functions.php file every time.

Key Features

Global Lockdown: Completely remove the plugins page for specific user roles.
Granular Permissions: Restrict the ability to add, delete, activate, deactivate, or install plugins on a per-role basis.
Exempt Users Whitelist: Designate trusted administrators (like yourself) who bypass all lockdown rules. Only exempt users can configure the access control settings.
Dashboard Cleanup: Hide the plugins menu item from unauthorized users to keep the dashboard less confusing for clients.

How It Works

Once installed and activated, the user who activates the plugin is automatically added to the Exempt Users list. This prevents you from accidentally locking yourself out.

From the settings panel, you can select which roles should be restricted from managing plugins. For example, you can give your client an "Administrator" role (so they feel in control of their site) but restrict their ability to install or delete plugins. If they try to access the restricted URLs directly, they will be safely redirected.

What's Next?

The plugin is currently actively developed, and there are some exciting advanced features on the roadmap:

Individual Plugin Selection: Hide specific plugins from users while leaving others visible.
Activity & Audit Logs: A timestamped log of all access attempts and plugin visibility events.(Coming soon)
Slack Notifications: Get instant alerts when someone attempts to breach a lockdown rule.(Coming soon)
Multisite Compatibility: Manage rules across a network of sites.(Coming soon)

Conclusion

Securing the WordPress admin area is a critical step in maintaining the longevity and stability of your client projects. By restricting plugin access, you save yourself hours of troubleshooting and protect your clients from their own curiosity.

Check out the repository on (https://wordpress.org/plugins/restrictify-extension-access-control/) to contribute, or download the latest release to try it out on your next project!

If you find it useful, let me know in the comments below!

Laravel Packages Every Developer Should Know (After Building a Real-World Product)

Abiodun Paul Ogunnaike — Thu, 30 Jul 2026 18:35:36 +0000

Laravel is one of my favorite frameworks because it allows you to move from idea to production incredibly fast. But after spending months building CelebrateMe a platform that helps people celebrate life's special moments through virtual gifts, wishlists, messages, and verified vendors—I realized something.

I wasn't just using Laravel.

I was relying heavily on the incredible ecosystem around it.

Some packages solved problems that would have taken days (or weeks) to build myself. Others helped me monitor, debug, and secure the application as it grew.

Here are the Laravel packages I now consider essential for almost every project.

1. Laravel Sanctum

Use it for: API Authentication

CelebrateMe has a Laravel API with a React frontend, so authentication needed to be secure without adding unnecessary complexity.

Laravel Sanctum was the perfect choice.

It provides:

Personal access tokens
SPA authentication
Mobile API authentication
Lightweight implementation

For most APIs, Sanctum is more than enough.

2. Laravel Horizon

Use it for: Queue Monitoring

As CelebrateMe grew, background jobs became increasingly important.

Things like:

Sending emails
Processing uploads
Notifications
Payment-related jobs

Instead of wondering whether jobs were running correctly, Horizon gave me a beautiful dashboard to monitor everything in real time.

If you're using queues and not using Horizon, you're missing out.

3. Laravel Telescope

Use it for: Debugging

Telescope quickly became one of my favorite development tools.

Instead of scattering dd() statements throughout my code, I could inspect:

Requests
SQL queries
Jobs
Exceptions
Cache operations
Notifications

It made debugging significantly easier.

4. Spatie Laravel Permission

Use it for: Roles & Permissions

CelebrateMe has multiple user types, each requiring different permissions.

Managing authorization manually would have become difficult very quickly.

Spatie's Permission package made it straightforward to assign roles and permissions while integrating cleanly with Laravel's authorization system.

5. Laravel Excel

Use it for: Importing and Exporting Data

Every business application eventually needs reporting.

Whether it's exporting users, vendors, or financial reports, Laravel Excel saves an enormous amount of development time.

6. Spatie Media Library

Use it for: File Management

Users upload profile pictures, event images, product photos, and other assets.

Media Library handles:

Multiple collections
Image conversions
Cloud storage
Responsive images

Instead of building a custom media management solution, I could focus on building product features.

7. Laravel Activity Log

Use it for: Audit Trails

As applications grow, knowing who changed what becomes increasingly valuable.

Whether it's an administrator updating information or users modifying their profiles, Activity Log creates a reliable audit trail with minimal effort.

8. Laravel Pint

Use it for: Code Formatting

This may seem like a small addition, but it improves team productivity.

Instead of discussing formatting during code reviews, Pint keeps everything consistent automatically.

One command:

./vendor/bin/pint

That's it.

9. Laravel Pulse

Use it for: Application Monitoring

Performance issues are much easier to solve when you can actually see what's happening.

Pulse provides visibility into:

Slow requests
Database performance
Cache usage
Queue health

It's a great addition once your application reaches production.

10. Laravel Socialite

Use it for: Social Authentication

If your application supports "Sign in with Google" or GitHub, don't build OAuth yourself.

Socialite makes authentication simple and integrates beautifully with Laravel.

My Biggest Lesson

One thing I learned while building CelebrateMe is that being productive isn't about writing the most code.

It's about writing the right code.

Laravel's ecosystem already solves many common problems with mature, well-maintained packages. Instead of reinventing those solutions, I could spend my time building features that actually made CelebrateMe better for its users.

That shift in mindset probably saved me weeks of development.

Honorable Mentions

Some excellent packages that are also worth exploring:

Laravel Reverb
Laravel Scout
Laravel Octane
Spatie Laravel Data
Spatie Query Builder
Barryvdh DomPDF
Intervention Image
Laravel Backup

Final Thoughts

These are the packages that have consistently made my development workflow faster and my applications more maintainable.

The Laravel ecosystem is one of the framework's biggest strengths, and learning which packages to trust is just as important as learning the framework itself.

I'm always looking for new tools.

What Laravel package do you install on every project?

I'd love to discover a few more.

# Using FlyEnv for Laravel and WordPress Development: My First Experience

Abiodun Paul Ogunnaike — Sun, 28 Jun 2026 00:43:29 +0000

As someone who works with both Laravel and WordPress projects often, one recurring challenge is managing local development environments efficiently. Switching between projects, maintaining configurations, and ensuring everything works consistently can sometimes take more effort than expected.

Recently, I decided to try FlyEnv and wanted to share my experience using it in my Laravel and WordPress workflow.

Why I Tried FlyEnv

I was looking for a simpler way to manage local development without spending too much time on setup and configuration.since upgrading XAMPP on mac was a hassle.

For my workflow, I wanted:

Easier environment management
Faster project setup
Less manual configuration
Ability to change from different versions of PHP
A smoother transition between Laravel and WordPress projects

My Experience Using FlyEnv

I tested FlyEnv with both Laravel and WordPress development projects.

The initial setup process was straightforward and did not take long. I was able to get started without spending excessive time trying to understand the interface or changing multiple settings.

For Laravel projects, I liked having a cleaner environment setup because it helped me focus more on building features rather than handling configuration issues.

For WordPress development, having a simpler local workflow also made things easier when working on themes, creating custom plugins and testing changes.

Since I regularly move between Laravel applications and WordPress projects, having a tool that helps reduce friction during development is valuable.

What I Liked

A few things stood out during my use:

Simple onboarding process
Cleaner development workflow
Less time spent on manual environment setup
Useful for handling different project types
Easy enough to start using quickly

Final Thoughts

Overall, my experience with FlyEnv for Laravel and WordPress development was positive.

I appreciate tools that reduce setup overhead and allow developers to spend more time writing code rather than troubleshooting environments.

I'll continue using it and testing additional workflows, but so far it has been a useful addition to my development setup.

Have you used FlyEnv in your projects? I'd be interested in hearing how others are using it in their workflows.

Building a Custom Home Casting App with Rust and React

Abiodun Paul Ogunnaike — Sat, 06 Jun 2026 13:26:17 +0000

Have you ever wanted a simple, lightweight way to cast videos from your phone to your smart TV without relying on third-party apps or dealing with complex Chromecast/DLNA setups? In this article, I am going to show you how I built "Home Cast" – a fully self-hosted video casting application using a Rust backend and a sleek React frontend.

The Architecture

The system consists of two main parts:

The Server (Rust/Axum): A fast, concurrent backend that handles video uploads via multipart forms and communicates with the TV using WebSockets.
The Client (React/Vite): A beautiful, modern interface that lets you upload videos and cast them with a single tap.

The magic relies on WebSockets. When you open the application on your TV's web browser, it connects to the Rust server's WebSocket endpoint and passively listens. When you upload a video from your phone, the Rust server saves it locally. Then, when you click "Cast to TV," the server broadcasts a message containing the new video URL to the TV. The TV receives the message, dynamically updates its HTML5 <video> player, and immediately begins playback.

Handling Browser Autoplay Policies

One major hurdle with web-based video players on TVs is the dreaded "Playback Blocked" error. Modern browsers restrict videos with audio from playing automatically unless the user interacts with the page first. I solved this by catching the rejected play promise and gracefully prompting the user to press the OK button on their TV remote (which simulates a click event). This bypasses the restriction and starts the stream seamlessly.

Why Rust?

Using Axum and Tokio made it incredibly easy to handle WebSocket connections and file uploads concurrently. Rust's memory safety guarantees mean we never have to worry about null pointer exceptions or memory leaks crashing our server right in the middle of movie night.

My Conclusion

Building your own casting app is a fun weekend project that teaches you a lot about WebSockets, multipart uploads, and HTML5 video APIs. Best of all, you get a custom media solution that works entirely on your local network, without any cloud dependencies!

I probably will be adding more features as time goes on, below is the github repo: https://github.com/abbeymaniak/cast-app

OAuth vs OAuth 2.0 Explained Simply for Beginners

Abiodun Paul Ogunnaike — Fri, 01 May 2026 18:34:00 +0000

If you’ve ever clicked "Continue with Google" or "Login with Facebook", then you’ve already used OAuth 2.0 even if you didn’t know it.

As developers, especially backend developers, understanding OAuth is important because it powers modern authentication and authorization systems across APIs, web apps, and mobile applications.

Let’s break it down in the simplest way possible.

What Problem Does OAuth Solve?

Imagine a third-party app wants access to your Google contacts or GitHub repositories.

Before OAuth existed, the only way to do this was to give the app your actual username and password.

That created huge security problems:

The app could store your password
Your credentials could be leaked if the app got hacked
You had no control over what the app could access OAuth solved this problem.

Instead of sharing your password, OAuth allows applications to access specific parts of your account using temporary tokens.

OAuth in Simple Terms

OAuth is an authorization framework that allows one application to access another application’s resources on behalf of a user without exposing the user’s password.

In simple English:

OAuth lets users give limited access to their data without sharing login credentials.

How OAuth 2.0 Works

Here’s the basic flow:

Step 1: User Clicks Login

A user clicks:

Continue with Google
Sign in with GitHub

Step 2: Redirect to Provider

The app redirects the user to the provider (Google, GitHub, Facebook).

Step 3: User Grants Permission

The provider asks:

Do you allow this app to access your profile/email?

Step 4: Token Issued

If approved, the provider generates an access token.

Step 5: Access Granted

The application uses that token to access allowed resources.

No password is shared with the third-party application.

OAuth vs OAuth 2.0

OAuth 2.0 is simply the modern version of OAuth.

It was designed to be:

Simpler
Faster
More flexible
Better for APIs and mobile apps Today, OAuth 2.0 is the industry standard.

Important OAuth 2.0 Terms

Access Token

A temporary token used to access resources.

Refresh Token

Used to generate a new access token when the old one expires.

Scope

Defines what the app can access:

email
profile
contacts
repositories

Authorization Server

The server responsible for issuing tokens.

Resource Server

The server that stores the protected data.

OAuth Is NOT Authentication

One of the biggest beginner mistakes is thinking OAuth is authentication.

OAuth handles:

Authorization -> What can this app access?

Authentication answers:

Who is this user?

This is why technologies like OpenID Connect exist on top of OAuth 2.0.

Why Backend Developers Should Learn OAuth

As a backend developer, OAuth 2.0 is everywhere:

API authentication
Social login systems
Microservices
SaaS integrations
Mobile app authentication

Frameworks like Laravel make implementation easier using tools like:

Laravel Passport
Laravel Sanctum

Understanding OAuth helps you build more secure systems and integrate with modern platforms confidently.

If you’re learning backend development, mastering OAuth 2.0 is one of the most valuable concepts you can add to your skill set.

Understanding and Fixing the N+1 Query Problem in Laravel

Abiodun Paul Ogunnaike — Wed, 22 Apr 2026 11:28:16 +0000

If you’ve ever built a Laravel app that felt fast locally but slow in production, there’s a good chance you’ve encountered the N+1 query problem.

It’s one of the most common performance issues in backend development and many developers don’t realize it’s happening.

What is the N+1 Query Problem?

The N+1 problem occurs when:

You run 1 query to fetch data
Then N additional queries to fetch related data

$users = User::all();

foreach ($users as $user) {
    echo $user->posts;
}

If you have 10 users, Laravel executes:

1 query for users
10 queries for posts

Total: 11 queries

Why This is Dangerous

At small scale, it looks harmless.

At scale:

100 users = 101 queries
1000 users = 1001 queries

This leads to:

Slow response times
High database load
Poor user experience

The Solution: Eager Loading

Laravel provides a simple fix using with():

$users = User::with('posts')->get();

Now Laravel executes:

1 query for users
1 query for posts

Total: 2 queries

Going Deeper: Nested Relationships

The problem becomes worse with nested relationships:

$users = User::all();

foreach ($users as $user) {
    foreach ($user->posts as $post) {
        echo $post->comments;
    }
}

The Fix:

$users = User::with('posts.comments')->get();

Quick Tips

Always inspect queries using Laravel Debugbar
Be cautious with API resources and transformers
Use eager loading by default when returning relationships

Conclusion

The N+1 query problem is easy to miss—but expensive to ignore.

If you’re serious about building scalable Laravel applications, mastering this concept is essential.

Built a Fully Offline AI Assistant on My Mac (Using Local LLMs)

Abiodun Paul Ogunnaike — Mon, 13 Apr 2026 18:31:50 +0000

Most AI apps today rely on APIs.

I wanted something different:

A fully offline AI assistant
Runs locally on my Mac
No API keys, no internet required

So I built one.

What I Built

A local AI assistant that:

Runs using a small language model (LLaMA / Mistral)
Works entirely offline
Supports chat + memory
Can be extended into a RAG system

Architecture

[CLI / Terminal] 
      ↓ 
[Node.js App] 
      ↓ 
[Ollama (Local AI Engine)] 
      ↓ 
[Local LLM]

Step 1 — Install Ollama on your local Machine

brew install ollama

Start the server:

ollama serve

Pull a model:

ollama run qwen2.5:latest

I choose qwen:2.5:latest because its just 4.7GB in size

Step 2 — Build CLI Assistant

mkdir local-ai-assistant 
cd local-ai-assistant 
npm init -y 
npm install axios readline-sync

Create a file in the local-ai-assistant folder

assistant.js

!/usr/bin/env node

const axios = require('axios');
const readline = require('readline-sync');

let history = [];

async function chat() {
    while (true) {
        const input = readline.question("You: ");

        history.push({ role: "user", content: input });

        const response = await axios.post('http://localhost:11434/api/chat', {
            model: 'qwen2.5:latest',
            messages: history,
            stream: false
        });

        const reply = response.data.message?.content || "No response";

        history.push({ role: "assistant", content: reply });

        console.log("AI:", reply);
    }
}

chat();

Step 3 — Make It a Global CLI Tool

Update package.json:

{
  "name": "local-ai",
  "bin": {
    "local-ai": "./assistant.js"
  }
}

Run:

npm link

Now you can run:

local-ai

What I Learned

Local LLMs are powerful enough for real use cases
You don’t need Python to start — Node works fine
The real value is in architecture, not just models

What i intend to build next

Add file-based memory (RAG)
Add tools (agent behavior)
Connect to Laravel API
Deploy via Docker + AWS

Final Thought

Running AI locally changes how you think about systems.

You’re no longer dependent on external APIs — you own the stack.

If you’re building something similar, I’d love to connect

https://github.com/abbeymaniak
https://linkedin.com/in/abiodun-paul-ogunnaike

DEV Community: Abiodun Paul Ogunnaike

WordPress Performance Part 2: Crushing LCP & Mastering Image Optimization for Core Web Vitals

Why Images Destroy Mobile Core Web Vitals

Step 1: Prioritize the Hero Banner with fetchpriority="high" & loading="eager"

The Problem: Carousel / Slider Cannibalization

The Solution: Smart Slide Attribute Splitting

Step 2: Preload the LCP Hero Image in <head>

The Solution: Server-Side Preload Hint

Step 3: Enforce Native Lazy Loading Across All Below-the-Fold Blocks

The Solution: Audit Dynamic Block Templates

Global WordPress Attachment Filter

Step 4: Responsive Image Sizing & Layout Stability (CLS)

1. Leverage WordPress Responsive srcset

2. Prevent Cumulative Layout Shift (CLS)

Step 5: Adopt Next-Gen Image Formats (WebP & AVIF)

WordPress Native Modern Format Support

The Combined Impact of Phase 1 + Phase 2

Summary Checklist for Your WordPress Project

How I Built an Autonomous AI Refund Decision Engine with FastAPI, React, and LiteLLM

1. High Level Architecture and the Tracer Bullet Approach

The Technology Stack

2. Deterministic Guardrails Meet Generative AI

Structured Policy Output

3. Scoped Customer Portal and Real Time Claims History

Slide Over Inspection Drawer

4. Human in the Loop: The Supervisor Review Desk

5. Testing and Verification Rigor

6. What I Learned

A practical walkthrough of real-world WordPress performance optimizations

The Initial Audit: What Went Wrong?

Step 1: Strip Gutenberg Admin Dependencies from Frontend Block Scripts

The Problem

The Solution

Step 2: Stop Using time() for Asset Versioning

The Problem

The Solution

Step 3: Eliminate CSS @import & Modernize Font Loading

The Problem

The Solution

Step 4: Defer jQuery and Strip jquery-migrate

1. Remove jquery-migrate on Frontend

2. Defer Core jQuery (WordPress 6.3+)

3. Safeguard Inline Event Handlers

Step 5: Dequeue Redundant Third-Party Plugin Assets

Step 6: Conditionally Load Heavy Plugin Assets (Forms & Anti-Spam)

The Problem

The Solution: Smart Conditional Dequeuing

The Results

Conclusion

Why I Added Tailscale to My VPS: Secure Access Without Relying on a Static IP

What is Tailscale?

Why Would You Use Tailscale?

1. Your ISP Uses Dynamic IP Addresses

2. Secure Access to Your VPS

3. You Don't Need to Know Your Current Public IP

4. Access Services That Shouldn't Be Public

5. You Can Connect More Than Just Your Laptop

Setting Up Tailscale on a Linux VPS

Step 1: Install Tailscale

Step 2: Authenticate the VPS

Step 3: Check the Tailscale Connection

Step 4: Install Tailscale on Your Mac

Step 5: Test SSH Through Tailscale

Making SSH Easier with ~/.ssh/config

Tailscale vs a Traditional VPN

Tailscale and Firewalls

Should You Close Port 22?

Tailscale SSH

A Practical VPS Security Architecture

What Tailscale Doesn't Solve

My Main Takeaway

Useful Resources

Mastering Zero-Downtime Deployments with Laravel Deployer

Triggering Deployments with GitHub Actions

How Zero-Downtime Deployment Works

The Problem: Deployer's Git Cache (.dep/repo)

The Issue I Faced

The Solution: The Clone Strategy

The Second Gotcha: Laravel Horizon and "Ghost" Code

Why did this happen?

Step 1: Prioritize the Hero Banner with `fetchpriority="high"` & `loading="eager"`

Step 2: Preload the LCP Hero Image in `<head>`

1. Leverage WordPress Responsive `srcset`

Step 2: Stop Using `time()` for Asset Versioning

Step 3: Eliminate CSS `@import` & Modernize Font Loading

Step 4: Defer jQuery and Strip `jquery-migrate`

1. Remove `jquery-migrate` on Frontend

The Problem: Deployer's Git Cache (`.dep/repo`)