DEV Community: Sara Casciaro

Why Your Lighthouse Score Lies: Real-World Performance Optimization for WordPress Sites

Sara Casciaro — Mon, 08 Jun 2026 09:00:00 +0000

Lighthouse is the first thing clients send you when they think their website is slow. A screenshot of the Performance tab, a score in the red or yellow zone, and the question: "Can you fix this?"

The honest answer is: it depends on what you mean by fix.

Lighthouse measures a simulated experience on a throttled mobile connection, using a headless Chrome instance running on Google's servers. It is an incredibly useful diagnostic tool. It is also a number that can be gamed in ways that mean absolutely nothing for real users.

This guide is about the gap between what Lighthouse reports and what actually makes a WordPress site fast for the people visiting it, and what to prioritize when you are optimizing a production site for a real business.

The Metrics That Actually Matter

Lighthouse reports six metrics, but three of them have a direct, measurable impact on user experience and Google rankings: LCP (Largest Contentful Paint), INP (Interaction to Next Paint, which replaced FID in 2024), and CLS (Cumulative Layout Shift).

LCP measures how long it takes for the largest visible element, usually a hero image or a large heading, to fully render. Google considers anything under 2.5 seconds good. For most WordPress sites, LCP is dominated by the featured image or the hero section background, and it is almost always the first thing to optimize.

INP measures responsiveness: how long it takes for the page to respond after a user interacts with it. This is where JavaScript-heavy WordPress setups struggle most. Every plugin that adds JS to the frontend is a potential INP killer.

CLS measures visual stability: whether elements jump around as the page loads. Common culprits in WordPress are images without explicit dimensions, web fonts causing layout shifts during load, and ads or embeds that push content down.

If you focus exclusively on these three and ignore the others, you will have done 80% of the meaningful work.

The LCP Problem in WordPress

The most common LCP issue in WordPress sites is a hero image that is not treated as a priority resource. By default, WordPress lazy-loads images, which means the browser delays loading them until they are near the viewport. For images that are already in the viewport on page load, exactly like a hero image, lazy loading actively hurts LCP.

Add loading="eager" and fetchpriority="high" directly to the hero image markup in your theme or page builder output. This tells the browser to treat it as a high-priority resource and start loading it immediately.

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="100vw"
  width="1200"
  height="600"
  fetchpriority="high"
  loading="eager"
  alt="Your descriptive alt text here"
>

Note the explicit width and height attributes. These prevent CLS by reserving the correct space in the layout before the image loads.

The second LCP killer is image format and size. A 2MB JPEG hero image on a mobile connection will produce a bad LCP regardless of everything else you do. WebP at the right dimensions with proper srcset implementation is not optional anymore. It is the baseline.

If you need to remove lazy loading programmatically in WordPress for specific images:

add_filter( 'wp_lazy_loading_enabled', function( $default, $tag_name, $context ) {
    if ( $tag_name === 'img' && $context === 'the_content' ) {
        return false;
    }
    return $default;
}, 10, 3 );

Handle this granularly in production. Disabling lazy loading globally will hurt performance for images below the fold.

INP and the JavaScript Problem

Most WordPress performance conversations focus on page load speed and ignore interactivity. INP changed that by making responsiveness a Core Web Vital that affects rankings.

The root cause of poor INP in WordPress is almost always JavaScript execution on the main thread. Every plugin that loads JS on the frontend is competing for the same single thread. When a user clicks something and the browser is busy executing plugin scripts, the response is delayed.

The diagnostic step is straightforward: open Chrome DevTools, go to Performance, record an interaction such as a click or form input, and look for long tasks blocking the main thread. The responsible scripts are usually immediately identifiable.

If the script is not needed for the initial render or for above-the-fold interactivity, defer it:

<script src="plugin-script.js" defer></script>

If it can be loaded after user interaction, such as analytics, chat widgets, or non-critical features, load it on user gesture:

