Posts tagged: WordPress

Speed up your WordPress website and you fix two problems at once — Google ranks you higher, and visitors actually stay long enough to become customers. Ignore it and you’re bleeding traffic from both ends.

I’ve worked on WordPress sites for restaurants in Denmark, tourism businesses in Aruba, nonprofits in the US, and e-commerce stores in the UK. Every single one of them had speed problems when they first came to me. Not because WordPress is slow — WordPress itself is fine. The problems were almost always the same three things: bad hosting, unoptimised images, and a bloated page builder doing ten times more work than necessary.

This guide covers what I actually fix on client sites, in the order I fix it. Not a generic checklist of 23 things you’ll never do. Real fixes, real order of priority, real results.

Why Your WordPress Site Is Slow (The Actual Reasons)

Before you install any plugin or change any setting, you need to know what’s making your site slow. Guessing wastes time. A free speed test takes two minutes.

Open Google PageSpeed Insights and run your homepage URL. Do it in a new incognito window so browser cache doesn’t skew the results. You’ll get two scores — mobile and desktop — and a list of specific issues ranked by their impact.

Most WordPress sites I audit fail on mobile. Desktop scores look acceptable, sometimes even good. But mobile is what Google uses to rank your site. If your mobile score is below 50, your rankings are being actively suppressed.

The most common issues I see in PageSpeed reports:

Largest Contentful Paint (LCP) too slow — usually caused by a large unoptimised hero image loading above the fold. The browser has to download a 3MB JPEG before it can show the page.

Cumulative Layout Shift (CLS) too high — elements jumping around as the page loads. Usually caused by images without defined dimensions, web fonts loading late, or ad slots appearing after content.

Interaction to Next Paint (INP) failing — the page is technically loaded but feels sluggish to interact with. Almost always JavaScript bloat — too many scripts running on page load from plugins that don’t need to load everywhere.

Fix these three and you fix your Core Web Vitals. Fix your Core Web Vitals and your Google rankings improve. It’s that direct.

Fix 1 — Your Hosting Is Probably the Root Cause

I’ll say this directly: cheap shared hosting is a performance ceiling you cannot overcome with plugins.

You can install WP Rocket, optimise every image, minify every script, and your site will still load slowly if your server response time (TTFB — Time to First Byte) is above 600ms. No frontend optimisation fixes a slow server. It’s like trying to make a slow car faster by changing the tyres.

For small to medium WordPress sites in 2026, Hostinger Business or Hostinger Cloud handles most needs at a reasonable price. For high-traffic or e-commerce sites, Cloudways on a DigitalOcean or Linode server is what I recommend. Cloudways gives you server-level caching with Redis and Varnish, which is a completely different performance tier from shared hosting.

The test is simple. Run your site through WebPageTest and look at the TTFB number. Under 200ms is good. 200–600ms is acceptable but improvable. Above 600ms — fix your hosting before doing anything else, because nothing else will matter.

✅ Pro Tip: If you’re on Hostinger, enable LiteSpeed Cache from the Hostinger dashboard before installing any other caching plugin. Hostinger’s servers run LiteSpeed and the native integration is significantly faster than generic caching plugins on the same server.

Fix 2 — Images Are Destroying Your Load Time

Images are the single biggest contributor to slow WordPress sites. Not plugins, not themes — images. I’ve seen restaurant sites with 8MB hero images and tourism sites with 40 photos uploaded straight from a phone camera at full resolution.

In 2026 there is no reason to serve JPEG or PNG for photographs on a WordPress site. The correct format is WebP. WebP files are 25–35% smaller than JPEG at the same visual quality and are supported by every modern browser.

The even better option is AVIF — roughly 50% smaller than JPEG and browser support is now above 95%. If your image optimisation plugin supports AVIF, use it with a JPEG fallback.

For automatic conversion and compression, I use ShortPixel on most client sites. It gives the best file-size-to-quality ratio of any image plugin I’ve tested, supports both WebP and AVIF, and pay-per-image pricing makes it cost-effective for sites that aren’t uploading hundreds of images per month.

