DEV Community: Marcc Atayde

PWA Architecture Decisions That Actually Matter in Production: Manifests, Workbox Strategies, and Push Notifications Done Right

Marcc Atayde — Tue, 27 Oct 2026 01:00:13 +0000

Most PWA tutorials get you to a Lighthouse score of 100 and call it a day. That's fine for a demo, but production is different. Users install your app, kill it, come back three days later expecting fresh data, and get a stale cache from 2023. Push notifications don't arrive. The install prompt never fires. The offline page is a blank white screen.

This article is about the decisions that matter after you've read the intro docs — the ones you only encounter when real users are actually using the thing.

The Manifest Is More Than a Checklist

Every PWA guide tells you to create a manifest.json. Few tell you that the display mode choice has real UX consequences.

{
  "name": "My App",
  "short_name": "App",
  "start_url": "/dashboard?source=pwa",
  "display": "standalone",
  "background_color": "#1a1a2e",
  "theme_color": "#0f3460",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any maskable" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any maskable" }
  ],
  "screenshots": [
    { "src": "/screenshots/desktop.png", "sizes": "1280x800", "form_factor": "wide" },
    { "src": "/screenshots/mobile.png", "sizes": "390x844", "form_factor": "narrow" }
  ]
}

A few things worth noting here:

start_url with a query param lets you track installs in your analytics separately from regular web traffic. ?source=pwa is a simple convention that pays dividends.
purpose: "any maskable" on a single icon is laziness that costs you. Android's adaptive icons will crop aggressively. Use a proper maskable icon with safe-zone padding, and list it separately.
screenshots are not cosmetic fluff. Chrome on Android uses them to render a richer install bottom sheet. Include them.

Service Worker Caching: Pick the Right Strategy Per Resource Type

Workbox is the correct tool here. Writing raw service worker cache logic by hand is how you end up with race conditions that only manifest on slow 3G connections during a demo.

Install Workbox via the CLI or as a build plugin. Here's a realistic sw.js configuration for a Laravel-backed app:

import { registerRoute } from 'workbox-routing';
import { CacheFirst, NetworkFirst, StaleWhileRevalidate } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';
import { precacheAndRoute } from 'workbox-precaching';

// Precache compiled assets (Vite injects __WB_MANIFEST)
precacheAndRoute(self.__WB_MANIFEST);

// HTML pages: NetworkFirst so users always get fresh content if online
registerRoute(
  ({ request }) => request.destination === 'document',
  new NetworkFirst({
    cacheName: 'pages',
    plugins: [
      new ExpirationPlugin({ maxEntries: 30, maxAgeSeconds: 86400 })
    ]
  })
);

// API responses: StaleWhileRevalidate for dashboard data
registerRoute(
  ({ url }) => url.pathname.startsWith('/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new ExpirationPlugin({ maxEntries: 50, maxAgeSeconds: 300 })
    ]
  })
);

// Images: CacheFirst, long TTL
registerRoute(
  ({ request }) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'images',
    plugins: [
      new ExpirationPlugin({ maxEntries: 100, maxAgeSeconds: 2592000 })
    ]
  })
);

The mental model: documents need freshness, API data needs speed with background updates, static assets need longevity. Mix these up and you'll get either stale UIs or waterfall loading on every page visit.

Handling Cache Invalidation on Deploy

This is where most teams hit problems. You deploy a new version, the service worker updates, but users are still seeing the old UI because the old service worker is controlling existing tabs.

Force the update:

// In your main JS file
if ('serviceWorker' in navigator) {
  const registration = await navigator.serviceWorker.register('/sw.js');

  registration.addEventListener('updatefound', () => {
    const newWorker = registration.installing;
    newWorker.addEventListener('statechange', () => {
      if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
        // New version is ready — prompt the user
        showUpdateBanner();
      }
    });
  });
}

function showUpdateBanner() {
  const banner = document.createElement('div');
  banner.innerHTML = `
    <div style="position:fixed;bottom:0;left:0;right:0;background:#1e40af;color:white;padding:12px;display:flex;justify-content:space-between;align-items:center;z-index:9999">
      <span>A new version is available.</span>
      <button onclick="window.location.reload()">Refresh</button>
    </div>
  `;
  document.body.appendChild(banner);
}

Don't silently reload. That's jarring when a user is mid-form. The banner pattern respects their context.

Push Notifications: The Server-Side Is Where It Gets Real

The client-side subscription flow is documented everywhere. The server-side part — actually sending notifications reliably — is where implementations fall apart.

In Laravel, use the web-push library from minishlink:

composer require minishlink/web-push

use Minishlink\WebPush\WebPush;
use Minishlink\WebPush\Subscription;

class SendPushNotification
{
    public function handle(User $user, string $message): void
    {
        $auth = [
            'VAPID' => [
                'subject' => 'mailto:hello@example.com',
                'publicKey' => config('services.vapid.public_key'),
                'privateKey' => config('services.vapid.private_key'),
            ]
        ];

        $webPush = new WebPush($auth);

        foreach ($user->pushSubscriptions as $sub) {
            $webPush->queueNotification(
                Subscription::create([
                    'endpoint' => $sub->endpoint,
                    'keys' => [
                        'p256dh' => $sub->p256dh,
                        'auth' => $sub->auth,
                    ]
                ]),
                json_encode(['title' => 'Update', 'body' => $message])
            );
        }

        foreach ($webPush->flush() as $report) {
            if ($report->isSubscriptionExpired()) {
                // Clean up stale subscriptions from DB
                $user->pushSubscriptions()
                     ->where('endpoint', $report->getEndpoint())
                     ->delete();
            }
        }
    }
}

The isSubscriptionExpired() check is critical. Without it, your push subscription table fills with dead endpoints and your notification delivery rate quietly collapses over months.

The Install Prompt: Don't Fight the Browser

The A2HS (Add to Home Screen) prompt is gated behind browser heuristics: engagement time, return visits, HTTPS. You cannot force it. What you can do is capture the beforeinstallprompt event and defer it until a moment that makes sense in your UX flow.

let deferredPrompt;

window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();
  deferredPrompt = e;
  // Show your own install button/banner now
  document.getElementById('install-btn').style.display = 'block';
});

document.getElementById('install-btn').addEventListener('click', async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();
  const { outcome } = await deferredPrompt.userChoice;
  console.log(`Install outcome: ${outcome}`);
  deferredPrompt = null;
});

Trigger it after a meaningful user action — completing a form, reaching a dashboard — not the moment they land on the page.

Content Strategy Matters Too

Building a great PWA is only half the equation. The other half is making sure people actually find it. Teams at HanzWeb working on content and SEO strategy for web apps often find that PWAs get overlooked in organic search not because of technical issues, but because the discoverability work was never done — metadata, indexability of app shell routes, and structured data all need deliberate attention.

Conclusion

PWAs in production are less about the checklist and more about the edge cases: stale caches after deploy, push endpoints that silently expire, install prompts that fire at the wrong moment. The strategies here — Workbox routing by resource type, explicit update banners, server-side subscription hygiene — are the ones that move a PWA from a demo to something users actually trust.

Pick one pain point from your current PWA and fix it this week. The technology is solid. The execution is where the work is.

WCAG Compliance for Business Websites: A Developer's Practical Guide to Accessibility That Actually Ships

Marcc Atayde — Tue, 20 Oct 2026 01:00:06 +0000

Accessibility is one of those topics where most developers nod along in meetings and then quietly deprioritize it when sprint pressure mounts. I've been there. But after auditing dozens of business websites — and watching clients face real complaints and lost conversions because keyboard users couldn't complete a checkout flow — I've shifted my perspective completely. WCAG compliance isn't a checkbox for enterprises with legal teams; it's a quality standard that affects every user on every device, and the implementation details are genuinely interesting once you dig in.

This guide skips the motivational preamble. You know why accessibility matters. Let's talk about how to actually implement it in a modern web stack.

Understanding WCAG 2.1 AA: The Target You're Actually Shooting For

Most production websites should target WCAG 2.1 Level AA. Level A is the floor (serious blockers), Level AAA is often impractical for general-purpose sites, and AA is what most accessibility regulations and procurement requirements reference.

The four principles — Perceivable, Operable, Understandable, Robust (POUR) — sound abstract but translate directly into code decisions:

Perceivable: Can non-visual or non-auditory users consume your content?
Operable: Can every interactive element be reached and activated without a mouse?
Understandable: Do your forms, errors, and flows make sense to assistive tech users?
Robust: Does your markup parse correctly across browsers and AT (assistive technology)?

The failures I see most often aren't exotic edge cases. They're the same half-dozen issues across almost every site.

The High-Impact Failures (And How to Fix Them)

1. Keyboard Navigation Traps and Missing Focus Styles

The single most common issue. Developers remove the browser's default focus outline because it's "ugly," then never replace it.

/* Don't do this */
* {
  outline: none;
}

/* Do this instead — custom focus that matches your design system */
:focus-visible {
  outline: 3px solid #005FCC;
  outline-offset: 2px;
  border-radius: 2px;
}

Note :focus-visible rather than :focus — this applies the outline only for keyboard navigation, not mouse clicks, which is the behaviour designers usually want.

For modal dialogs, you need to trap focus inside the modal while it's open. Here's a minimal Alpine.js implementation:

<div
  x-data="{ open: false }"
  @keydown.escape.window="open = false"
>
  <button @click="open = true" aria-haspopup="dialog">Open Modal</button>

  <div
    x-show="open"
    role="dialog"
    aria-modal="true"
    aria-labelledby="modal-title"
    x-trap="open"
    class="modal"
  >
    <h2 id="modal-title">Confirm Action</h2>
    <p>Are you sure you want to proceed?</p>
    <button @click="open = false">Cancel</button>
    <button @click="open = false">Confirm</button>
  </div>
</div>

Alpine's x-trap directive (from @alpinejs/focus) handles focus trapping automatically. It's one of the most underused accessibility tools in the TALL stack.

2. Form Errors That Screen Readers Can't Announce

Inline validation is great visually. It's often invisible to screen reader users if you're only toggling a CSS class.

<!-- Broken pattern -->
<input type="email" id="email" class="border-red-500">
<span class="text-red-500 text-sm">Invalid email address</span>

<!-- Accessible pattern -->
<div>
  <label for="email">Email address</label>
  <input
    type="email"
    id="email"
    aria-describedby="email-error"
    aria-invalid="true"
  >
  <span
    id="email-error"
    role="alert"
    class="text-red-500 text-sm"
  >
    Please enter a valid email address.
  </span>
</div>

role="alert" causes screen readers to announce the content immediately when it appears in the DOM. aria-invalid signals the error state to AT. aria-describedby creates the programmatic association between input and error message.

In a Livewire component, this wires up cleanly:

// In your Livewire component
public function updated($field)
{
    $this->validateOnly($field);
}

<!-- In your Blade view -->
<input
  type="email"
  wire:model.lazy="email"
  id="email"
  aria-describedby="email-error"
  @error('email') aria-invalid="true" @enderror
>
@error('email')
  <span id="email-error" role="alert" class="text-red-500 text-sm">
    {{ $message }}
  </span>
@enderror

3. Images and Icon Buttons Without Accessible Names

This is brutally common in icon-based UIs.

<!-- What most devs ship -->
<button>
  <svg><!-- cart icon --></svg>
</button>

<!-- What screen reader users hear: "button" -->

<!-- Accessible version -->
<button aria-label="Add to cart">
  <svg aria-hidden="true" focusable="false"><!-- cart icon --></svg>
</button>

Mark decorative SVGs with aria-hidden="true" and focusable="false" (the latter prevents IE/Edge from tabbing into SVG elements). Provide the accessible name on the button itself.

4. Color Contrast at Scale

WCAG 2.1 AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt+, or 14pt bold). The issue isn't usually your primary palette — it's placeholder text, disabled states, and secondary labels.

In Tailwind, audit your config:

// tailwind.config.js — document contrast ratios for your custom colors
theme: {
  extend: {
    colors: {
      // Primary: #005FCC on white = 7.2:1 ✓
      primary: '#005FCC',
      // Danger text: use this on white backgrounds only
      // #CC0000 on white = 5.9:1 ✓
      danger: '#CC0000',
      // Avoid gray-400 on white for body text — 3.1:1 fails AA for small text
    }
  }
}

The tool I reach for most is Colour Contrast Analyser for ad-hoc checks and axe-core for automated CI integration.

Automating What You Can: axe-core in Your Test Suite

Automation catches roughly 30-40% of WCAG issues — the deterministic ones. Integrate it early:

// Using axe-core with Playwright
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage has no critical accessibility violations', async ({ page }) => {
  await page.goto('/');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

Run this against your staging environment in CI. It won't catch everything — keyboard trap testing, screen reader announcements, and cognitive load require manual review — but it will catch the low-hanging fruit before it reaches production.

The Manual Testing Workflow That Actually Works

Three tools cover most manual testing scenarios:

Keyboard only: Unplug your mouse. Tab through your entire user journey. Every interactive element must be reachable, operable, and have a visible focus state.
NVDA + Firefox (Windows) or VoiceOver + Safari (macOS/iOS): Read your critical flows — homepage, contact form, checkout. Listen for how headings, landmarks, and errors are announced.
axe DevTools browser extension: Run this on each page during development for instant feedback.

When I'm auditing a client site — the kind of work we handle at HanzWeb Dubai often involves inheriting codebases with years of accessibility debt — I run automated tools first to quantify the scope, then do a focused keyboard and screen reader walkthrough of the conversion-critical paths.

Semantic HTML: Still the Most Underrated Accessibility Tool

Before any ARIA, reach for the right HTML element. A <button> is keyboard-accessible, announces its role to AT, and responds to Space/Enter by default. A <div @click="..."> is none of those things until you add role, tabindex, and keyboard event handlers manually.

<!-- You're creating work for yourself -->
<div
  @click="toggle"
  @keydown.enter="toggle"
  @keydown.space.prevent="toggle"
  tabindex="0"
  role="button"
  :aria-expanded="open"
>
  Toggle
</div>

<!-- This is already accessible -->
<button @click="toggle" :aria-expanded="open">Toggle</button>

The rule of thumb: use ARIA to supplement semantics when native HTML can't express something, not to replace semantics you didn't bother writing.

Conclusion

WCAG compliance isn't a separate track that runs parallel to feature development — it's the result of small, consistent decisions at the code level. Correct semantic HTML, visible focus management, programmatic label associations, and sufficient color contrast together cover the vast majority of real-world accessibility issues without requiring specialist knowledge.

The tooling is mature, the patterns are well-documented, and the payoff extends beyond accessibility: accessible markup is cleaner, more maintainable, and more resilient across devices. Start with an axe-core integration in your CI pipeline, fix the focus styles you've been suppressing, and do one keyboard-only walkthrough of your most important user journey. You'll find more issues than you expect — and more of them will be straightforward to fix.

How AI Is Actually Changing Web Agency Workflows: The Honest Developer's Breakdown

Marcc Atayde — Tue, 13 Oct 2026 01:00:05 +0000

There's a version of this article that opens with "AI is revolutionizing everything" and then lists ChatGPT prompts for writing alt text. You've read that article. This isn't it.

What's actually happening in web agencies right now is messier, more interesting, and more consequential than the hype suggests. AI isn't replacing developers — but it is fundamentally reshaping where developer time goes, which skills compound in value, and how agencies structure their delivery pipelines. If you're shipping client work professionally, the changes are already affecting you whether you've intentionally adopted AI tooling or not.

Let me walk through where AI integration is producing real workflow gains, where it's creating new categories of technical debt, and what the code actually looks like when you wire this stuff into production.

Where AI Is Genuinely Useful in Agency Work

Content Intelligence Pipelines

The most durable AI integration I've seen in agency workflows isn't code generation — it's content processing. Specifically, taking unstructured client content and transforming it into structured, SEO-aware output at scale.

A typical pattern: a client dumps a folder of Word documents, product specs, and old blog posts. Previously, a developer manually parsed this into CMS-ready content. Now you can pipe it through an LLM with a structured extraction prompt and get JSON back that maps directly to your content model.

// Laravel job that processes raw client documents through OpenAI
class ProcessClientContentJob implements ShouldQueue
{
    public function __construct(
        private string $rawText,
        private int $pageId
    ) {}

    public function handle(OpenAI\Client $openai): void
    {
        $response = $openai->chat()->create([
            'model' => 'gpt-4o',
            'messages' => [
                [
                    'role' => 'system',
                    'content' => 'You are a content structuring assistant. Extract structured page content from raw text. Return valid JSON only.'
                ],
                [
                    'role' => 'user',
                    'content' => $this->buildExtractionPrompt($this->rawText)
                ]
            ],
            'response_format' => ['type' => 'json_object'],
            'temperature' => 0.2,
        ]);

        $structured = json_decode(
            $response->choices[0]->message->content,
            true
        );

        Page::find($this->pageId)->update([
            'title'        => $structured['title'] ?? null,
            'meta_desc'    => $structured['meta_description'] ?? null,
            'body_blocks'  => $structured['content_blocks'] ?? [],
            'focus_keyword'=> $structured['primary_keyword'] ?? null,
            'ai_processed' => true,
        ]);
    }

    private function buildExtractionPrompt(string $text): string
    {
        return <<<PROMPT
        Extract the following from this content and return as JSON:
        - title (SEO-optimised, max 60 chars)
        - meta_description (max 155 chars)
        - primary_keyword
        - content_blocks (array of {type, content} where type is heading|paragraph|list)

        Raw content:
        {$text}
        PROMPT;
    }
}

The response_format: json_object constraint is critical — without it you're parsing freeform text and that breaks in production constantly.

Automated Code Review as a CI Step

Another pattern gaining traction: running AI code review as part of your PR pipeline, not as a replacement for human review but as a first-pass filter that catches the obvious stuff before it reaches a senior developer's attention.

# .github/workflows/ai-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD -- '*.php' > diff.txt
          echo "diff_exists=$([ -s diff.txt ] && echo true || echo false)" >> $GITHUB_OUTPUT

      - name: AI Review
        if: steps.diff.outputs.diff_exists == 'true'
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          DIFF=$(cat diff.txt)
          REVIEW=$(curl -s https://api.openai.com/v1/chat/completions \
            -H "Authorization: Bearer $OPENAI_API_KEY" \
            -H "Content-Type: application/json" \
            -d "$(jq -n \
              --arg diff "$DIFF" \
              '{model:"gpt-4o-mini",messages:[{role:"system",content:"Review this PHP diff for security issues, N+1 queries, and missing validation. Be terse and specific. Flag only real problems."},{role:"user",content:$diff}],max_tokens:800}'\
            )" | jq -r '.choices[0].message.content')

          gh pr comment ${{ github.event.pull_request.number }} --body "**AI Review:**
          $REVIEW"

The gpt-4o-mini choice here is deliberate — it runs on every PR, so cost matters. Save the expensive model for the high-stakes operations.

The Problems Nobody Talks About

Context Window Debt

LLMs are stateless. Every request is a clean slate. This is obvious but the implications sneak up on you. When you're building AI-assisted features that span multiple user interactions — think a multi-step onboarding wizard with an AI advisor — you're responsible for reconstructing context on every call. That means serializing conversation history, truncating it intelligently when it exceeds limits, and deciding what's safe to drop.

class ConversationContextManager
{
    private const MAX_TOKENS = 6000; // conservative limit for gpt-4o-mini

    public function buildMessages(Conversation $conversation): array
    {
        $messages = [['role' => 'system', 'content' => $this->systemPrompt()]];
        $history  = $conversation->messages()
                        ->latest()
                        ->take(20) // grab recent 20
                        ->get()
                        ->reverse();

        $tokenCount = $this->estimateTokens($this->systemPrompt());

        foreach ($history as $message) {
            $msgTokens = $this->estimateTokens($message->content);

            if ($tokenCount + $msgTokens > self::MAX_TOKENS) {
                break; // drop oldest first
            }

            $messages[]  = ['role' => $message->role, 'content' => $message->content];
            $tokenCount += $msgTokens;
        }

        return $messages;
    }

    private function estimateTokens(string $text): int
    {
        // rough approximation: 1 token ≈ 4 chars
        return (int) ceil(mb_strlen($text) / 4);
    }
}

This is boring infrastructure work. It's also the difference between a chatbot that works and one that loses its mind after five messages.

Over-Reliance on Generation for Client-Facing Content

This one is more of an agency operations concern. AI-generated content, shipped without domain review, creates SEO problems downstream. Thin content, homogenized phrasing, and factual errors in technical niches are common failure modes. At https://hanzweb.ae, the approach that's held up best is using AI for structure and first-draft scaffolding, then routing output through a human review step before anything touches a production CMS. It's slower than fully automated pipelines, but the quality delta in search performance is measurable.

What Skills Actually Compound Here

If you're thinking about where to invest learning time, the highest-leverage areas in an AI-augmented agency workflow are:

Prompt engineering for structured output — JSON mode, function calling, and schema enforcement are more reliable than free-text parsing.
Retrieval-augmented generation (RAG) — Knowing how to chunk, embed, and retrieve client-specific knowledge makes generic LLM outputs actually relevant to a client's business context.
Observability for AI calls — Logging latency, token usage, and output quality metrics. When an AI feature degrades silently, you need the data to diagnose it.
Cost modeling — A feature that costs $0.002 per trigger is fine. One that costs $0.40 per trigger needs a budget conversation before it ships.

Conclusion

AI in agency workflows isn't a switch you flip — it's a surface you instrument carefully. The wins are real: content processing, code review augmentation, client-facing conversational interfaces. But the failure modes are equally real: context mismanagement, cost blowouts, and content quality regressions that don't show up until months later in analytics.

The developers getting the most out of these tools aren't the ones using AI to write all their code. They're the ones who understand where deterministic systems end and probabilistic ones begin — and who build the guardrails accordingly.

Ship AI features the same way you'd ship any infrastructure: with logging, with fallbacks, and with a healthy skepticism toward anything that looks too easy.

Image Optimization Beyond Compression: Lazy Loading, Modern Formats, and the Rendering Pipeline Tricks That Actually Help

Marcc Atayde — Mon, 05 Oct 2026 01:00:06 +0000

Most developers stop at squishing a JPEG and calling it done. Run it through ImageOptim, drop it into the public/ folder, ship it. Job done. Except it's not — because image optimization in 2025 is a multi-layered problem that spans format selection, delivery strategy, browser rendering behavior, and server-side generation pipelines. Get any one of those layers wrong and you're leaving real performance on the table, even if your file sizes look great.

This article goes past the basics. We're talking about the rendering pipeline decisions that affect Largest Contentful Paint (LCP), the loading and fetchpriority attributes that most developers use incorrectly, how to wire up responsive images properly in a Laravel/Blade context, and why AVIF isn't always better than WebP despite what the benchmarks suggest.

Understanding the Rendering Pipeline First

Before you touch a format or a build tool, understand what the browser actually does with an image. The browser parses HTML, discovers image resources, queues them in the network priority system, downloads them, decodes them in the main thread (or off-thread for some formats), and then composites them onto the page.

The decode step is where a lot of developers get surprised. A 200 KB WebP that decodes to a 4000×3000 bitmap is pushing 45 MB into memory. The browser has to handle that. For images that appear in the viewport immediately, you want decode to be fast. For images below the fold, you want it deferred entirely.

This is why the decoding attribute matters:

<!-- Hero image — decode synchronously, don't block compositing -->
<img
  src="/images/hero.webp"
  decoding="sync"
  fetchpriority="high"
  alt="Hero banner"
/>

<!-- Below-fold image — decode asynchronously, don't block rendering -->
<img
  src="/images/product-shot.webp"
  decoding="async"
  loading="lazy"
  alt="Product detail"
/>