document.addEventListener('click', function loadScript() {
    const script = document.createElement('script');
    script.src = 'heavy-widget.js';
    document.head.appendChild(script);
    document.removeEventListener('click', loadScript);
}, { once: true });

For WordPress specifically: audit every active plugin and ask whether it actually needs to load JS on every page. Many plugins load their scripts globally even when they are only needed on specific pages or post types. Conditional loading via wp_enqueue_scripts with proper conditional tags eliminates a significant portion of unnecessary JS.

add_action( 'wp_enqueue_scripts', function() {
    if ( is_singular( 'post' ) ) {
        wp_enqueue_script( 'my-plugin-script', get_template_directory_uri() . '/js/plugin.js', array(), '1.0', true );
    }
});

CLS and the Font Loading Problem

Cumulative Layout Shift caused by web fonts is one of the most common and most overlooked issues in WordPress themes. The browser loads the page, renders text in a fallback system font, then swaps to the web font once it loads, causing a visible shift in layout.

The modern solution is the font-display: swap CSS property combined with preloading critical fonts:

<link rel="preload" href="/fonts/primary-font.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
    font-family: 'PrimaryFont';
    src: url('/fonts/primary-font.woff2') format('woff2');
    font-display: swap;
}

font-display: swap tells the browser to show text immediately with a fallback font, then swap when the web font is ready. Combined with preloading, the swap happens fast enough to be invisible to most users.

If you are using Google Fonts, self-hosting them eliminates one DNS lookup and gives you control over caching headers. Both are meaningful optimizations for LCP and CLS that add up at scale.

The Caching Layer Matters More Than You Think

A WordPress site without proper server-level caching is doing unnecessary work on every request. PHP executes, database queries run, HTML is assembled for every single visitor, every single time. On shared hosting, this adds meaningful latency to every page load.

Object caching with Redis or Memcached removes the database query overhead for repeat requests. Page caching serves pre-built HTML files directly, bypassing PHP entirely. CDN caching serves static assets from edge locations close to the visitor.

The order of optimization priority: page cache first, then object cache, then CDN for static assets. Each layer compounds on the previous one.

For most WordPress sites on managed hosting with server-level caching configured correctly, the plugin-level caching layer becomes less critical. Know what your hosting stack provides before adding complexity with additional plugins.

What a Good Score Actually Looks Like in Production

A Lighthouse score of 95 in the lab means nothing if your real-user data in Google Search Console shows LCP averaging 4 seconds. The lab score measures a single simulated load. Real users arrive with warm connections, cached resources, varying devices and network conditions.

The CrUX (Chrome User Experience Report) data in Search Console reflects actual user experiences over a 28-day window. This is the data Google uses for ranking. This is the data you should optimize toward.

The workflow for a WordPress performance audit:

Check CrUX data in Search Console for real-user Core Web Vitals
Run Lighthouse for diagnostic details on specific issues
Profile the main thread with DevTools Performance panel
Audit JS and CSS payload with the Coverage tool
Fix LCP, INP, CLS in that order
Verify in CrUX after 28 days

The 28-day cycle is the frustrating reality of Core Web Vitals optimization. Changes you make today will not show up in your Search Console data for a month. Build your optimization workflow around that timeline, not around Lighthouse screenshots.

Written by Sara Casciaro, founder of Sabriel Agency, digital studio in Ugento (LE), Italy.

Schema Markup JSON-LD for Local Businesses: A Practical Implementation Guide

Sara Casciaro — Sat, 09 May 2026 06:27:15 +0000

If you have ever wondered why some businesses show up in Google search with rich results like star ratings, address, opening hours and service area, while others appear as plain blue links, the answer is almost always structured data. Specifically, JSON-LD schema markup.

This guide walks through exactly how to implement LocalBusiness schema for small and medium-sized businesses, why it matters more than most developers think, and the common mistakes that make it useless even when it is technically present.