Beyond format, two other image rules matter:

Set explicit width and height attributes on every image. This prevents layout shift (CLS) and tells the browser how much space to reserve before the image loads.

Use lazy loading on everything below the fold. WordPress enables this by default since version 5.5, but check that your theme or page builder isn’t overriding it.

⚠️ Watch Out: Never lazy load your hero image — the large image at the top of the page that’s visible immediately on load. Lazy loading delays images that are off-screen. Your hero image is on-screen. Lazy loading it actually hurts your LCP score. In Elementor, set the hero image widget’s loading attribute to “eager” to prevent this.

Fix 3 — Caching: What to Install and What to Skip

Caching plugins store a static HTML version of your pages so WordPress doesn’t have to rebuild them from scratch every time someone visits. It’s one of the highest-impact changes you can make.

The right caching plugin depends entirely on your hosting:

On Hostinger — use LiteSpeed Cache. It’s free and integrates natively with the server. Enable page cache, browser cache, CSS/JS minification, and lazy load from its settings. Don’t install WP Rocket on top of it — two caching plugins conflict and create problems.

On Cloudways — use Breeze (Cloudways’ own plugin). It’s designed specifically for their server stack and works better than third-party alternatives on their infrastructure.

On any other shared hosting — WP Rocket is the most reliable all-in-one option. It handles caching, file minification, lazy loading, and database cleanup in one plugin with a clean interface that doesn’t require technical knowledge to configure.

After installing and configuring your caching plugin, run PageSpeed Insights again. A well-configured cache should improve your performance score noticeably, sometimes by 15–25 points on its own.

✅ Pro Tip: After any significant site change — new page, new plugin, updated content — clear your cache. Visitors can see outdated versions of pages if cache isn’t cleared. Every major caching plugin has a “Clear All Cache” button in the WordPress admin toolbar. Use it after every update.

Fix 4 — Elementor Is Probably the Slowest Thing on Your Site

I use Elementor on client sites. It’s a powerful page builder and most clients love the flexibility. But I’ll be direct — Elementor is one of the heaviest page builders available in terms of what it loads on every page.

By default, Elementor loads its CSS and JavaScript on every single page of your site, even pages that have nothing built with Elementor. It also generates inline CSS for every widget which adds page weight.

Here’s how I reduce Elementor’s impact without removing it:

Go to Elementor → Settings → Advanced → Enable “Improved CSS Loading.” This loads widget CSS only when that widget is actually used on the page rather than loading all widget styles globally.

Enable “Improved Asset Loading” in the same menu. This reduces the number of JavaScript files Elementor loads.

Disable the Elementor font awesome library if you’re using a theme that already loads it. Duplicate icon libraries loading twice is a common culprit for script bloat.

Use the Elementor Image widget’s native lazy loading option rather than relying on a plugin to add it.

None of these fixes make Elementor as fast as a lightweight theme with no page builder. But they close the gap significantly. After making these changes on a restaurant client site, the mobile PageSpeed score went from 41 to 67 — without changing hosting or images.

Fix 5 — Minify CSS and JavaScript (But Test After)

Minification removes unnecessary characters — spaces, line breaks, comments — from your CSS and JavaScript files. It reduces file size and speeds up delivery. Every caching plugin mentioned above handles this automatically.

The thing nobody tells you is that aggressive minification breaks things. JavaScript minification in particular can conflict with how some plugins and themes load their scripts, causing visual or functional errors on the front end.

My approach: enable CSS minification first, test the site thoroughly. Then enable JavaScript minification, test again. Never enable both at once without testing. Check every page type — homepage, single post, shop page, checkout — because different pages load different scripts.

If anything breaks after enabling JS minification, look for the “exclude” option in your caching plugin settings. You can exclude specific scripts from minification while minifying everything else.