Most tutorials tell you to slap loading="lazy" on everything. Don't. Any image in the initial viewport — especially your LCP candidate — should never be lazy loaded. You're telling the browser to deprioritize the most important visual on the page.

Format Selection: AVIF, WebP, and the Reality of Decode Cost

AVIF offers better compression than WebP at equivalent quality. That's real. But AVIF has a higher CPU decode cost, which matters on low-end mobile devices. If your audience skews toward budget Android phones — which is increasingly common in markets across the Middle East, South Asia, and Southeast Asia — AVIF can actually hurt perceived performance even when the file is smaller, because the decode blocks rendering longer.

The pragmatic approach: use AVIF for static, below-fold images and large hero backgrounds where the browser has time to decode off the critical path. Stick with WebP for product images, thumbnails, and anything in the viewport on page load.

In a Laravel application, you can automate this with Spatie's Laravel Image package alongside a queue-driven conversion pipeline:

// app/Jobs/ProcessProductImage.php

use Spatie\Image\Image;
use Spatie\Image\Enums\ImageDriver;

class ProcessProductImage implements ShouldQueue
{
    public function __construct(
        private string $sourcePath,
        private string $publicDir
    ) {}

    public function handle(): void
    {
        $baseName = pathinfo($this->sourcePath, PATHINFO_FILENAME);

        // Generate WebP for viewport-critical delivery
        Image::useImageDriver(ImageDriver::Gd)
            ->loadFile($this->sourcePath)
            ->quality(82)
            ->save("{$this->publicDir}/{$baseName}.webp");

        // Generate AVIF for below-fold / preload link usage
        Image::useImageDriver(ImageDriver::Imagick)
            ->loadFile($this->sourcePath)
            ->quality(70)
            ->save("{$this->publicDir}/{$baseName}.avif");

        // Responsive sizes
        foreach ([400, 800, 1200] as $width) {
            Image::useImageDriver(ImageDriver::Gd)
                ->loadFile($this->sourcePath)
                ->width($width)
                ->quality(80)
                ->save("{$this->publicDir}/{$baseName}-{$width}.webp");
        }
    }
}

Dispatch this on the saved observer of your model and you've got a fully automated responsive image pipeline that runs off the request cycle.

Responsive Images: `srcset` and `sizes` Done Correctly

The srcset attribute is widely used and widely misunderstood. The w descriptor tells the browser the intrinsic width of the image source. The sizes attribute tells the browser what rendered size the image will occupy at various viewport widths. The browser combines these two pieces of information with the device pixel ratio to pick the optimal source.

If your sizes attribute is wrong, the browser makes bad choices. Here's a real-world example for a three-column product grid that goes full-width on mobile:

<picture>
  <source
    type="image/avif"
    srcset="
      /images/product-400.avif  400w,
      /images/product-800.avif  800w,
      /images/product-1200.avif 1200w
    "
    sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
  />
  <source
    type="image/webp"
    srcset="
      /images/product-400.webp  400w,
      /images/product-800.webp  800w,
      /images/product-1200.webp 1200w
    "
    sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
  />
  <img
    src="/images/product-800.webp"
    alt="Product name"
    loading="lazy"
    decoding="async"
    width="800"
    height="600"
  />
</picture>

Always include explicit width and height attributes on the <img> element. This is how the browser reserves layout space before the image loads, eliminating Cumulative Layout Shift (CLS) — a Core Web Vitals metric that tanks rankings and feels broken to users.

Building a Blade Component for Consistency

Repeating the <picture> pattern by hand across a Laravel application is error-prone. Wrap it in a Blade component:

// app/View/Components/ResponsiveImage.php

class ResponsiveImage extends Component
{
    public function __construct(
        public string $src,
        public string $alt,
        public int $width,
        public int $height,
        public string $sizes = '100vw',
        public bool $priority = false,
    ) {}

    public function render()
    {
        return view('components.responsive-image');
    }

    public function baseName(): string
    {
        return pathinfo($this->src, PATHINFO_FILENAME);
    }

    public function dir(): string
    {
        return pathinfo($this->src, PATHINFO_DIRNAME);
    }
}

{{-- resources/views/components/responsive-image.blade.php --}}
<picture>
  <source
    type="image/avif"
    srcset="
      {{ $dir() }}/{{ $baseName() }}-400.avif 400w,
      {{ $dir() }}/{{ $baseName() }}-800.avif 800w,
      {{ $dir() }}/{{ $baseName() }}-1200.avif 1200w
    "
    sizes="{{ $sizes }}"
  />
  <source
    type="image/webp"
    srcset="
      {{ $dir() }}/{{ $baseName() }}-400.webp 400w,
      {{ $dir() }}/{{ $baseName() }}-800.webp 800w,
      {{ $dir() }}/{{ $baseName() }}-1200.webp 1200w
    "
    sizes="{{ $sizes }}"
  />
  <img
    src="{{ $dir() }}/{{ $baseName() }}-800.webp"
    alt="{{ $alt }}"
    width="{{ $width }}"
    height="{{ $height }}"
    @if($priority)
      fetchpriority="high"
      decoding="sync"
    @else
      loading="lazy"
      decoding="async"
    @endif
  />
</picture>

Usage becomes clean and intention-revealing:

{{-- Hero image — prioritized --}}
<x-responsive-image
  src="/images/hero"
  alt="Company hero banner"
  :width="1200"
  :height="630"
  sizes="100vw"
  :priority="true"
/>

{{-- Product card — lazy --}}
<x-responsive-image
  src="/images/product-{{ $product->id }}"
  alt="{{ $product->name }}"
  :width="800"
  :height="600"
  sizes="(max-width: 640px) 100vw, 33vw"
/>

CDN Delivery and Cache-Control Headers

None of this matters if you're serving images from the same server handling PHP requests. Static assets should be on a CDN. Laravel's config/filesystems.php makes it straightforward to push to S3-compatible storage with CloudFront or Cloudflare in front:

// config/filesystems.php
'images' => [
    'driver' => 's3',
    'key' => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'region' => env('AWS_DEFAULT_REGION'),
    'bucket' => env('AWS_BUCKET'),
    'url' => env('CDN_URL'),
    'visibility' => 'public',
    'options' => [
        'CacheControl' => 'public, max-age=31536000, immutable',
    ],
],

The immutable directive tells browsers and CDN edge nodes that this URL's content will never change. Since your processed images are content-addressed (or version-stamped through your deployment pipeline), this is safe — and it eliminates revalidation requests entirely.

This is the kind of compounding infrastructure work that teams at HanzWeb Agency build into projects from the start rather than retrofitting later, because it's significantly harder to restructure a delivery pipeline after an application is in production.

Conclusion

Image optimization isn't a one-time task — it's a pipeline decision made at architecture time. The format you choose, the attributes you set, the responsive breakpoints you define, and the CDN configuration you deploy all interact with each other and with the browser's rendering engine in ways that file size alone can't capture.

The takeaway: audit your LCP image first. Make sure it has fetchpriority="high" and no loading="lazy". Add explicit dimensions to every image. Build a format conversion job that generates WebP and AVIF variants at multiple widths. Then set aggressive cache headers and put a CDN in front of everything. That sequence, applied consistently, will move your Core Web Vitals scores in ways that running files through a compressor never will.

Structured Data in 2025: Schema Markup That Actually Wins Rich Results (With Real Laravel Examples)

Marcc Atayde — Tue, 29 Sep 2026 01:00:05 +0000

Structured data is one of those topics that developers treat as an afterthought — slap some JSON-LD on the page, validate it in Rich Results Test, and call it done. That approach worked fine in 2019. In 2025, Google's crawlers are more selective, AI-driven search summaries are pulling from schema directly, and the gap between "valid" markup and "ranking" markup has never been wider.

This article is about closing that gap. We'll look at which schema types actually drive measurable SERP features, common implementation mistakes that silently kill eligibility, and how to generate and validate structured data programmatically in a Laravel application.

Why Most Schema Implementations Underperform

The common failure mode isn't invalid JSON-LD — validators catch that. The real problem is incomplete or contextually weak schema. Google's documentation is explicit: required properties get you eligibility; recommended properties get you prominence. Most developers stop at required.

Take Article schema. The minimum spec asks for headline, image, and datePublished. But if you want your article appearing in Top Stories or Google Discover, you also need author with a valid Person entity, publisher with a logo that meets dimension specs, and dateModified to signal freshness. Omitting those doesn't break validation — it just quietly removes you from contention.

Another silent killer: schema that doesn't match the visible page content. Google cross-references your markup against what users actually see. A Product schema with a price that doesn't appear in the rendered HTML — or a Review aggregate that differs from the on-page star display — will get ignored or, worse, flagged as manipulative.

The Schema Types Worth Prioritising in 2025

`Article` / `BlogPosting`

Essential for content-heavy sites. Use BlogPosting (a subtype of Article) for blog content; it signals intent to crawlers. Key recommended properties you shouldn't skip:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Your Post Title Here",
  "image": [
    "https://example.com/photos/1x1/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/16x9/photo.jpg"
  ],
  "datePublished": "2025-01-15T08:00:00+04:00",
  "dateModified": "2025-06-10T09:20:00+04:00",
  "author": {
    "@type": "Person",
    "name": "Your Name",
    "url": "https://example.com/authors/your-name"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Your Brand",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png",
      "width": 600,
      "height": 60
    }
  },
  "description": "A concise summary that matches your meta description."
}

Note the three image aspect ratios. Google recommends providing all three (1:1, 4:3, 16:9) so the crawler can select the most appropriate one per context.

`FAQPage`

FAQ schema still earns expandable rich results in desktop SERPs and is increasingly used by AI Overviews to surface direct answers. The catch: questions and answers must be verbatim visible on the page. Don't generate FAQ schema from a database if the content isn't rendered in HTML.

`Product` with `Offer` and `AggregateRating`

For e-commerce, completeness here is commercially significant. An Offer without availability or priceCurrency gets deprioritised for Shopping graph features. AggregateRating requires both ratingValue and reviewCount — and both must reflect actual visible content.

Generating Schema Programmatically in Laravel

Hard-coding JSON-LD in Blade templates is fine for static pages but doesn't scale. Here's a clean approach using a dedicated service class.

<?php

namespace App\Services\Seo;

class SchemaBuilder
{
    public function blogPosting(array $data): string
    {
        $schema = [
            '@context' => 'https://schema.org',
            '@type'    => 'BlogPosting',
            'headline' => $data['title'],
            'image'    => $data['images'] ?? [],
            'datePublished' => $data['published_at']->toIso8601String(),
            'dateModified'  => $data['updated_at']->toIso8601String(),
            'author' => [
                '@type' => 'Person',
                'name'  => $data['author_name'],
                'url'   => $data['author_url'],
            ],
            'publisher' => [
                '@type' => 'Organization',
                'name'  => config('app.name'),
                'logo'  => [
                    '@type'  => 'ImageObject',
                    'url'    => asset('images/logo-schema.png'),
                    'width'  => 600,
                    'height' => 60,
                ],
            ],
            'description' => $data['excerpt'],
        ];

        return json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT);
    }

    public function faqPage(array $questions): string
    {
        $schema = [
            '@context'   => 'https://schema.org',
            '@type'      => 'FAQPage',
            'mainEntity' => array_map(fn($q) => [
                '@type'          => 'Question',
                'name'           => $q['question'],
                'acceptedAnswer' => [
                    '@type' => 'Answer',
                    'text'  => $q['answer'],
                ],
            ], $questions),
        ];

        return json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT);
    }
}

In your Blade layout:

@stack('schema')

And in specific page views:

@push('schema')
<script type="application/ld+json">
{!! $schemaBuilder->blogPosting($post->toSchemaArray()) !!}
</script>
@endpush

This keeps schema generation testable, reusable, and away from your view layer logic. You can write unit tests against SchemaBuilder methods and assert that required keys are always present before anything hits production.

Testing Beyond the Rich Results Tool

The Rich Results Test tells you if your schema is valid. It doesn't tell you if you're eligible. Use it, but don't stop there.