What JSON-LD Schema Markup Actually Does

Schema markup is a vocabulary of tags you add to your HTML that helps search engines understand your content in a structured, machine-readable way. JSON-LD (JavaScript Object Notation for Linked Data) is Google's preferred format. It sits in a script tag in your document head, completely separate from your visible HTML, which makes it easy to implement and maintain without touching your layout.

For local businesses, the LocalBusiness schema type tells Google exactly who you are, what you do, where you are, when you are open, and how to contact you. This structured signal complements your Google Business Profile and helps Google display your information accurately in search results, Maps, and increasingly in AI-generated answer summaries.

The SEO value is real. According to Google's own documentation, properly implemented structured data can enable rich results that significantly improve click-through rates compared to plain organic listings. For local businesses competing in a specific geographic area, this visibility advantage is concrete and measurable.

The Basic LocalBusiness JSON-LD Structure

Here is a clean, minimal implementation for a professional services business:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Your Business Name",
  "description": "A clear, specific description of what your business does and who it serves.",
  "url": "https://yourdomain.com",
  "telephone": "+39000000000",
  "email": "hello@yourdomain.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via Example 1",
    "addressLocality": "Your City",
    "addressRegion": "Province",
    "postalCode": "00000",
    "addressCountry": "IT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.0000,
    "longitude": 18.0000
  },
  "areaServed": {
    "@type": "Country",
    "name": "Italy"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "priceRange": "€€",
  "sameAs": [
    "https://www.facebook.com/yourbusiness",
    "https://www.linkedin.com/company/yourbusiness"
  ]
}
</script>

The @type value ProfessionalService is a subtype of LocalBusiness. Always use the most specific type that fits your client. Schema.org lists dozens of subtypes: Restaurant, MedicalBusiness, LegalService, HomeAndConstructionBusiness, and many more. The more specific your type, the better Google understands the business category.

The geo coordinates are optional but strongly recommended for local SEO. They remove any ambiguity about exact location, especially in areas where street address matching might be imprecise.

Choosing the Right @type

This is where most implementations go wrong. Using generic LocalBusiness as a type works, but you are leaving precision on the table. Google uses the specific type to determine which rich result features are applicable and how to categorize the business in local search.

Here is a quick reference for common business types:

Restaurant           → schema.org/Restaurant
Dental Clinic        → schema.org/Dentist
Law Firm             → schema.org/LegalService
Photography Studio   → schema.org/PhotographyBusiness
Web Agency           → schema.org/ProfessionalService
Hair Salon           → schema.org/HairSalon
Hotel or B&B         → schema.org/LodgingBusiness
E-commerce Store     → schema.org/Store

For service-area businesses without a physical storefront, like freelancers and remote agencies, omit the address field and use areaServed instead:

"areaServed": [
  { "@type": "City", "name": "Rome" },
  { "@type": "City", "name": "Milan" }
]

Or for country-wide service:

"areaServed": {
  "@type": "Country",
  "name": "Italy"
}

WordPress Implementation: The Right Way

Plugins like RankMath and Yoast generate schema automatically, but they do not always give you granular control and sometimes produce bloated or incorrect output.

The cleanest approach is injecting custom JSON-LD directly via functions.php, bypassing auto-generated schema entirely:

function add_local_business_schema() {
    if ( is_front_page() ) {
        $schema = [
            '@context' => 'https://schema.org',
            '@type'    => 'ProfessionalService',
            'name'     => get_bloginfo('name'),
            'url'      => home_url(),
        ];
        echo '<script type="application/ld+json">' .
             wp_json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) .
             '</script>';
    }
}
add_action('wp_head', 'add_local_business_schema');

Using wp_json_encode with JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE keeps the output clean and readable.

If you are using WPCode for custom code injection, add the snippet as a PHP snippet with "Site Wide Header" placement. It works without touching theme files and survives theme updates.