⚠️ Watch Out: Never enable JavaScript deferral or delay on pages with inline scripts that need to run on page load — payment gateways, booking widgets like FareHarbor, and map embeds are common casualties. A broken checkout or booking flow is a far bigger problem than a slightly lower PageSpeed score.

Fix 6 — Use a CDN for Static Assets

A Content Delivery Network (CDN) serves your images, CSS, and JavaScript files from servers geographically close to each visitor. If your site is hosted in Europe and someone visits from the US, without a CDN they’re waiting for files to travel across the Atlantic. With a CDN, those files come from a server in the US.

For most WordPress sites, Cloudflare’s free tier is the right starting point. It’s easy to set up, improves load times for international visitors, and adds a basic layer of security as a bonus.

If you’re on Hostinger Business or above, Cloudflare CDN integration is available directly from the Hostinger dashboard. Enable it there rather than setting it up separately — it’s preconfigured for their infrastructure.

After enabling a CDN, check your PageSpeed score again. The improvement is most noticeable for visitors who are geographically distant from your server.

How to Know If Your Fixes Are Actually Working

Speed optimisation without measurement is guesswork. After every change, run these three tools:

Google PageSpeed Insights — the most important one since it directly reflects how Google scores your site. Aim for 90+ on desktop and 70+ on mobile as your initial targets.

GTmetrix — gives you waterfall view showing exactly which files are taking longest to load. Useful for identifying specific problem scripts or images that PageSpeed Insights doesn’t pinpoint clearly.

WebPageTest — shows your TTFB clearly and lets you test from different geographic locations. Use this to verify your CDN is working and your server response time is acceptable.

Run each test three times and average the results. Speed scores fluctuate based on server load at the time of testing. One bad result doesn’t mean your site is broken and one good result doesn’t mean your work is done.

Common WordPress Speed Mistakes I See Constantly

Installing multiple caching plugins. They conflict. Pick one and use only that one.

Using full-size images in thumbnails. WordPress generates thumbnail sizes automatically but only if images are properly registered. If your theme or page builder is displaying your 2400px hero image at 400px wide, the browser is still downloading 2400px of image.

Leaving hello-world post and unused demo content indexed. Extra pages Google crawls for zero benefit. Delete them.

Installing plugins for every small feature. Every plugin adds code that loads on every page. A contact form, a social share widget, a cookie notice, a popup, a chat widget — individually fine, collectively they add seconds to your load time. Audit your plugins and remove anything that isn’t actively earning its place.

Not testing on actual mobile. Desktop PageSpeed scores and mobile PageSpeed scores are completely different. Most clients only ever test on desktop. Check your site on a real phone on a real mobile network before calling a project done.

FAQ

What PageSpeed score should I aim for in 2026?
Target 90+ on desktop and 70+ on mobile as your baseline. Google’s ranking algorithm weighs mobile score heavily. A desktop score of 95 with a mobile score of 45 means your SEO is still being penalised.

Is WP Rocket worth paying for?
For non-LiteSpeed hosting, yes. It’s the most reliable all-in-one caching and optimisation plugin available. The configuration is straightforward, it works well with most themes and plugins, and the support is good. On LiteSpeed servers, use LiteSpeed Cache instead — it’s free and performs better on that infrastructure.

Will a caching plugin break my WooCommerce store?
It can if configured incorrectly. Cart pages, checkout pages, and account pages must be excluded from caching — every major plugin does this automatically when it detects WooCommerce, but always verify. A cached checkout page where all customers see the same cart content is a serious problem.

Does image optimisation affect visual quality?
With modern formats like WebP and AVIF at 80–85% quality settings, the difference is invisible to the human eye at normal viewing sizes. The files are dramatically smaller. I’ve never had a client notice a quality difference after converting to WebP.

How often should I check my site speed?
After every significant change — new plugin, updated theme, new page template. Set a reminder to run a full PageSpeed check monthly even if nothing has changed. Server environments change, plugin updates add new scripts, and speed regressions creep in silently over time.