Search Console's Rich Results report is the ground truth. It shows actual impressions and clicks from rich results, and — critically — it surfaces warnings that the Rich Results Test misses, like schema detected on pages with thin content or low crawl priority.

Schema Markup Validator (validator.schema.org) runs a stricter conformance check than Google's tool and often catches type mismatches.

Screaming Frog's structured data extraction lets you audit schema across your entire site at once — invaluable when you have hundreds of product or blog pages and need to verify consistency programmatically.

For teams building content-heavy applications, automated schema auditing should be part of your CI/CD pipeline, not a quarterly manual task. Parsing rendered HTML with something like symfony/dom-crawler and asserting schema presence on key page types is straightforward to implement.

The Entity Relationship Angle

One underappreciated dimension: schema isn't just about individual pages. Google builds an entity graph, and your markup contributes to it. Consistent use of sameAs properties — pointing author entities to verified profiles like LinkedIn or Wikipedia, and organisation entities to Wikidata or Crunchbase — strengthens entity disambiguation and can improve how your content is attributed in AI-generated summaries.

This is an area that the team at HanzWeb writes about in depth — particularly how entity signals interact with local SEO for businesses operating in competitive markets like the UAE.

Conclusion

Structured data done right is an investment in discoverability infrastructure — not just a checkbox. The implementation effort is low; the discipline to keep it accurate, complete, and content-matched is where most projects fall short. Start with a schema service class, write tests for required property completeness, monitor Search Console's rich results report weekly, and treat schema updates as a first-class concern whenever content models change. The SERP real estate you gain is genuinely free — but only if the crawler trusts what you've marked up.

Integrating AI APIs into Web Applications: OpenAI, Claude, and DeepSeek Compared in Production

Marcc Atayde — Tue, 22 Sep 2026 01:00:06 +0000

You've shipped the demo. The AI feature works beautifully on localhost, generates coherent responses, and impresses everyone in the standup. Then you hit production and reality arrives: inconsistent response formats, ballooning token costs, timeouts under load, and users complaining the thing "just stopped working." Sound familiar?

Integrating AI APIs into real applications isn't hard to start — it's hard to do well. This article cuts through the hello-world tutorials and focuses on what actually matters when you're wiring OpenAI, Claude, or DeepSeek into a production Laravel or Node application: provider differences, structured output, error handling, cost control, and building a provider-agnostic layer so you're not locked in.

The Provider Landscape in 2025

Each of the three major providers has a distinct personality that affects how you architect around them.

OpenAI (GPT-4o, o3-mini) remains the default choice for most teams. The ecosystem is mature, the function-calling / tool-use API is solid, and the structured outputs feature (JSON mode with schema enforcement) is production-grade. The downside is cost and occasional rate-limit surprises at scale.

Anthropic Claude (claude-3-5-sonnet, claude-3-haiku) consistently produces better instruction-following on long, complex prompts. It handles large context windows gracefully and tends to be more "literal" — which is a feature, not a bug, when you need predictable output. The API surface is slightly simpler than OpenAI's.

DeepSeek (deepseek-chat, deepseek-reasoner) is the disruptor. It's OpenAI-API-compatible (same SDK, different base URL), dramatically cheaper, and performs competitively on coding and reasoning tasks. For internal tools or high-volume classification tasks where you'd burn through OpenAI credits, DeepSeek is worth serious consideration.

Building a Provider-Agnostic Abstraction

The single best architectural decision you can make is to never call an AI SDK directly from your business logic. Wrap everything behind a contract.

// app/Contracts/AiProvider.php
namespace App\Contracts;

interface AiProvider
{
    public function complete(string $prompt, array $options = []): string;
    public function completeStructured(string $prompt, array $schema, array $options = []): array;
}

Now implement it for each provider. Here's the OpenAI implementation using the official PHP SDK:

// app/Ai/OpenAiProvider.php
namespace App\Ai;

use App\Contracts\AiProvider;
use OpenAI\Client;

class OpenAiProvider implements AiProvider
{
    public function __construct(private Client $client) {}

    public function complete(string $prompt, array $options = []): string
    {
        $response = $this->client->chat()->create([
            'model'    => $options['model'] ?? 'gpt-4o-mini',
            'messages' => [['role' => 'user', 'content' => $prompt]],
            'max_tokens' => $options['max_tokens'] ?? 1024,
        ]);

        return $response->choices[0]->message->content;
    }

    public function completeStructured(string $prompt, array $schema, array $options = []): array
    {
        $response = $this->client->chat()->create([
            'model'    => $options['model'] ?? 'gpt-4o-mini',
            'messages' => [['role' => 'user', 'content' => $prompt]],
            'response_format' => [
                'type'        => 'json_schema',
                'json_schema' => [
                    'name'   => $schema['name'] ?? 'response',
                    'schema' => $schema['schema'],
                    'strict' => true,
                ],
            ],
        ]);

        return json_decode($response->choices[0]->message->content, true);
    }
}

For DeepSeek, because it mirrors the OpenAI spec, the implementation is almost identical — just swap the base URL:

// app/Ai/DeepSeekProvider.php
namespace App\Ai;

use App\Contracts\AiProvider;
use OpenAI\Client;

class DeepSeekProvider implements AiProvider
{
    // DeepSeek uses the same OpenAI client with a custom base URI
    // configured in your service provider:
    // OpenAI::factory()->withBaseUri('https://api.deepseek.com/v1')->make()

    public function __construct(private Client $client) {}

    public function complete(string $prompt, array $options = []): string
    {
        $response = $this->client->chat()->create([
            'model'    => $options['model'] ?? 'deepseek-chat',
            'messages' => [['role' => 'user', 'content' => $prompt]],
        ]);

        return $response->choices[0]->message->content;
    }

    public function completeStructured(string $prompt, array $schema, array $options = []): array
    {
        // DeepSeek supports json_object mode; parse and validate manually
        $response = $this->client->chat()->create([
            'model'           => $options['model'] ?? 'deepseek-chat',
            'messages'        => [
                ['role' => 'system', 'content' => 'Respond only with valid JSON matching this schema: ' . json_encode($schema['schema'])],
                ['role' => 'user', 'content' => $prompt],
            ],
            'response_format' => ['type' => 'json_object'],
        ]);

        return json_decode($response->choices[0]->message->content, true);
    }
}

Bind the correct provider in a service provider based on config:

$this->app->bind(AiProvider::class, function () {
    return match(config('ai.provider')) {
        'deepseek' => new DeepSeekProvider(/* DeepSeek client */),
        'claude'   => new ClaudeProvider(/* Anthropic SDK */),
        default    => new OpenAiProvider(app(Client::class)),
    };
});

Now your business logic calls AiProvider::complete() without caring which model is behind it. Switching providers for cost or quality reasons becomes a config change.

Structured Output: The Feature That Changes Everything

Free-form text responses are fine for chatbots. For any feature that feeds AI output into application logic — classification, extraction, scoring — you need structured, validated output.

OpenAI's strict JSON schema mode actually guarantees the response matches your schema. Claude achieves this reliably via careful system prompting plus a JSON extraction step. DeepSeek's json_object mode produces valid JSON but doesn't enforce a schema, so validate on your side:

use Illuminate\Support\Facades\Validator;

$raw = $provider->completeStructured($prompt, $schema);

$validator = Validator::make($raw, [
    'sentiment'  => 'required|in:positive,negative,neutral',
    'confidence' => 'required|numeric|min:0|max:1',
    'topics'     => 'required|array|min:1',
]);

if ($validator->fails()) {
    // Retry once or fall back to a default
    throw new \RuntimeException('AI returned invalid structure: ' . $validator->errors()->first());
}

Always validate. Never trust that the schema will be respected 100% of the time, regardless of provider.

Error Handling and Resilience

AI APIs fail. Rate limits, timeouts, upstream errors — they all happen. Your integration needs to handle them gracefully.

use Illuminate\Support\Facades\Log;

function withAiRetry(callable $fn, int $maxAttempts = 3): mixed
{
    $attempt = 0;
    while ($attempt < $maxAttempts) {
        try {
            return $fn();
        } catch (\OpenAI\Exceptions\TransporterException $e) {
            $attempt++;
            if ($attempt === $maxAttempts) throw $e;
            sleep((int) pow(2, $attempt)); // exponential backoff: 2s, 4s
        } catch (\OpenAI\Exceptions\ErrorException $e) {
            // Rate limit or quota — back off longer
            if (str_contains($e->getMessage(), 'rate_limit')) {
                sleep(10);
                $attempt++;
            } else {
                throw $e; // Non-retriable error
            }
        }
    }
}

Push non-interactive AI calls through Laravel queues. User clicks "generate report", a job gets dispatched, the UI polls for completion. Users tolerate a 10-second wait; they don't tolerate a spinning button that eventually shows an error.

Cost Control in Practice

Token costs sneak up on you. Three things that actually help:

Cache aggressively. Identical prompts should hit Redis, not the API. Hash the prompt + model + parameters as the cache key. Even a 1-hour TTL eliminates enormous duplicate spend for content generation features.

Compress your system prompts. That 800-token system prompt you wrote in prose? Rewrite it as terse instructions. Every API call pays for it.

Route by task complexity. Use deepseek-chat or gpt-4o-mini for classification and extraction. Reserve claude-3-5-sonnet or gpt-4o for generation tasks where quality visibly matters. The abstraction layer you built earlier makes this routing trivial.

public function routeProvider(string $task): AiProvider
{
    return match($task) {
        'classify', 'extract', 'score' => app(DeepSeekProvider::class),
        'generate', 'summarize'        => app(ClaudeProvider::class),
        default                        => app(OpenAiProvider::class),
    };
}

Claude's Edge: Long Context and Instruction Fidelity

If you're feeding large documents — contracts, transcripts, codebases — Claude handles context windows more gracefully than the alternatives in practice. It also follows multi-step, conditional instructions more reliably. When a client project at my agency involved processing lengthy legal documents, Claude's behavior was notably more consistent than GPT-4o on the same prompts. Teams building document-heavy features in regions like the Gulf — where firms investing in Dubai web design services increasingly expect AI-native document workflows — will find Claude worth the slightly higher cost.

Conclusion

The right AI integration isn't about picking the "best" provider — it's about building an abstraction that lets you swap, route, and evolve your choices as the landscape shifts. Enforce structured output and validate it. Handle failures with retries and queues. Route tasks by cost and quality requirements rather than defaulting everything to the most expensive model.

The providers are converging in capability. Your architecture is the differentiator.

Progressive Web Apps in 2025: A Production-Focused Guide to Service Workers, Caching, and the Install Experience

Marcc Atayde — Tue, 15 Sep 2026 01:00:05 +0000

There's a version of this article that starts with "PWAs are the future." This isn't that article. Instead, let's talk about what PWAs actually buy you in production — where the real complexity lives, what the spec glosses over, and how to ship something that behaves reliably across Chrome, Safari, and Firefox without losing your mind.

If you've built SPAs with Laravel backends or worked in the TALL stack, you already have most of the mental models. Service workers are just cache interceptors with a lifecycle. The manifest is just metadata. The hard part is the orchestration — and the gaps in the spec that nobody warns you about.

What a PWA Actually Is (Past the Marketing)

Strip away the buzzwords and a PWA is three things working together:

A web app manifest — JSON metadata that lets the browser offer an install prompt and controls how the app looks when installed.
A service worker — a JS script running in a separate thread that intercepts network requests and manages caches.
HTTPS — mandatory. No negotiation.

Nothing in that list requires React, a SPA, or even JavaScript-heavy architecture. A server-rendered Laravel app with Blade templates can be a perfectly valid PWA. The confusion happens when people conflate PWA capabilities with SPA patterns. They're orthogonal concerns.

The Manifest: More Than `name` and `icons`

Most tutorials show you a bare-bones manifest and move on. Here's a more complete version reflecting what you actually want in production:

{
  "name": "Field Service Tracker",
  "short_name": "FSTracker",
  "description": "Real-time job dispatch and field technician tracking.",
  "start_url": "/dashboard?source=pwa",
  "display": "standalone",
  "background_color": "#1e293b",
  "theme_color": "#3b82f6",
  "orientation": "portrait-primary",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ],
  "screenshots": [
    { "src": "/screenshots/desktop.png", "sizes": "1280x720", "type": "image/png", "form_factor": "wide" },
    { "src": "/screenshots/mobile.png", "sizes": "390x844", "type": "image/png", "form_factor": "narrow" }
  ],
  "categories": ["business", "productivity"],
  "shortcuts": [
    {
      "name": "New Job",
      "url": "/jobs/create?source=shortcut",
      "icons": [{ "src": "/icons/shortcut-new-job.png", "sizes": "96x96" }]
    }
  ]
}

A few things worth noting:

start_url with a query param lets you segment PWA installs in your analytics without any extra instrumentation. Filter on source=pwa and you get a clean cohort.
Maskable icons are non-optional if you want the app to look correct on Android. Without a maskable variant, the OS applies its own shape and you get white-boxed icons.
Screenshots unlock the richer install dialog in Chrome on desktop and Android — the one that shows a preview instead of just a bare install button.
Shortcuts appear on long-press of the home screen icon. For task-oriented apps, this is a meaningful UX improvement with zero runtime cost.

Service Workers: The Lifecycle Is the Hard Part

The spec describes install, activate, and fetch as the three primary events. What it undersells is the waiting state — the source of most PWA update bugs in production.

When a new service worker is detected, it installs and waits. It won't activate until all tabs running the old SW are closed. This means users can run a stale version for days on a tab they never close. The typical fix is skipWaiting, but you need to coordinate with the client:

// sw.js
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('app-shell-v3').then((cache) => {
      return cache.addAll([
        '/',
        '/dashboard',
        '/offline.html',
        '/css/app.css',
        '/js/app.js',
      ]);
    })
  );
});

self.addEventListener('activate', (event) => {
  const allowedCaches = ['app-shell-v3', 'api-runtime-v1'];
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys
          .filter((key) => !allowedCaches.includes(key))
          .map((key) => caches.delete(key))
      )
    ).then(() => self.clients.claim())
  );
});

self.addEventListener('message', (event) => {
  if (event.data?.type === 'SKIP_WAITING') {
    self.skipWaiting();
  }
});

Then on the client side, prompt the user when a new version is ready:

// In your main app JS
let newWorker;

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then((reg) => {
    reg.addEventListener('updatefound', () => {
      newWorker = reg.installing;
      newWorker.addEventListener('statechange', () => {
        if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
          // New version available — show a non-blocking toast
          showUpdateBanner(() => {
            newWorker.postMessage({ type: 'SKIP_WAITING' });
            window.location.reload();
          });
        }
      });
    });
  });
}

This pattern — detect, inform, let the user choose to reload — is far better UX than silently forcing a reload or leaving users stranded on stale builds.

Caching Strategies: Match the Strategy to the Resource

Don't use one strategy for everything. Here's how to think about it:

Resource Type	Strategy	Rationale
App shell (HTML, CSS, JS)	Cache-first with versioned cache names	Changes are deploy-time events, not runtime
API responses (read-heavy)	Stale-while-revalidate	Show cached data instantly, refresh in background
API responses (write operations)	Network-first	Stale data on mutations is dangerous
Images / fonts	Cache-first with long TTL	These rarely change
Offline fallback page	Cache-only (pre-cached on install)	Must be available when network fails

For the network-first with offline fallback pattern on API calls:

self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url);

  if (url.pathname.startsWith('/api/')) {
    event.respondWith(
      fetch(event.request)
        .then((response) => {
          // Clone before consuming
          const clone = response.clone();
          caches.open('api-runtime-v1').then((cache) => {
            cache.put(event.request, clone);
          });
          return response;
        })
        .catch(() =>
          caches.match(event.request).then(
            (cached) => cached || caches.match('/offline.html')
          )
        )
    );
    return;
  }

  // Cache-first for everything else
  event.respondWith(
    caches.match(event.request).then(
      (cached) => cached || fetch(event.request)
    )
  );
});

Background Sync for Offline Write Operations

The scenario: a field technician submits a job update with no signal. The naive approach loses the data. Background Sync queues the request and replays it when connectivity returns:

// On form submission
async function submitJobUpdate(data) {
  try {
    await fetch('/api/jobs', { method: 'POST', body: JSON.stringify(data) });
  } catch {
    // Store in IndexedDB
    await saveToQueue('job-updates', data);
    const reg = await navigator.serviceWorker.ready;
    await reg.sync.register('sync-job-updates');
  }
}

// In sw.js
self.addEventListener('sync', (event) => {
  if (event.tag === 'sync-job-updates') {
    event.waitUntil(flushJobUpdateQueue());
  }
});

Browser support for Background Sync is still Chrome/Edge-only as of 2025. Safari supports the Periodic Background Sync spec differently. Plan your offline strategy accordingly and use it as progressive enhancement, not a hard dependency.

Safari: The Reality Check

Safari's PWA support has improved meaningfully since 2023, but gaps remain. Push notifications on iOS require the user to install the PWA first, and only work from the home screen — not the browser. The install prompt API (BeforeInstallPromptEvent) doesn't exist in Safari; you have to build your own "Add to Home Screen" instruction UI and detect the platform yourself:

const isIos = /iphone|ipad|ipod/i.test(navigator.userAgent);
const isInStandaloneMode = window.matchMedia('(display-mode: standalone)').matches;

if (isIos && !isInStandaloneMode) {
  showIosInstallInstructions(); // Your custom UI
}

This is the kind of implementation detail that separates a production PWA from a tutorial demo. Teams at hanzweb.ae working on cross-platform business apps spend a meaningful chunk of QA time on Safari edge cases alone — the spec says one thing, the browser does another, and the user experience depends on you catching the gap.

Testing Your Service Worker

Chrome DevTools → Application → Service Workers is your primary tool, but don't skip these:

Lighthouse PWA audit — catches manifest issues and SW registration failures
Simulate offline in DevTools → Network → Offline, then navigate around
Test the update flow explicitly — modify your SW, reload, confirm the waiting state appears, then trigger skip-waiting
Test on a real device — Android Chrome and iOS Safari behave differently than desktop DevTools emulation

Conclusion

PWAs earn their complexity when your users have intermittent connectivity, when you need app-store-like discoverability without the friction of a native submission process, or when a native app isn't justified by budget but installed-app UX is genuinely required. They're not a silver bullet — a poorly implemented service worker will make your app slower and harder to debug than a plain website.

The takeaway: invest time in the caching strategy and the update lifecycle. Get those two things right and everything else is configuration. Get them wrong and you're shipping a cache poisoning bug to every user who ever visited your site.

Build the manifest thoughtfully. Handle the waiting state. Match your cache strategy to the resource type. Test on real devices. That's the whole game.

Migrating Legacy Websites to Modern Laravel: A Practical, Battle-Tested Guide

Marcc Atayde — Tue, 08 Sep 2026 01:00:08 +0000

There's a particular kind of dread that hits when you open a legacy codebase for the first time. Global variables flying around, mysql_query() calls buried three functions deep, a functions.php that's 4,000 lines long, and zero tests. Yet the business depends on it. Customers are using it. And now you've been asked to modernise it.

Migrating a legacy site to Laravel isn't just a technical exercise — it's a translation job between two very different philosophies. This guide walks through a structured approach that lets you migrate incrementally, keep the existing system running, and avoid the classic trap of the never-ending rewrite.

Why Incremental Migration Beats the Big Bang Rewrite

The temptation is to freeze feature work, rewrite everything from scratch, and launch a brand-new system six months later. This almost never works. Requirements drift, the old system acquires patches the new one doesn't have, and teams lose momentum.

A strangler fig pattern — wrapping the new system around the old one, routing traffic piece by piece — is almost always the right call. Laravel is well-suited to this because its routing, middleware, and service container can coexist with legacy code running on the same server.

Step 1: Audit Before You Touch Anything

Before writing a single line of Laravel, map the existing system:

Entry points: Which files does the webserver actually serve? Often legacy PHP apps have dozens of index.php files in subdirectories.
Database schema: Export a full ERD. Tools like SchemaSpy or even just SHOW CREATE TABLE exports are your friends.
External dependencies: Payment gateways, SMTP config, third-party APIs — document every outbound connection.
Session and auth model: Is auth session-based? Cookie-based? Custom token table?

Document this ruthlessly. You'll refer back to it constantly.

Step 2: Stand Up Laravel Alongside the Legacy App

Install a fresh Laravel application in a sibling directory. Configure your web server (nginx is easiest here) to proxy requests to either the legacy app or Laravel based on URL prefix.