The areaServed vs Address Distinction

A business can serve an entire country while being physically located in a small town. Schema handles these as two separate fields.

address tells Google where the business is physically located. It feeds into Google Maps and the local pack for geographic proximity signals.

areaServed tells Google where the business can serve clients. For a remote digital studio, this might be all of Italy even if the physical office is in a small town in Puglia.

Both should coexist when applicable:

"address": {
  "@type": "PostalAddress",
  "streetAddress": "Via Sant'Antonio 68",
  "addressLocality": "Ugento",
  "postalCode": "73059",
  "addressCountry": "IT"
},
"areaServed": {
  "@type": "Country",
  "name": "Italy"
}

Common Implementation Mistakes

Duplicate schema with conflicting data. If RankMath or Yoast is generating schema automatically and you are also adding custom JSON-LD, you end up with two conflicting schemas on the same page. Always check with Google's Rich Results Test before assuming your implementation is clean.

NAP inconsistency. Name, Address and Phone number in your schema must exactly match your Google Business Profile, your website footer, and every directory listing. Even minor variations like "Via S. Antonio" vs "Via Sant'Antonio" weaken your local SEO signals. This is one of the most common and most damaging mistakes in local SEO.

Missing @id for linked data. Adding an @id property makes your schema node referenceable across multiple pages:

"@id": "https://yourdomain.com/#organization"

This matters when you want blog posts, service pages and team pages to all reference the same organization entity.

Generic descriptions. The description field gets indexed. Write it like a focused meta description: specific, keyword-aware, under 160 characters. Be explicit about what the business does and who it serves.

Wrong opening hours format. Days of the week must be full English strings: Monday, Tuesday and so on. Not abbreviations. Violations silently break rich result eligibility without throwing visible errors.

Validating Your Implementation

Use Google's Rich Results Test to validate your JSON-LD and preview how Google reads it. Use Schema.org's validator for a more detailed structural check.

Pay attention to warnings, not just errors. A schema can be technically valid but still missing properties that unlock specific rich result types.

In Google Search Console, the Enhancements section shows detected structured data across your site after Google crawls the updated pages.

What to Expect After Implementation

Structured data does not produce overnight ranking changes. It typically takes two to four weeks for Google to recrawl affected pages and update its index.

The impact you are looking for is in rich result eligibility, knowledge panel accuracy, and local pack performance. For local businesses competing in specific geographic areas, clean schema plus an optimized Google Business Profile plus consistent NAP across directories is one of the most reliable local SEO foundations you can build.

Written by Sara Casciaro, founder of Sabriel Agency, digital studio in Ugento (LE), Italy.

WordPress vs Custom Development: A Practical Framework for Making the Right Call

Sara Casciaro — Mon, 06 Apr 2026 10:16:51 +0000

WordPress vs Custom Development: A Practical Framework for Making the Right Call

Every time a client comes to me with a new project, eventually the question comes up: "Should we use WordPress or build something custom?"

I've been asked this enough times that I've developed a fairly systematic way of thinking about it. Not a rigid rule, because the answer genuinely depends on context, but a set of criteria that helps me cut through the noise and make a decision I can defend six months into a project.

Here's how I actually think about it.

First: Reject the False Dichotomy

Before we get into the framework, I want to push back on how the question is usually framed. "WordPress vs custom" implies that WordPress isn't custom, but a well-built WordPress site with properly organized templates, custom post types, and a clean plugin stack is absolutely custom software. It just happens to run on a well-understood foundation.

The real question is: does the available WordPress ecosystem solve your specific problem well, or do you need to build something that doesn't exist yet?

With that reframing, let's look at the criteria.

Criterion 1: Who Maintains Content?

If the answer is "a non-technical person who needs to update the site themselves," WordPress wins almost every time.

The admin interface is familiar, widely documented, and forgiving. A client can add a blog post, update a service page, or swap an image without touching code. This matters more than people think. The best-built custom CMS is worthless if the client is afraid to use it.