Can I speed up WordPress without any paid plugins?
Yes. LiteSpeed Cache is free and powerful on compatible hosting. ShortPixel has a free tier. Cloudflare CDN has a free tier. The honest answer is that combining free tools gets you 80% of the way there. Paid tools like WP Rocket make the process faster and more reliable but aren’t strictly necessary if you’re willing to configure free alternatives carefully.

Final Thoughts

Speeding up a WordPress website is not complicated — but it is sequential. Fix the hosting first. Then the images. Then the caching. Then the page builder settings. Then the minification. Each step builds on the last.

Most slow WordPress sites I encounter aren’t slow because WordPress is bad. They’re slow because they were built quickly, without performance in mind, on the cheapest hosting available, with whatever theme looked nice in the preview. That’s a solvable problem. And the impact of solving it — on rankings, on bounce rate, on conversions — is immediate and measurable.

If you want an expert to audit and optimise your WordPress site’s speed, get in touch at https://syedaounraza.online/contact/

How to Add FareHarbor to WordPress (And Not Lose Your Commission Like I Did)

I almost cost my client real money on their first month of bookings. Not because the integration broke. Not because the plugin had a bug. Because I forgot to set the ASN.

If you don’t know what that means yet — you will by the end of this guide. And you won’t make the same mistake I did.

I’ve built FareHarbor WordPress sites for three tourism brands in Aruba: Pelican Adventures, De Palm Tours, and Kukoo Kunuku. Each one is a separate WordPress site, each targeting a different audience, each with its own booking flow. I’ve gone through the plugin setup, the shortcode configuration, the multi-brand partner pages, and yes — the moment where commissions weren’t tracking and I had to figure out why.

This guide is everything I learned doing it for real clients, not just reading the docs.

What Is FareHarbor and Why Tourism Sites Need It on WordPress

FareHarbor is the booking system that most serious tour and activity operators use. It handles availability, payments, customer communications, and operator commissions all in one place. If your client runs boat tours, island excursions, or any kind of ticketed experience — they’re probably already on FareHarbor or about to be.

WordPress is where most of these businesses want their public-facing site. So connecting the two is one of the most common requests I get from tourism clients.

The good news: FareHarbor has an official WordPress plugin. The bad news: the plugin documentation tells you the minimum, not the reality. There are decisions you need to make before you even install it — and if you skip them, you’ll spend hours debugging something that should have taken 20 minutes.

Let me walk you through the whole thing.

Step 1: Start With the Client’s Goal, Not the Plugin

Most developers jump straight to installing the FareHarbor plugin. I used to do this too. Now the first thing I do is ask the client one question: what are you actually trying to achieve with this integration?

That question changes everything.

Some clients want a simple “Book Now” button on their homepage. Others want a full availability calendar embedded on each tour page. Some are resellers who earn commission on other operators’ bookings — and that requires a completely different setup than a direct operator.

If you skip this conversation, you’ll build the wrong thing. I’ve seen developers embed a full calendar when the client just needed a lightframe button. I’ve seen reseller sites set up without affiliate tracking, meaning every booking they drove earned them nothing.

Know the goal first. Then choose your integration method.

Step 2: Install the FareHarbor WordPress Plugin

Once you know what you’re building, installation is straightforward.

Go to your WordPress dashboard, navigate to Plugins → Add New, and search for “FareHarbor.” Install and activate the official plugin by FareHarbor. As of 2026 it’s at version 3.6.13 with over 9,000 active installs, so it’s well maintained.

After activation, go to Settings → FareHarbor. You’ll see a settings page with a few options. The two that matter most:

Default Shortname — set this to your client’s FareHarbor shortname (more on this below). If you’re only building for one operator, set it here and you won’t need to type it in every shortcode.

Enable Auto Lightframing — check this box. Always. It means any link on the site that points to a FareHarbor booking URL will automatically open in the Lightframe overlay instead of taking the user away from your site. It’s a conversion improvement with zero downsides.