server {
    listen 80;
    server_name example.com;

    # New Laravel routes
    location /account {
        proxy_pass http://127.0.0.1:8001;
    }

    location /api {
        proxy_pass http://127.0.0.1:8001;
    }

    # Everything else goes to the legacy app
    location / {
        root /var/www/legacy;
        index index.php;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Laravel runs on PHP 8.x on port 8001 via a separate FPM pool. The legacy app continues to handle everything else untouched.

Step 3: Shared Session State

The single hardest problem in this migration pattern is auth. Users logged into the legacy system shouldn't be asked to log in again when Laravel handles a request.

The pragmatic solution: share the session backend. If the legacy app uses PHP file sessions, Laravel can read those too — but it's messy. Better to migrate the legacy app to use a database or Redis session store first, then configure Laravel to use the same store.

// config/session.php in Laravel
'driver' => 'redis',
'connection' => 'default',
'cookie' => 'legacy_session', // must match the legacy app's cookie name

On the legacy side, use a custom session handler that writes to Redis with the same key format. PhpRedis or Predis works fine here. This buys you true single-sign-on between the old and new systems without a full auth migration upfront.

Step 4: Wrap the Legacy Database in Eloquent Models

Don't rename tables. Don't normalise the schema yet. Just point Eloquent at what's already there.

class LegacyUser extends Model
{
    protected $table = 'tbl_users'; // old naming convention
    protected $primaryKey = 'user_id';
    public $timestamps = false; // no created_at/updated_at columns

    protected $casts = [
        'is_active' => 'boolean',
        'created' => 'datetime', // maps the legacy column name
    ];

    public function getCreatedAtAttribute()
    {
        return $this->attributes['created'] ?? null;
    }
}

This gives you the full power of Eloquent — relationships, scopes, query builder — without touching the database. Schema refactoring comes later, after you've proven the migration works.

Step 5: Migrate Routes Module by Module

Pick the least risky, most self-contained module first. Admin dashboards, reporting pages, or internal tools are ideal. Avoid payment flows and the core checkout until you've built confidence.

For each module:

Reproduce the functionality in a Laravel controller and Blade view (or Livewire component).
Write feature tests that cover the happy path and the edge cases you found in the audit.
Update the nginx config to proxy that URL prefix to Laravel.
Monitor error logs for 48–72 hours before moving to the next module.

// Example feature test to lock in behaviour before refactoring
public function test_order_history_displays_for_authenticated_user(): void
{
    $user = LegacyUser::factory()->create();
    $orders = LegacyOrder::factory()->count(3)->for($user)->create();

    $response = $this->actingAs($user)->get('/account/orders');

    $response->assertOk();
    $response->assertSee($orders->first()->order_ref);
}

Tests written against the legacy behaviour become the safety net for every subsequent refactor.

Step 6: Schema Migration — When You're Ready

Once a module is fully running on Laravel and tested, you can consider schema normalisation. Use Laravel migrations with Schema::table() to add columns, rename things, and introduce proper indexes — but do it additively at first. Keep the old column, write to both, verify data integrity, then drop the old column in a later migration.

Schema::table('tbl_users', function (Blueprint $table) {
    $table->string('email')->nullable()->after('user_email');
    $table->index('email');
});

// Backfill in a job, not in the migration itself
LegacyUser::whereNull('email')->eachById(function ($user) {
    $user->update(['email' => $user->user_email]);
});

Never backfill large datasets in a migration. It locks the table and causes downtime.

Step 7: The Final Cutover

When all routes are handled by Laravel and the legacy entry points are dead code, you're ready to cut over fully. At this point:

Rename or archive the legacy directory.
Update nginx to point the root location directly at Laravel's public/ folder.
Remove the legacy FPM pool.
Run php artisan route:cache, config:cache, and view:cache in production.

Keep the legacy codebase archived for at least 90 days. You will want to reference it.

Hard-Won Opinions From Production

A few things learned from doing this on real client projects — including migrations handled through work at hanzweb.ae — that don't get mentioned in tutorials:

Don't let perfect be the enemy of shipped. Ugly Eloquent models that mirror a messy schema are fine. Clean them up once the system is stable.
The legacy app will have undocumented business logic. Read the old code before deleting it. Every mysterious if statement has a story.
Logging is your best diagnostic tool. Add structured logging via Monolog from day one. You'll thank yourself when something breaks in production at 2am.
Communicate with stakeholders about the strangler fig timeline. Migrations of this kind take months, not weeks. Set that expectation early.

Conclusion

Legacy migrations succeed when they're treated as a series of small, verifiable steps rather than a single heroic rewrite. The strangler fig pattern, shared sessions, Eloquent wrappers over existing tables, and feature tests written against legacy behaviour — these aren't glamorous techniques, but they're the ones that actually ship.

The end state is worth the effort: a codebase you can reason about, test confidently, and hand off to another developer without writing a 40-page onboarding document.

Site Speed and Search Rankings: Real Benchmarks, Core Web Vitals, and the Code Changes That Actually Move the Needle

Marcc Atayde — Mon, 31 Aug 2026 01:00:09 +0000

Google has been saying speed matters since 2010. Most developers nodded along and moved on. Then Core Web Vitals landed as confirmed ranking signals in 2021, and suddenly the conversation got a lot more specific — and a lot more urgent.

The problem is that most speed advice on the internet is either too surface-level ("enable caching!") or too abstract ("improve your LCP!") to be actionable. This article is neither. We're going deep on what the benchmarks actually mean, where sites lose rankings in practice, and what code-level changes produce real improvements.

Why Speed Is a Ranking Signal Worth Taking Seriously

Google's Page Experience documentation is clear: Core Web Vitals are used as a tiebreaker when content quality is roughly equal between two competing pages. That sounds minor until you realise how competitive most SERPs actually are. In practice, a well-optimised page with a 90+ PageSpeed score can outrank a slightly better-written page that loads in 6 seconds — and the gap widens on mobile.

The three signals that matter right now:

LCP (Largest Contentful Paint): How long until the main content element is visible. Target: under 2.5 seconds.
INP (Interaction to Next Paint): Replaced FID in March 2024. Measures responsiveness across all interactions, not just the first. Target: under 200ms.
CLS (Cumulative Layout Shift): Visual stability. Target: under 0.1.

LCP is the one most sites fail on. It's usually an image, a hero block, or a server-rendered heading — and it's almost always fixable.

Diagnosing Real Problems: Beyond Lighthouse Scores

Lighthouse is a lab tool. It simulates a single page load under controlled conditions. Real users are on throttled connections, low-end Android devices, and cold caches. The gap between your Lighthouse 95 and your actual field data in Google Search Console can be humbling.

Always cross-reference:

CrUX data in Search Console — this is the field data Google actually uses for ranking.
WebPageTest with a real device profile — run a Moto G Power test from a geographically relevant server.
performance.getEntriesByType('navigation') — instrument your own users in production.

// Drop this in your app's JS to capture real navigation timing
window.addEventListener('load', () => {
  const [nav] = performance.getEntriesByType('navigation');
  console.table({
    ttfb: nav.responseStart - nav.requestStart,
    domInteractive: nav.domInteractive,
    domComplete: nav.domComplete,
    loadEvent: nav.loadEventEnd - nav.loadEventStart,
  });
});

Once you're looking at field data, the usual suspects for LCP failures become obvious: unoptimised hero images, render-blocking scripts, and slow TTFB from the origin server.

Fixing LCP: The Image Pipeline

The single highest-ROI fix for most sites is image delivery. Here's what production-ready image handling looks like in a Laravel application:

// config/image.php — using Spatie's Laravel Image Optimizer
// Composer: spatie/laravel-image-optimizer

// In your Blade component for hero images

<!-- Use native lazy loading for below-fold images, but NEVER on LCP elements -->
<img
  src="{{ $heroImage->getUrl('webp') }}"
  srcset="
    {{ $heroImage->getUrl('sm') }} 640w,
    {{ $heroImage->getUrl('md') }} 1024w,
    {{ $heroImage->getUrl('lg') }} 1920w
  "
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 100vw, 1920px"
  fetchpriority="high"
  decoding="async"
  alt="{{ $alt }}"
/>

The fetchpriority="high" attribute is often missed. It tells the browser to prioritise this resource in the preload scanner, which can shave 300–800ms off LCP on images that are in the initial viewport.

For WebP conversion at upload time with Livewire:

// In your Livewire component
public function save()
{
    $this->validate(['photo' => 'required|image|max:5120']);

    $path = $this->photo->store('uploads', 'public');

    // Convert to WebP immediately
    $image = Image::load(storage_path('app/public/' . $path))
        ->format(ImageFormat::Webp)
        ->quality(82)
        ->save();

    // Store the WebP path, not the original
    $this->model->update(['image_path' => $path]);
}

Quality 82 is a production-tested sweet spot. Below 75 and compression artifacts become noticeable; above 85 and file sizes bloat without perceptible quality gain.

TTFB: The Server-Side Problem Nobody Wants to Fix

Time to First Byte is the foundation everything else builds on. A 2-second TTFB means your LCP can never be under 2 seconds, no matter how optimised your frontend is.

For Laravel apps, TTFB problems are usually one of three things:

1. Uncached database queries on the critical path

// Bad: this runs on every page load
$categories = Category::with('children')->get();

// Better: cache it with a tagged key so you can invalidate precisely
$categories = Cache::tags(['categories'])->remember('nav-categories', 3600, function () {
    return Category::with('children')->get();
});

2. Missing opcode cache configuration

Check that opcache.validate_timestamps is 0 in production. On shared hosting, developers often forget this setting is controlled by the host and defaults to timestamp validation on every request.

3. No full-page caching for anonymous users

For marketing pages that don't change per-user, spatie/laravel-responsecache can drop your TTFB from 400ms to under 20ms:

// In your middleware, exclude authenticated routes
public function handle(Request $request, Closure $next)
{
    if (auth()->check()) {
        return $this->addDoNotCacheHeaders($next($request));
    }

    return $next($request);
}

Fixing INP: JavaScript Execution Budget

INP failures are almost always caused by long tasks blocking the main thread. The browser's task scheduler doesn't care about your business logic — if a task runs for more than 50ms, it's considered "long" and will delay the next interaction response.

The fix is yielding back to the browser between chunks of work:

// Instead of processing a large array synchronously
function processItems(items) {
  items.forEach(item => heavyOperation(item));
}

// Yield between chunks using scheduler.yield() (or setTimeout fallback)
async function processItemsYielded(items) {
  const CHUNK_SIZE = 50;

  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE);
    chunk.forEach(item => heavyOperation(item));

    // Yield to the browser — allows pending interactions to fire
    if (i + CHUNK_SIZE < items.length) {
      await new Promise(resolve => setTimeout(resolve, 0));
    }
  }
}

For Alpine.js-heavy interfaces, be careful with x-on:click handlers that trigger multiple reactive updates. Each update can trigger a repaint. Batch your state changes where possible.

CLS: The Invisible UX Killer

Layout shift is usually caused by images without explicit dimensions, late-loading fonts, or dynamically injected banners. The fix is almost always the same: reserve space before content loads.

<!-- Always declare width and height on images — browser uses aspect-ratio internally -->
<img src="product.webp" width="800" height="600" alt="Product" />

<!-- For dynamic content blocks, use min-height to reserve space -->
<div class="min-h-[120px]" x-data="{ loaded: false }">
  <div x-show="loaded" x-transition>
    <!-- Dynamic content -->
  </div>
</div>

For font-related CLS, font-display: optional is the nuclear option — it prevents the browser from swapping fonts after the page has painted. Combined with preloading your primary font, it eliminates font-related shift entirely.

Putting It Together: A Prioritisation Framework

Most teams have limited time. Here's the order of operations based on what moves CrUX scores fastest in practice:

Fix TTFB first. Everything downstream improves when the server responds faster.
Audit your LCP element. Use DevTools' Performance panel to identify it, then apply fetchpriority="high" and confirm it's not lazy-loaded.
Convert images to WebP and add explicit dimensions.
Defer non-critical scripts. Third-party analytics, chat widgets, and A/B testing libraries are often the worst offenders.
Profile for long tasks. Chrome's Performance Insights panel flags them directly.

Clients at our agency — including several that came to us after being burned by slow, off-the-shelf implementations — often find the most impactful work happens at steps 1 and 2. If you're looking to hand this off to a team that thinks about these tradeoffs daily, working with the best web development company in Dubai means getting a build that's performance-optimised from the architecture up, not patched after the fact.

Conclusion

Core Web Vitals aren't a checkbox — they're a reflection of how your application actually behaves for real users on real devices. The benchmarks are specific enough that you can measure precisely what's broken and fix it methodically. Start with TTFB, work forward through LCP, then close out INP and CLS. Each fix compounds.

The developers who win at this aren't the ones who chase Lighthouse scores in incognito mode. They're the ones who instrument their production traffic, read their CrUX data, and treat performance as a feature — not a finishing step.

Laravel Livewire Wire:Model Deep Dive: Reactivity, Debouncing, and Lazy Binding Explained

Marcc Atayde — Tue, 18 Aug 2026 01:00:09 +0000

If you've been using Livewire for a while, you've almost certainly typed wire:model without thinking too hard about it. It works — data flows between your component and the DOM, and life is good. But once your apps grow, you start noticing things: inputs that feel sluggish, forms triggering unnecessary server round-trips, and components re-rendering when they really shouldn't.

This article goes deeper than the basics. We'll dissect how wire:model actually works under the hood, explore the full suite of modifiers (lazy, debounce, defer, live), and look at when each one should be your weapon of choice. By the end, you'll write Livewire bindings that are both reactive and efficient.

How `wire:model` Actually Works

At its core, wire:model is a two-way data binding directive. When a user types into an input, Livewire intercepts the DOM event, serializes the component's state, sends it to the server, re-renders the relevant parts of the component, and patches the DOM. That's a full HTTP request for every keystroke — by default.

This is called live binding, and it's the default in Livewire 3:

<input type="text" wire:model="search" />

Every input event fires a network request. For a search field with no debouncing, this means a request per character. Fine for prototyping, painful at scale.

The Modifier Toolkit

`wire:model.live` — Explicit Real-Time Binding

In Livewire 3, wire:model alone no longer triggers live updates by default. You need .live to replicate the old behavior explicitly:

<input type="text" wire:model.live="search" />

This is intentional. The Livewire team made the default lazy to avoid unnecessary requests, pushing developers toward more deliberate binding choices.

`wire:model.lazy` — Update on Blur

Use .lazy when you don't need the server to react until the user leaves the field:

<input type="text" wire:model.lazy="email" />

This binds to the change event rather than input, so the server only gets updated when focus leaves the element. Perfect for form fields like email addresses, where you validate on completion, not on every keystroke.

`wire:model.debounce` — Throttle Live Updates

Debouncing is the sweet spot for search inputs. Instead of sending a request per keypress, you wait until the user pauses:

<input type="text" wire:model.live.debounce.500ms="search" />

This chains .live (to enable real-time updates) with .debounce.500ms (to wait 500 milliseconds after the last keystroke before firing). The result is a responsive search field that doesn't hammer your server.

Here's a practical live-search component that puts it together:

<?php

namespace App\Livewire;

use Livewire\Component;
use App\Models\Product;