The exception: if you're building a headless architecture where the CMS is separated from the frontend, there are purpose-built headless CMSes like Contentful, Sanity, and Strapi that offer better developer experience without sacrificing editor-friendliness.

Criterion 2: What's the Budget and Timeline?

Let's be honest about the math.

WordPress with a well-configured theme can deliver a solid 10-page business site in 3-4 weeks. A custom-built equivalent would take 2-3x longer. That time difference costs money, either yours or the client's.

For most small business sites, the performance, SEO, and flexibility differences between WordPress and custom aren't significant enough to justify doubling the budget. The marginal gain doesn't justify the cost.

Custom development makes economic sense when the project requires complex business logic that would require building custom WordPress plugins anyway, when performance requirements are extreme and the WordPress overhead is genuinely problematic, when the client has an internal dev team that will maintain and extend the codebase, or when the project scope is large enough that the upfront custom build cost amortizes over time.

Criterion 3: What Are the Performance Requirements?

WordPress gets a bad reputation for performance that's mostly deserved by bad WordPress implementations, not the platform itself.

A WordPress site with a lightweight theme like GeneratePress or Kadence, an object cache like Redis or Memcached, a page cache like LiteSpeed Cache or WP Rocket, WebP images and a CDN, and no more than 10-15 carefully selected plugins can score 95+ on Google PageSpeed Insights and pass Core Web Vitals without much difficulty.

The performance problems come from 50 plugins, heavy page builders making 80 database queries per page, unoptimized images, no caching, and shared hosting with limited resources.

That said, there are cases where WordPress genuinely can't compete. If you're building something with thousands of concurrent users, complex real-time functionality, or very specific server-side rendering requirements, a custom Node.js or PHP application, or a headless setup, is the right call.

Criterion 4: What Does the Integration Landscape Look Like?

WordPress has an enormous plugin ecosystem. Payment gateways, booking systems, LMS platforms, CRM integrations, membership systems — there's usually a plugin that covers 80% of what you need.

But "80% of what you need" isn't always enough. If the remaining 20% requires the kind of customization that means you're essentially rewriting a plugin to work differently than it was designed, you're probably better off building that component from scratch on a custom codebase.

I've spent enough hours fighting WooCommerce to make it do something it wasn't designed for that I can recognize when it's time to step back and build a proper custom solution for e-commerce edge cases.

The Middle Path: Headless WordPress

Nobody talks about this enough in the "WordPress vs custom" debate: headless WordPress is a legitimate third option that combines the best of both worlds.

WordPress as the content layer: editors use a familiar interface, content is stored in a database, the REST API or WPGraphQL exposes everything cleanly.

A modern JavaScript framework like Next.js, Nuxt, or Astro as the frontend layer: full control over rendering, excellent performance, server-side rendering or static generation as needed.

This is increasingly what I recommend for e-commerce projects or content-heavy sites where SEO performance is critical and the client team needs to manage content themselves.

The tradeoff: higher upfront development cost, more complex deployment, and a dependency between two separate applications. Not the right choice for a straightforward 10-page business site. Absolutely the right choice for a high-traffic media site or a complex e-commerce platform.

My Actual Decision Framework

Here's the simplified version.

Choose WordPress when non-technical content editors will maintain the site, when the budget is under €5,000 and timeline is under 8 weeks, when the requirements are well within what plugins and themes handle well, or when the client needs something live quickly and can expand later.

Choose custom when the project has complex business logic that doesn't fit any existing plugin architecture, when the team has developers who will maintain and extend the codebase, when performance at scale is a hard requirement, or when you need functionality that would require rebuilding a plugin from scratch anyway.

Consider headless WordPress when content editors need a familiar CMS but frontend performance is critical, when SEO requirements are serious and you need full control over rendering, or when the budget supports the added complexity.

The Most Common Mistake