Enable FH Buttons Stylesheet — check this too if your client wants styled booking buttons. It loads FareHarbor’s button CSS so you can use their pre-built button styles.

What Is a Shortname and Why It Almost Broke My Project

Here’s the thing nobody explains clearly in the docs.

Every FareHarbor operator has a shortname. It’s the unique identifier for their account — the bit that appears in their FareHarbor dashboard URLs. For Pelican Adventures it was pelican-aruba. For De Palm Tours it was depalmtours. For Kukoo Kunuku it was kukookunuku-au.

You get this from the client or directly from their FareHarbor account. You cannot guess it. You cannot derive it from their business name. You need the exact string.

This is important because every shortcode you write uses it. Get it wrong and nothing loads. Get it right but forget the ASN — and you’ll lose commission tracking entirely.

I’ll explain the ASN issue in a moment. First, let me show you the shortcodes.

Step 3: The Four Shortcodes You Actually Need

The FareHarbor plugin gives you four shortcodes. Here’s when to use each one.

[fareharbor shortname=”companyname”] — This embeds a full availability calendar directly on the page. Use it on dedicated tour pages where you want visitors to see all available dates and book without leaving. It’s immersive but heavy — don’t put it on your homepage.

[itemgrid shortname=”companyname”] — This creates a grid of all activities or a specific flow. Use it on category pages where you want to show multiple tours at once. It looks clean, loads faster than the full calendar, and works well as a browsing interface before the customer picks a specific tour.

[lightframe shortname=”companyname”]Book Now[/lightframe] — This wraps any text or button to open the FareHarbor booking overlay on click. Use it for CTAs anywhere on the site — hero sections, tour description pages, sidebar widgets. This is the most flexible shortcode and the one you’ll use most.

[partners shortname=”companyname” include=”brand1,brand2″] — This is for reseller sites that want to show multiple operators’ inventory together. I didn’t use this for the Aruba project because each brand had its own separate WordPress site. But if you’re building a single site that aggregates multiple operators — a tourism hub, for example — this is what you need.

Step 4: The ASN — The Thing That Cost My Client Commission

This is the part I wish someone had told me before I launched.

If your client is a reseller — meaning they earn a commission when they drive bookings to another operator — FareHarbor tracks this through something called an ASN (Affiliate Short Name). Think of it as a tracking identifier that tells FareHarbor “this booking came through this reseller’s site.”

Without the ASN set correctly, FareHarbor has no way of attributing the booking to your client. The booking still happens. The customer still pays. But your client earns nothing from it.

For the Aruba project, the ASN for the account was toptiervacationrental. Every shortcode on every partner brand site needed to include this. And in my first build, I forgot to add it.

The first month went live. Bookings were happening. But when the client checked their FareHarbor dashboard, the commission column was empty.

It took me an hour of digging through the FareHarbor documentation to realize what was missing. The fix was a single parameter added to every shortcode. But the damage was real — a month of bookings with no commission tracked.

The correct shortcode format for a reseller looks like this:

[lightframe shortname=”pelican-aruba” asn=”toptiervacationrental”]Book Pelican Adventures[/lightframe]

[itemgrid shortname=”depalmtours” asn=”toptiervacationrental”]

That asn parameter is what creates the commission trail. Add it to every single shortcode on every page. Don’t leave it out on “just the homepage” or “just this one page.” Every shortcode needs it.

PRO TIP: Set the ASN as a default in the FareHarbor plugin settings page if your entire site is running under one reseller account. That way it applies automatically to every shortcode without typing it each time.

WATCH OUT: The ASN is case-sensitive. toptiervacationrental is not the same as TopTierVacationRental. Get the exact string from the FareHarbor account, copy it, paste it — don’t type it manually.

Step 5: Building Separate Pages Per Brand