class ProductSearch extends Component
{
    public string $search = '';

    public function render()
    {
        $products = Product::query()
            ->when($this->search, fn($q) =>
                $q->where('name', 'like', "%{$this->search}%")
            )
            ->limit(10)
            ->get();

        return view('livewire.product-search', compact('products'));
    }
}

<div>
    <input
        type="text"
        wire:model.live.debounce.400ms="search"
        placeholder="Search products..."
        class="w-full border rounded px-4 py-2"
    />

    <ul class="mt-4 space-y-2">
        @foreach ($products as $product)
            <li class="p-2 border rounded">{{ $product->name }}</li>
        @endforeach
    </ul>
</div>

Clean, efficient, and no WebSocket configuration required.

`wire:model.defer` — Batch Updates on Form Submit

.defer holds the updated value client-side and only syncs it to the server when an action is triggered — typically a form submission:

<form wire:submit="save">
    <input type="text" wire:model.defer="title" />
    <textarea wire:model.defer="body"></textarea>
    <button type="submit">Save Post</button>
</form>

This is the most network-efficient option. All deferred values are batched into the action request rather than each triggering its own round-trip. For long forms, this can reduce server calls from dozens to one.

Choosing the Right Modifier

Here's a quick decision guide:

Use Case	Recommended Modifier
Search input with live results	`wire:model.live.debounce.400ms`
Email / username with validation	`wire:model.lazy`
Multi-field form with submit	`wire:model.defer`
Toggle / checkbox reacting immediately	`wire:model.live`
Character counter updating in real-time	`wire:model.live.debounce.200ms`

Nested Object Binding

Livewire supports binding to nested arrays and objects, which is useful for form objects:

public array $form = [
    'name' => '',
    'email' => '',
];

<input type="text" wire:model.defer="form.name" />
<input type="email" wire:model.defer="form.email" />

Or better yet, use Livewire's Form object pattern (introduced in Livewire 3) for validation encapsulation:

namespace App\Livewire\Forms;

use Livewire\Attributes\Rule;
use Livewire\Form;

class ContactForm extends Form
{
    #[Rule('required|min:2')]
    public string $name = '';

    #[Rule('required|email')]
    public string $email = '';
}

// In your component
public ContactForm $form;

public function submit()
{
    $this->form->validate();
    // process...
}

This keeps validation rules co-located with the data, making complex forms much easier to manage.

Debugging Wire:Model Issues

When bindings behave unexpectedly, check these common causes:

1. Missing public property initialization
Livewire can't bind to a property that doesn't exist or isn't public. Always initialize:

public string $search = ''; // ✅
private string $search = ''; // ❌ won't bind

2. Modifier conflicts
Don't combine .lazy and .live — they're mutually exclusive binding strategies. Pick one.

3. Alpine.js conflicts
If you're also using Alpine x-model on the same element, the two can conflict. Use wire:model for server state and Alpine x-model for purely local UI state on separate elements.

Real-World Context: Why This Matters at Scale

The difference between a debounced search and a naive wire:model.live binding doesn't matter on localhost. It absolutely matters when you have hundreds of concurrent users. A simple 400ms debounce on a search field can cut server requests by 80% or more under real load.

This kind of deliberate, performance-aware Livewire development is something teams building production TALL stack applications — whether SaaS products, e-commerce platforms, or enterprise tools — need to get right from the start. At hanzweb.ae, working across a range of Laravel projects in the region, these optimizations consistently come up as the difference between a sluggish prototype and a smooth production app.

Conclusion

wire:model is deceptively simple on the surface but has a lot of nuance once you factor in network efficiency and user experience. The core takeaway: default to .defer for forms, .lazy for single-field validation, and .live.debounce for anything search-like. Reach for plain .live only when you genuinely need immediate server reactivity.

Understanding which binding strategy fits which context is what separates Livewire components that scale from ones that don't. Now go audit your existing components — there's a good chance a few of them are doing more round-trips than they need to.

Laravel API Security in Depth: Sanctum Tokens, Granular Rate Limiting, and Multi-Version Routing

Marcc Atayde — Tue, 11 Aug 2026 01:00:05 +0000

You've built the endpoints, wired up the controllers, and the happy path works. Then someone hammers your API with 10,000 requests in a minute, a client ships a breaking change to mobile users on v1, and a rogue token gives third-party access to everything it shouldn't. This is where most "RESTful API" tutorials stop — and where real API design begins.

This article goes beyond the basics. We'll cover Laravel Sanctum token scopes, building genuinely useful rate limiting that doesn't punish legitimate users, and a versioning strategy that scales without turning your routes file into spaghetti.

Authentication with Laravel Sanctum: Scopes and Token Abilities

Sanctum is the right tool for most Laravel APIs — it's lightweight, integrates with your existing users table, and supports both SPA cookie auth and token-based auth. But most implementations ignore token abilities entirely.

Creating Tokens with Abilities

// Issue a token with specific abilities
$token = $user->createToken('mobile-app', ['products:read', 'orders:create']);

return response()->json([
    'token' => $token->plainTextToken,
]);

Checking Abilities in Controllers

public function store(Request $request)
{
    if (!$request->user()->tokenCan('orders:create')) {
        abort(403, 'Token lacks required ability: orders:create');
    }

    // proceed with order creation
}

Or use a dedicated middleware approach with a reusable ability check:

// app/Http/Middleware/RequireTokenAbility.php
public function handle(Request $request, Closure $next, string $ability): Response
{
    if (!$request->user()?->tokenCan($ability)) {
        return response()->json(['message' => 'Insufficient token permissions.'], 403);
    }

    return $next($request);
}

->withMiddleware(function (Middleware $middleware) {
    $middleware->alias([
        'token.ability' => RequireTokenAbility::class,
    ]);
})

Now your routes self-document their permission requirements:

Route::post('/orders', [OrderController::class, 'store'])
    ->middleware('token.ability:orders:create');

Granular Rate Limiting That Actually Makes Sense

The default throttle:60,1 is a blunt instrument. A read-heavy dashboard client and a bulk import tool have very different legitimacy profiles. Laravel's RateLimiter facade lets you build context-aware limits.

Defining Named Limiters

In AppServiceProvider::boot() (or a dedicated RateLimitServiceProvider):

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    return $request->user()
        ? Limit::perMinute(120)->by($request->user()->id)
        : Limit::perMinute(20)->by($request->ip());
});

RateLimiter::for('exports', function (Request $request) {
    return [
        Limit::perMinute(5)->by($request->user()->id),
        Limit::perDay(50)->by($request->user()->id),
    ];
});

RateLimiter::for('auth', function (Request $request) {
    return Limit::perMinute(10)->by($request->ip())
        ->response(function () {
            return response()->json([
                'message' => 'Too many login attempts. Try again in a moment.'
            ], 429);
        });
});

Applying Limiters to Route Groups

Route::middleware(['auth:sanctum', 'throttle:api'])->group(function () {
    Route::get('/products', [ProductController::class, 'index']);
    Route::get('/orders', [OrderController::class, 'index']);
});

Route::middleware(['auth:sanctum', 'throttle:exports'])->group(function () {
    Route::get('/orders/export', [ExportController::class, 'orders']);
});

Route::middleware('throttle:auth')->group(function () {
    Route::post('/login', [AuthController::class, 'login']);
});

The X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After headers are automatically injected by Laravel's throttle middleware — make sure your API clients are reading and respecting them.

API Versioning Without the Chaos

Versioning is one of those things that feels over-engineered until you ship a breaking change and break three client apps at once. There are two dominant patterns in Laravel: URL prefix versioning and header-based versioning. URL prefixing wins on debuggability — you can see the version in logs, browser tabs, and Postman without extra config.

Folder and Namespace Structure

app/Http/Controllers/
├── Api/
│   ├── V1/
│   │   ├── ProductController.php
│   │   └── OrderController.php
│   └── V2/
│       ├── ProductController.php
│       └── OrderController.php

Route Files

// routes/api.php
use App\Http\Controllers\Api;

Route::prefix('v1')->name('api.v1.')->group(function () {
    Route::apiResource('products', Api\V1\ProductController::class);
    Route::apiResource('orders', Api\V1\OrderController::class);
});

Route::prefix('v2')->name('api.v2.')->group(function () {
    Route::apiResource('products', Api\V2\ProductController::class);
    Route::apiResource('orders', Api\V2\OrderController::class);
});

Sharing Logic Between Versions with Base Controllers

Don't duplicate code — extend a versioned base from a shared abstract:

// app/Http/Controllers/Api/BaseProductController.php
abstract class BaseProductController extends Controller
{
    protected function formatProduct(Product $product): array
    {
        return [
            'id'    => $product->id,
            'name'  => $product->name,
            'price' => $product->price,
        ];
    }
}

// app/Http/Controllers/Api/V2/ProductController.php
class ProductController extends BaseProductController
{
    public function index()
    {
        return ProductResource::collection(
            Product::with('category')->paginate()
        );
    }
}

V2 adds category data and pagination; V1 keeps the original flat response. Both extend the same base — changes to shared logic propagate correctly.

API Resources: Your Contract with Consumers

Never return Eloquent models directly from an API. JsonResource classes act as a transformation and documentation layer:

// app/Http/Resources/V2/ProductResource.php
public function toArray(Request $request): array
{
    return [
        'id'         => $this->id,
        'name'       => $this->name,
        'price'      => number_format($this->price, 2),
        'currency'   => 'AED',
        'category'   => new CategoryResource($this->whenLoaded('category')),
        'created_at' => $this->created_at->toIso8601String(),
    ];
}

The whenLoaded() helper prevents N+1 and avoids over-fetching — the field only appears if the relationship was eager-loaded.

Practical Considerations for Production

Token rotation: Set token expiry and build a /auth/refresh endpoint. Long-lived tokens are a liability.

Structured error responses: Be consistent. Pick a shape and stick to it:

{
  "message": "Validation failed.",
  "errors": {
    "email": ["The email field is required."]
  }
}

Deprecation headers: When you ship v3, start sending Deprecation: true and Sunset: Sat, 01 Jan 2026 00:00:00 GMT headers on v1 responses. Clients that read headers will catch it early.

Logging: Attach the authenticated user ID and token ID to your log context inside a middleware so every log line is traceable:

Logger::withContext([
    'user_id'  => $request->user()?->id,
    'token_id' => $request->user()?->currentAccessToken()?->id,
]);

A colleague who works as a Dubai web developer once pointed out that the most expensive API bugs in client projects were never about logic — they were about missing authentication checks on a single route, a rate limiter that only applied to half the endpoints, and a versioning strategy that was never enforced. The infrastructure around your business logic matters as much as the logic itself.

Conclusion

Building a reliable Laravel API means thinking in layers: authentication that's granular enough to limit blast radius when a token leaks, rate limiting that's smart enough to distinguish users from bots, and versioning that lets you ship breaking changes without breaking anyone. Each of these is independently simple — the craft is in wiring them together consistently from day one rather than retrofitting them after your first incident.

Start with Sanctum abilities even if you don't need them yet. Define named rate limiters from day one. Create the V1 namespace before you have a V2. Future you will be grateful.

Building Intelligent Chatbots with RAG and Vector Databases: A Developer's Practical Guide

Marcc Atayde — Tue, 28 Jul 2026 01:00:07 +0000

Most chatbots are broken in a predictable way. You ask something slightly outside their training data, and they either hallucinate confidently or give you a useless "I don't know." The problem isn't the language model — it's the architecture. Retrieval-Augmented Generation (RAG) fixes this by grounding your chatbot in real, up-to-date knowledge rather than relying purely on what the model memorized during training.

In this guide, we'll build an intelligent chatbot using RAG, a vector database, and Laravel as the backend. By the end, you'll understand the full pipeline: from chunking documents and generating embeddings, to querying a vector store and feeding retrieved context into an LLM response.

What Is RAG and Why Does It Matter?

RAG stands for Retrieval-Augmented Generation. Instead of asking a language model to answer purely from memory, you first retrieve relevant documents from a knowledge base, then pass those documents as context to the model alongside the user's question.