The most common mistake I see isn't choosing the wrong platform. It's choosing the right platform and implementing it badly.

A custom-built site with poor database design and no caching will be slower than a well-configured WordPress site. A WordPress site with 60 plugins and no performance optimization will be a nightmare regardless of the theme.

Platform choice matters less than implementation quality. Whatever you build, build it well.

Written by Sara Casciaro, founder of Sabriel Agency, a digital studio in Ugento, Lecce, Italy, building websites, e-commerce, and digital interfaces for businesses that need things done right. sabrielagency.com

The Website That Doesn't Convert Is Worse Than Having None

Sara Casciaro — Mon, 23 Mar 2026 18:57:14 +0000

By Sara Casciaro, Founder of Sabriel Agency

There is a very common illusion among small businesses: having a website means being present online. It is an understandable belief, but a dangerous one. Because a poorly built website is not neutral. It is actively harmful. It communicates distrust, wastes budget, and convinces potential clients to choose a competitor.

I have built websites for restaurants, luxury brands, fashion e-commerce, medical practices, and AI mobile apps. In every project I learned the same thing: the problem is never the lack of a website. It is the lack of a system.

The Numbers the Industry Prefers Not to Show You

According to Google, 53% of mobile users abandon a page that takes more than 3 seconds to load. Not 10%, not 20%, 53%.
The Nielsen Norman Group documented that users read on average only 20% of the text on a web page. Writing long, dense texts without visual structure is wasted effort.
According to HubSpot, companies with an active blog generate 67% more leads than those that do not publish content. Yet most websites have no blog, or abandoned it after three articles.

These are not abstract figures. They explain why so many websites exist but do not work.

The Real Problem: Confusing Presence with Performance

When we design a website we do not start with the design. We start with a question: who is the user, what are they looking for, and what convinces them to make a request? Only after answering that question does it make sense to talk about color palettes, typography, and hero sections. Design is not decoration. It is communication. Every visual choice must serve a precise objective.

The structure determines user behavior, not the other way around.

The 4 Pillars of a Website That Delivers Results

Real Speed, Not Perceived Speed

Speed is measured by Core Web Vitals: LCP, FID, and CLS. These parameters directly influence Google ranking. A slow website does not just lose users, it loses organic visibility. The solution involves:

High performance hosting
Correctly configured cache
Images in WebP format
Lazy loading

SEO Architecture Designed From the Start

SEO is not added to an already built website like paint on a wall. It is designed into the architecture from day one:

Clean URLs
Hierarchical heading structure
Schema markup for search engines
XML sitemap
Canonical tags to avoid duplicate content

A Clear Message in the First 5 Seconds

A visitor who lands on your homepage has 5 seconds to understand three things:

Who you are
What you offer
Why they should choose you

If they have to scroll, read extensively, or search for information, they have already decided to leave. Clarity is not simplicity. It is the most advanced form of communication.

A Designed User Journey, Not an Improvised One

Every page must have a precise purpose and a clear direction:

Homepage leads to services
Services lead to contact
Contact leads to consultation

If this journey is not designed, traffic disperses without converting.

Why Most Websites Fail on All 4 Points

Not because of lack of budget. Not because of lack of goodwill. But because the market is full of quick solutions, pre-packaged templates, and agencies that measure success by the number of pages delivered, not results generated.

A website is not a finished product. It is a living system that requires analysis, continuous optimization, and constant alignment between business objectives and user behavior. Small businesses deserve digital tools that match the quality of their products and services.

Where We Are

Sabriel Agency operates from Ugento, Salento, Italy, working with businesses across the country that want a digital presence built to last and to convert.

For a free consultation:

📍 Via Sant'Antonio 68, 73059 Ugento (LE), Italy

📞 +39 344 536 0025
📧 supporto@sabrielagency.com
📧 agenziasabriel@gmail.com
🌐 https://sabrielagency.com