For the three Aruba brands I mentioned — Pelican Adventures, De Palm Tours, and Kukoo Kunuku — we built separate WordPress sites rather than one multi-brand site. Each operator had their own domain, their own branding, and their own booking pages.

This approach has real advantages. Each site can be SEO-optimized for that specific brand’s search terms. There’s no confusion for the customer about whose tours they’re booking. And each site can have its own design that matches the brand’s identity.

The structure I use for these sites is simple and repeatable:

Homepage — hero section with a [lightframe] Book Now CTA, brief brand intro, featured tours using [itemgrid].

Individual tour pages — one page per tour, with description, photos, FAQs, and a full [fareharbor] calendar embed for that specific item ID.

Tours overview page — [itemgrid] showing all available tours, filterable by category if the operator has flows set up in FareHarbor.

This structure works. It converts. And it’s easy to hand off to the client to manage without them breaking anything.

Common Mistakes I See Other Developers Make

Beyond the ASN issue, here are the other things I’ve seen go wrong on FareHarbor WordPress builds.

Not enabling Auto Lightframing. When this is off, clicking a FareHarbor link takes the user completely away from the WordPress site to FareHarbor’s own booking page. You lose the branded experience and the customer feels like they’ve left the site. Always enable it.

Embedding the full calendar on the homepage. The [fareharbor] calendar shortcode is heavy. It loads a full iframe with date pickers and availability data. On a homepage it slows the page down and overwhelms visitors who are still deciding whether to book. Use [itemgrid] or a [lightframe] button on the homepage instead.

Not testing on mobile. FareHarbor’s Lightframe overlay works fine on desktop. On mobile, especially older Android browsers, there can be scroll issues inside the overlay. Always test the full booking flow on an actual phone before handing the site to the client.

Using the wrong item ID. When embedding a specific tour’s calendar using [fareharbor item=”12345″], you need the item ID from FareHarbor’s dashboard — not a guess. Pull it from the URL of the item in the operator’s FareHarbor account.

FAQ

How do I find my FareHarbor shortname?
Log into the FareHarbor dashboard and look at the URL — it usually contains the shortname. Or ask your FareHarbor account manager directly. Don’t guess it.

Can I use FareHarbor on WordPress without the plugin?
Yes — you can embed the Lightframe API script manually and use raw HTML links. But the plugin makes it cleaner, handles Auto Lightframing automatically, and is the approach FareHarbor officially supports. Use the plugin.

Does FareHarbor work with Elementor?
Yes. The shortcodes work inside Elementor’s Text Editor or Shortcode widgets. The [lightframe] shortcode wrapping an Elementor button needs a bit more work — you’ll need to add the shortcode around the button’s text content, not the button widget itself.

What if my client is not a reseller — do I still need the ASN?
No. The ASN is only relevant for reseller/affiliate setups where commission tracking is required. If your client is a direct operator taking their own bookings, skip the ASN entirely.

Can I show multiple operators on one WordPress site?
Yes — use the [partners] shortcode with the include parameter listing each operator’s shortname. This is the right approach for tourism hub sites or aggregators rather than building separate sites per brand.

How do I test if commission tracking is working?
Make a test booking through the site and check the FareHarbor dashboard for that booking. Look for the referral source — it should show your ASN. FareHarbor support can also verify this on their end if you’re unsure.

Final Thoughts

FareHarbor is a solid booking system and the WordPress plugin works well once you understand what it’s actually doing. The documentation covers the basics. What it doesn’t cover is the real-world decisions — the ASN, the per-brand site structure, the difference between embedding a calendar and using a lightframe button.

I learned most of what’s in this guide by building real sites for real clients in Aruba. Some of it came easy. Some of it — like the missing ASN — came with consequences.

If you’re a developer taking on a FareHarbor WordPress project, save this guide. And if you’re a tourism business trying to figure out whether you need a developer or can do this yourself — feel free to reach out. I’ve built these setups from scratch and know exactly what your site needs.

Get in touch at https://syedaounraza.online/contact/