The result: answers that are accurate, grounded in your own data, and far less likely to hallucinate.

The pipeline looks like this:

Ingest — Load documents, chunk them, generate embeddings, store in a vector database
Query — Embed the user's question, run a similarity search against your vector store
Generate — Feed retrieved chunks + question into an LLM, return the response

Setting Up the Stack

For this guide we'll use:

Laravel as the application backend
OpenAI for embeddings (text-embedding-3-small) and chat completions (gpt-4o)
Qdrant as the vector database (self-hosted or cloud)
openai-php/laravel client package

composer require openai-php/laravel
php artisan vendor:publish --provider="OpenAI\Laravel\ServiceProvider"

Add your key to .env:

OPENAI_API_KEY=sk-...
QDRANT_URL=http://localhost:6333
QDRANT_COLLECTION=knowledge_base

Step 1: Ingesting and Chunking Documents

The quality of your RAG system lives or dies by how well you chunk your documents. Chunks that are too large lose precision; too small and you lose context. A sliding window of ~500 tokens with ~50-token overlap tends to work well in practice.

// app/Services/DocumentIngestionService.php

namespace App\Services;

use OpenAI\Laravel\Facades\OpenAI;
use Illuminate\Support\Collection;

class DocumentIngestionService
{
    public function chunkText(string $text, int $chunkSize = 500, int $overlap = 50): array
    {
        $words = explode(' ', $text);
        $chunks = [];
        $start = 0;

        while ($start < count($words)) {
            $chunk = array_slice($words, $start, $chunkSize);
            $chunks[] = implode(' ', $chunk);
            $start += ($chunkSize - $overlap);
        }

        return $chunks;
    }

    public function embedChunks(array $chunks): Collection
    {
        return collect($chunks)->map(function (string $chunk) {
            $response = OpenAI::embeddings()->create([
                'model' => 'text-embedding-3-small',
                'input' => $chunk,
            ]);

            return [
                'text'      => $chunk,
                'embedding' => $response->embeddings[0]->embedding,
            ];
        });
    }
}

Step 2: Storing Embeddings in Qdrant

Qdrant is a purpose-built vector database with a clean REST API. We'll use Laravel's HTTP client to interact with it directly — no SDK needed.

// app/Services/VectorStoreService.php

namespace App\Services;

use Illuminate\Support\Facades\Http;
use Illuminate\Support\Str;

class VectorStoreService
{
    protected string $baseUrl;
    protected string $collection;

    public function __construct()
    {
        $this->baseUrl    = config('services.qdrant.url');
        $this->collection = config('services.qdrant.collection');
    }

    public function upsertPoints(array $points): void
    {
        $payload = collect($points)->map(fn($point) => [
            'id'      => (string) Str::uuid(),
            'vector'  => $point['embedding'],
            'payload' => ['text' => $point['text']],
        ])->values()->all();

        Http::put("{$this->baseUrl}/collections/{$this->collection}/points", [
            'points' => $payload,
        ]);
    }

    public function search(array $queryEmbedding, int $topK = 5): array
    {
        $response = Http::post("{$this->baseUrl}/collections/{$this->collection}/points/search", [
            'vector' => $queryEmbedding,
            'limit'  => $topK,
            'with_payload' => true,
        ]);

        return collect($response->json('result'))
            ->pluck('payload.text')
            ->all();
    }
}

Step 3: The RAG Query Pipeline

This is where it all comes together. We embed the user's question, retrieve the most relevant chunks, then construct a prompt that grounds the LLM in that context.

// app/Services/ChatbotService.php

namespace App\Services;

use OpenAI\Laravel\Facades\OpenAI;

class ChatbotService
{
    public function __construct(
        protected VectorStoreService $vectorStore
    ) {}

    public function answer(string $userQuestion): string
    {
        // 1. Embed the question
        $embeddingResponse = OpenAI::embeddings()->create([
            'model' => 'text-embedding-3-small',
            'input' => $userQuestion,
        ]);
        $queryVector = $embeddingResponse->embeddings[0]->embedding;

        // 2. Retrieve relevant context
        $contextChunks = $this->vectorStore->search($queryVector, topK: 5);
        $context = implode("\n\n", $contextChunks);

        // 3. Build grounded prompt
        $systemPrompt = <<<PROMPT
        You are a helpful assistant. Answer the user's question using ONLY the context provided below.
        If the answer is not in the context, say "I don't have enough information to answer that."

        Context:
        {$context}
        PROMPT;

        // 4. Generate response
        $completion = OpenAI::chat()->create([
            'model'    => 'gpt-4o',
            'messages' => [
                ['role' => 'system',  'content' => $systemPrompt],
                ['role' => 'user',    'content' => $userQuestion],
            ],
        ]);

        return $completion->choices[0]->message->content;
    }
}

Wiring It Up with a Livewire Component

For real-time UX, a Livewire component handles streaming the response without a full page reload:

// app/Livewire/Chatbot.php

namespace App\Livewire;

use App\Services\ChatbotService;
use Livewire\Component;

class Chatbot extends Component
{
    public string $question = '';
    public string $answer   = '';
    public bool   $loading  = false;

    public function ask(ChatbotService $chatbot): void
    {
        $this->validate(['question' => 'required|string|max:500']);

        $this->loading = true;
        $this->answer  = $chatbot->answer($this->question);
        $this->loading = false;
    }

    public function render()
    {
        return view('livewire.chatbot');
    }
}

Improving Retrieval Quality

Once the basic pipeline works, a few techniques can significantly improve answer quality:

Hybrid Search

Combine vector similarity search with keyword (BM25) search. Qdrant supports sparse + dense vector search natively. This prevents edge cases where exact keyword matches score poorly in pure embedding space.

Re-ranking

After your initial top-K retrieval, run a cross-encoder re-ranker (e.g., via Cohere's Rerank API) to re-order results by true relevance to the question before constructing the prompt.

Metadata Filtering

Tag your chunks with metadata — document type, date, category — and pre-filter before the vector search. This is especially useful for multi-tenant systems where users should only see their own data.

// Example: filter by tenant in Qdrant search
Http::post("{$this->baseUrl}/collections/{$this->collection}/points/search", [
    'vector' => $queryEmbedding,
    'limit'  => $topK,
    'filter' => [
        'must' => [
            ['key' => 'tenant_id', 'match' => ['value' => auth()->id()]],
        ],
    ],
    'with_payload' => true,
]);

Real-World Considerations

Building this in production surfaces a few gotchas worth knowing before you deploy:

Embedding costs: text-embedding-3-small is cheap, but large document libraries still add up. Cache embeddings aggressively and only re-embed on document change.
Chunk freshness: When source documents update, you need a strategy to re-ingest the affected chunks and delete stale vectors by document ID.
Latency: Two API calls (embed + generate) plus a vector search adds 1–3 seconds. Use Laravel queues and optimistic UI patterns to keep the experience snappy.
Evaluation: Build a test set of question/answer pairs and track retrieval recall + answer faithfulness. Without measurement, you're flying blind. Tools like RAGAS can automate this.

For teams exploring how these patterns integrate into client projects — whether it's document Q&A, internal knowledge bases, or customer support bots — there's genuinely useful material to check it out across different AI integration approaches.

Conclusion

RAG isn't a silver bullet, but it's the most practical architecture for building chatbots that actually know what they're talking about. The core pattern — embed, retrieve, generate — is straightforward in Laravel once you have the scaffolding in place. The real engineering work is in the details: chunk strategy, hybrid search, metadata filtering, and evaluation.

Start simple: get one document ingested and a basic similarity search working end-to-end. Then layer on the improvements. A working RAG pipeline you can iterate on beats a theoretically perfect one you never ship.

DEV Community: Marcc Atayde

PWA Architecture Decisions That Actually Matter in Production: Manifests, Workbox Strategies, and Push Notifications Done Right

The Manifest Is More Than a Checklist

Service Worker Caching: Pick the Right Strategy Per Resource Type

Handling Cache Invalidation on Deploy

Push Notifications: The Server-Side Is Where It Gets Real

The Install Prompt: Don't Fight the Browser

Content Strategy Matters Too

Conclusion

WCAG Compliance for Business Websites: A Developer's Practical Guide to Accessibility That Actually Ships

Understanding WCAG 2.1 AA: The Target You're Actually Shooting For

The High-Impact Failures (And How to Fix Them)

1. Keyboard Navigation Traps and Missing Focus Styles

2. Form Errors That Screen Readers Can't Announce

3. Images and Icon Buttons Without Accessible Names

4. Color Contrast at Scale

Automating What You Can: axe-core in Your Test Suite

The Manual Testing Workflow That Actually Works

Semantic HTML: Still the Most Underrated Accessibility Tool

Conclusion

How AI Is Actually Changing Web Agency Workflows: The Honest Developer's Breakdown

Where AI Is Genuinely Useful in Agency Work

Content Intelligence Pipelines

Automated Code Review as a CI Step

The Problems Nobody Talks About

Context Window Debt

Over-Reliance on Generation for Client-Facing Content

What Skills Actually Compound Here

Conclusion

Image Optimization Beyond Compression: Lazy Loading, Modern Formats, and the Rendering Pipeline Tricks That Actually Help

Understanding the Rendering Pipeline First

Format Selection: AVIF, WebP, and the Reality of Decode Cost

Responsive Images: srcset and sizes Done Correctly

Building a Blade Component for Consistency

CDN Delivery and Cache-Control Headers

Conclusion

Structured Data in 2025: Schema Markup That Actually Wins Rich Results (With Real Laravel Examples)

Why Most Schema Implementations Underperform

The Schema Types Worth Prioritising in 2025

Article / BlogPosting

FAQPage

Product with Offer and AggregateRating

Generating Schema Programmatically in Laravel

Testing Beyond the Rich Results Tool

The Entity Relationship Angle

Conclusion

Integrating AI APIs into Web Applications: OpenAI, Claude, and DeepSeek Compared in Production

The Provider Landscape in 2025

Building a Provider-Agnostic Abstraction

Structured Output: The Feature That Changes Everything

Error Handling and Resilience

Cost Control in Practice

Claude's Edge: Long Context and Instruction Fidelity

Conclusion

Progressive Web Apps in 2025: A Production-Focused Guide to Service Workers, Caching, and the Install Experience

What a PWA Actually Is (Past the Marketing)

The Manifest: More Than name and icons

Service Workers: The Lifecycle Is the Hard Part

Caching Strategies: Match the Strategy to the Resource

Background Sync for Offline Write Operations

Safari: The Reality Check

Testing Your Service Worker

Conclusion

Migrating Legacy Websites to Modern Laravel: A Practical, Battle-Tested Guide

Why Incremental Migration Beats the Big Bang Rewrite

Step 1: Audit Before You Touch Anything

Step 2: Stand Up Laravel Alongside the Legacy App

Step 3: Shared Session State

Step 4: Wrap the Legacy Database in Eloquent Models

Step 5: Migrate Routes Module by Module

Step 6: Schema Migration — When You're Ready

Step 7: The Final Cutover

Hard-Won Opinions From Production

Conclusion

Site Speed and Search Rankings: Real Benchmarks, Core Web Vitals, and the Code Changes That Actually Move the Needle

Why Speed Is a Ranking Signal Worth Taking Seriously

Diagnosing Real Problems: Beyond Lighthouse Scores

Fixing LCP: The Image Pipeline

TTFB: The Server-Side Problem Nobody Wants to Fix

Fixing INP: JavaScript Execution Budget

Responsive Images: `srcset` and `sizes` Done Correctly

`Article` / `BlogPosting`

`FAQPage`

`Product` with `Offer` and `AggregateRating`

The Manifest: More Than `name` and `icons`

How `wire:model` Actually Works

`wire:model.live` — Explicit Real-Time Binding

`wire:model.lazy` — Update on Blur

`wire:model.debounce` — Throttle Live Updates

`wire:model.defer` — Batch Updates on Form Submit