JUX Preloader - Joomla Extension

Guide to Setting Up JUX Preloader for a Joomla Site

JUX Preloader is best treated not as decorative animation, but as a Joomla system plugin that controls a visitor's first visual contact with the page. In this guide, we will look at where it is actually useful, how to prepare the site before installation, which settings to verify after enabling it, how to align the loading screen with your template design, and how to make sure the preloader does not get in the way of speed, indexing, or usability.

This guide is written for site owners, webmasters, Joomla administrators, and developers who already have the extension as an installation package and want to deploy it safely on a live site. It does not cover buying the product or activating access. The focus here is strictly on features, setup, verification, and troubleshooting for an extension you already have.

What makes JUX Preloader different is that it runs at the system plugin level. That type of extension can affect every page, so the setup process should be calm and testable: first a staging environment, then careful activation, then checks on the public-facing site, followed by cache review, mobile testing, and conflict checks against the template.

Throughout the guide, we will refer to planned visual diagrams. These are not actual interface screenshots, but instructional graphics based on official pages, documentation, and standard Joomla admin logic. They are meant to make the path from "setting - action - result" easier to understand.

What problem a preloader solves and where it actually makes sense

A preloader shows visitors a temporary loading screen while the page is still assembling its visual output. Official sources for JUX Preloader confirm the basic logic: the plugin displays a styled animation while content is loading, lets you choose the preloader style, background color, spinner color and size, and also add a logo. That is a fairly narrow but clear feature set. Its job is not to make the site physically faster, but to make waiting feel less abrupt and visually connect the loading state to your brand.

It is important not to confuse the purpose. A preloader does not replace image optimization, caching, script reduction, or proper hosting configuration. If the site loads slowly because of a heavy template, too many extensions, or oversized images, the animation only hides part of the wait. Users will still feel the delay if the loading screen stays up too long or appears on every transition for no good reason.

A good use case for JUX Preloader is a visually rich site where the first render can look messy: a portfolio with large images, an agency landing page, an event promo page, a site with a heavy hero section, or a catalog with large banners. In cases like these, a short preloader can help prevent the impression that the page is "jumping" while fonts, images, and sections finish loading.

A poor use case is a lightweight informational site where pages already open quickly. There, a loading screen can become annoying because it adds an extra layer between the click and the content. Another questionable case is a site with frequent fast transitions: the user clicks a menu item, sees the preloader, clicks again, and waits again. If the wait shows up more often than it helps, the extension is better disabled or configured as gently as possible.

What the user should see

On a properly configured site, the visitor should see not a "blank white screen" but a brief loading state: a background in the site's color palette, an appropriately sized spinner, and a logo if needed. Once loading is complete, the preloader disappears and the page remains interactive. If the screen disappears but the content keeps shifting around for a long time, the issue is not the preloader but the actual loading speed and resource order.

What expectations should be limited from the start

JUX Preloader is useful for perception, but it should not become an excuse for a slow site. That is why this guide includes not just color settings, but also sections on validating the result, cache behavior, mobile devices, and troubleshooting. For a system plugin, those things matter more than simply choosing a nice animation.

Who JUX Preloader is a good fit for, and who should choose another approach

This extension is a good fit for people who want to add a controlled loading screen quickly without building JavaScript and CSS from scratch. According to the documentation, the setup is centered on plugin parameters: style, background, color, size, and logo. That is convenient for an administrator who does not want to edit the template but still wants a predictable visual result.

JUX Preloader is especially suitable for small teams and agencies managing Joomla sites for clients. In that scenario, it matters that the setup can be explained and repeated: install the package, enable the system plugin, choose a style, save, check the front end, clear the cache, and align it with the design. The less hidden code involved, the easier the site is to support after handoff.

The extension may not be the right fit if you need advanced display rules, such as showing the loading screen only for certain menu items, languages, user roles, or specific components. The official description of JUX Preloader focuses on visual customization of the preloader, not detailed targeting. If rules like that are critical, check the current documentation and the interface of your installed plugin ahead of time. Do not assume a feature exists unless it is confirmed by reliable sources.

You should also be careful on sites where instant actions matter: user dashboards, checkout flows, lead forms, login pages, or admin-facing workflows for editors. The preloader should not cover a form after the user is already able to interact with the page. If there is any delay in those areas, it is better to disable the effect or choose an alternative with more precise display rules.

The main practical rule is simple: if the preloader makes the wait easier to understand and disappears quickly, it helps. If it masks the problem and annoys users on every page transition, it needs to be adjusted or disabled.

What to check before installing it on Joomla

Before installing a system plugin, do not take the "upload the ZIP and enable it immediately" approach. JUX Preloader belongs to the type of extensions that can appear globally on the public-facing site. That means preparation should include a backup, a test page, a compatibility check, and a rollback plan.

The official Joomlaux documentation points to the standard Joomla admin installation path through the extension upload screen. It also lists server requirements and client-side conditions, including active JavaScript and browser cookie support. Some of those requirements look like general Joomlaux documentation boilerplate, so it is better to record exact values in sources.txt and verify them against the current documentation page instead of turning them into hard promises in the article.

Minimum admin preparation

Before installation, do the practical minimum:

• Create a fresh backup of both files and database, or confirm that your hosting provider has already created a restorable backup.
• Make sure you have access to the Joomla admin panel and the hosting control panel in case you need to disable the plugin manually.
• Confirm that your installed Joomla version is compatible with the current extension listing in JED or on the developer's site.
• Check whether aggressive JavaScript optimization modes are enabled, especially those that combine, defer, or relocate scripts.
• Pick one public page for the first test: the homepage, an article page, or a page with a heavy visual block.

If the site already uses a complex template, page builder, scroll-triggered animations, lazy-loaded images, and system cache, it is especially important to enable JUX Preloader on a staging copy first. A preloader affects the page-loading moment, and that is exactly where conflicts between scripts, fonts, cache, and template animation often show up.

What to inspect in the extension package

The Joomlaux documentation describes the downloaded package as an archive that should be unpacked so you can find the installation folder containing the plugin file. For JUX Preloader, the documentation names the file juxpreloader.zip. That is an important clue: if Joomla says the archive format is invalid, do not blindly upload everything you downloaded. First check whether the actual installable ZIP is nested inside the main archive.

Safe approach: if the installation fails, do not keep uploading random files one after another. Check the package structure, the documentation, and the Joomla error message. A common installation failure is uploading the general archive instead of the internal installable ZIP.

Why you need a rollback plan

Joomla system plugins load early and can affect the public-facing site. Joomla's official developer documentation specifically warns that an error in a system plugin can make the admin panel harder to access. JUX Preloader should not be treated as dangerous by default, but the extension type requires caution. A rollback plan is simple: know where the plugin list is, how to disable the extension from the admin panel, how to clear the cache, and where to turn if the site shows a white screen or hangs during loading.

Installation and initial activation without unnecessary risk

Installing JUX Preloader uses Joomla's standard mechanism. In current interfaces, the exact path may be labeled a little differently depending on the version and admin language, but the general idea is the same: open the extension installation area, choose package upload, provide the ZIP file, and wait for the successful installation message.

Step-by-step installation

1. Open the Joomla admin panel using an account with permission to install extensions.
2. Go to the extension installation area through System and the installer screen if your Joomla interface uses the modern menu structure.
3. Select the package upload tab, usually labeled Upload Package File.
4. Upload the plugin's installable archive listed in the documentation, not the general archive containing all materials.
5. Wait for Joomla to display the successful installation message.
6. Go to the plugin list and find the JUX Preloader system plugin.
7. Open the plugin settings, but do not start with complex visual options before the first simple test.

After installation, the plugin may still not work until it is published. That is normal Joomla behavior: many plugins and modules must be enabled separately. So do not conclude that "the extension does not work" until you have checked its publication status in the plugin manager.

Initial validation after enabling

For the first test, choose the simplest configuration: one preloader style, a neutral background, a visible spinner color, and no logo or only a small one. Save the settings, clear the Joomla cache and browser cache, then open a public page in a separate window or private mode.

Do not just check whether the animation appears. You need to verify the full cycle:

• The preloader appears while the page is loading.
• The animation does not continue covering the content once the page is ready.
• The page remains clickable after the loading screen disappears.
• The browser console shows no obvious JavaScript errors related to the loader or the template.
• After disabling the plugin, the site returns to its previous behavior.

The short conclusion for this stage is straightforward: installation is only successful not when Joomla shows a green message, but when the public page opens, the loading screen disappears, and the user can interact with the content normally.

Configuring style, background, spinner color, and spinner size

JUX Preloader is configured through a small set of visual parameters. The official documentation lists preloader style selection, background color, spinner color, spinner size, and logo support. These are the settings worth explaining in more depth because they determine whether the loading screen feels like part of the site or like a random animation dropped on top of the template.

Choosing a preloader style

The Joomlaux documentation says the plugin supports multiple styles for the front end. In one part of the documentation it mentions eight styles, but the text also includes a strange phrase about Grid or Slide layout that looks like leftover copy from another product. Because of that, it is better not to build instructions around "grid" and "slide," and instead focus on the confirmed meaning: the user chooses a preloader style that will be shown on the site.

For a typical business site, it is best to start with a simple spinner. A more elaborate animation may look impressive on a promo page, but on a standard site it quickly turns into visual noise. The more often the user moves between pages, the calmer the style should be.

Practical selection rule

If the site has a formal look, use a minimal spinner and a restrained background. If the site is highly visual, such as a portfolio, restaurant, event page, or creative agency site, a more expressive animation can work. If the site sells services or focuses on lead generation, avoid long or flashy effects because they distract from the user's main action.

Loading screen background

Background Color should support the template palette. The most common mistake is setting a bright background that clashes sharply with the site. The visitor sees one color while loading and another color when the page appears, and the transition feels rough. A better choice is the primary brand color, a lighter background tone, or a contrasting dark background if the site itself uses a dark visual system.

Check the background on pages with different above-the-fold layouts. For example, the homepage may have a dark hero image while the blog uses a light content area. If the same preloader color looks natural in both places, the setting is working. If the loading screen feels out of place, choose a more neutral value.

Spinner color and size

Spinner Color should stand out against the background. Do not pick similar shades, or the user will see what looks like an empty screen. Spinner Size should be chosen with the mobile view in mind: a spinner that is too large looks clumsy on a phone, while one that is too small gets lost on a large monitor.

For the initial setup, use a medium size. Then test the front end at different widths: desktop, tablet-sized, and narrow mobile screens. The documentation and JED indicate that the extension is designed with responsiveness in mind, but that does not remove the need for real testing inside your own template. Plugin responsiveness and site-specific responsiveness are not the same thing.

After changing each visual parameter, clear the cache and check the result again. If you change everything at once, it becomes hard to tell which setting caused the problem or created the visual imbalance.

Logo on the loading screen: when it strengthens the brand and when it gets in the way

One of JUX Preloader's confirmed features is the ability to show a logo on the preloader. That is useful when the loading screen becomes part of a branded experience: the user sees a familiar mark and then lands on a site that uses the same visual language. But a logo is easy to get wrong if you upload a file that is too large, use an image without transparency, or place it next to an active animation with no real composition.

When to enable the logo

A logo makes sense if the site promotes a brand, studio, product, event, or company where recognition matters more than a neutral loading state. It is also useful on sites with a dark background and a minimal spinner: the mark helps users understand they are on the right site rather than looking at a generic technical placeholder.

Do not enable the logo just because the field exists in the settings. On an informational site or inside a user dashboard, it can make the first screen feel heavier. On mobile, a large logo can start to feel like an ad splash screen, especially if the animation lasts more than a brief moment.

How to prepare the file

It is best to use a clean mark or a horizontal logo without a small tagline. If the logo includes fine text, it will be hard to read at a small size. Check the contrast against the background, make sure transparency is correct, remove unnecessary empty space around the image, and verify how it behaves at mobile widths.

• Use a file that already looks good on the site's background.
• Do not upload a heavy image for such a small loading-screen element.
• Make sure the logo does not overlap the spinner or look like a positioning error.
• Compare the version with the logo and the version without it on the same page.

How to verify the result

Open the page in a private window, then refresh it several times while clearing the cache. The logo should appear without a hard jump, should not stretch or compress, and should not remain on the page after the preloader disappears. If the image loads later than the spinner itself, reduce the file size or temporarily disable the logo.

Useful rule of thumb: the logo on a preloader should be secondary. If the user remembers the splash screen more strongly than the page content itself, the setup has become too intrusive.

How the system plugin affects the template, cache, and page loading

JUX Preloader is a system plugin. In Joomla, that means the extension does not run like a standalone module in a template position, but as part of the page-processing flow. Because of that, the configuration is tied not only to appearance, but also to loading order, cache behavior, template scripts, and browser behavior.

Why cache can make validation confusing

Joomla supports multiple caching layers: page cache, view cache, module cache, and global cache settings. If you change a color or style in JUX Preloader but still see the old version, the reason may not be the plugin itself. The page may be coming from cache, the browser may still hold old CSS, or an optimizer may not have rebuilt a combined file yet.

After every important change, clear the Joomla cache, the cache of any third-party optimizer if one is in use, and the browser cache. On a live site, do this carefully so you do not create a sudden spike in load. For validation, use one page and one browser mode, otherwise it becomes easy to misread the result.

Conflicts with template scripts and animations

The preloader operates right at the boundary between "the page is still loading" and "the content is already ready." At that same moment, other mechanisms are often active too: block entrance animations, lazy-loaded images, fonts, sliders, galleries, and page builder scripts. If multiple extensions try to control the first screen, symptoms can appear: the preloader does not disappear, the background remains on top of the page, elements start jumping, or the console shows errors.

Troubleshooting should be sequential. First disable JavaScript optimization, if any is enabled. Then test the page with a basic preloader style and no logo. After that, turn settings back on one by one. That approach is faster than changing ten settings at once and guessing what actually broke the page.

How not to hurt perceived speed

A preloader can make waiting feel smoother, but it can also make the site feel slower if the screen stays up longer than the content actually needs. On fast pages, it may be perceived as an artificial delay. So after setup, evaluate the page from the user's point of view: how long it takes from click to first useful content, whether it is immediately clear that the site is alive, and whether the preloader is covering a page that is already ready.

If the site is SEO-sensitive, do not rely only on subjective impression. Run the page through your usual performance tools, but interpret the result carefully: the preloader itself should not become the reason for heavy resources. If enabling it increases the number of blocking scripts or errors, go back to the settings and check for conflicts with optimization.

Practical scenario: a clean preloader for a portfolio or agency site

Let us look at a concrete example. Suppose you have a Joomla agency site or portfolio with large homepage images. On the first visit, fonts and images do not load at the same time, so the first screen looks rough for a moment. The goal is to add a short preloader that smooths out that moment without turning every page load into a splash screen.

Goal

Create a loading screen in the site's color palette: a calm background, a contrasting spinner, a small logo, and disappearance as soon as the page is ready. The user should be able to tell the site is loading, but should not wait any longer than necessary.

Preparation

Before you begin, prepare a staging copy or at least a backup. Choose the page where the issue is most visible. Prepare a logo without unnecessary empty margins, decide which background color best matches the site design, and open the browser developer tools ahead of time so you can check for errors.

Setup steps

1. Install JUX Preloader using the standard Joomla package upload flow.
2. Open the plugin list and locate the JUX Preloader system plugin.
3. Start by enabling a simple preloader style without a logo.
4. Choose a Background Color that does not clash with the site's first visible section.
5. Select a contrasting Spinner Color so the animation is clearly visible on the chosen background.
6. Set a medium Spinner Size and save the settings.
7. Clear the Joomla cache and open the selected page in a private window.
8. If the basic version works, enable the logo and repeat the validation.

Expected result

When the page opens, a clean loading screen appears. It disappears when the page is ready, leaves no semi-transparent layer behind, does not break scrolling, does not cover the menu, and does not interfere with clicks. If the user refreshes the page, the behavior stays consistent.

A common issue that gets in the way

Portfolio sites often use galleries, sliders, and block entrance animations. If the preloader disappears but images still load in with visible jumps, do not try to "fix" that by increasing the spinner size or using a brighter background. Look for the real cause in image optimization, lazy loading, caching, and template scripts. A preloader should hide a short technical transition, not a long wait caused by a poorly optimized page.

Validating the result on the public-facing site

Validation matters not only after installation, but after every noticeable change. For a system plugin, you need to make sure it works under real conditions: with cache enabled, across different pages, in different browsers, and at mobile widths. Without that, it is easy to end up with a nice-looking setup in the admin panel and a frustrating result for visitors.

Basic checklist

• Open the homepage after clearing the cache and verify the full appearance and disappearance cycle.
• Check an internal article page, because the first-screen template there may be different.
• Check a page with a form if that page matters for leads or contact requests.
• Open a page at mobile width and make sure the spinner and logo do not take up too much space.
• Disable the plugin and confirm that all questionable symptoms disappear with it.

How to test in the browser

Open the developer tools and look at the console tab. If JavaScript errors appear after enabling the preloader, record the error text in your admin notes. Then temporarily disable script combining and deferred loading if your optimizer handles those features. If the error disappears, the conflict is tied less to JUX Preloader itself and more to the script-processing order.

In the network tab, you can also check whether the preloader logo takes too long to load. If a small splash element is pulling in a heavy file, optimize the image. A visual preloader element should not become the heaviest resource in the first screen.

Validation after a template or Joomla update

After updating the template, optimizer, Joomla, or the extension itself, repeat a short test. Pay particular attention to the moment the loading screen disappears and to pages with nonstandard scripts. If the site uses multiple languages, test at least one page in each language, because menus, template positions, and module sets may differ.

A test can be considered successful when the preloader appears only as a brief transition, does not block a ready page, does not trigger console errors, and looks natural on both mobile and desktop widths.

Practical use ideas without overloading the site

JUX Preloader looks like a simple extension, but it can be used in different ways. The key is not to turn the effect on everywhere in the same way without understanding the goal. Below are several scenarios where the plugin's confirmed features provide a clear benefit: preloader style, color, size, and logo become a working visual transition tool.

Promo page or landing page

On a promo page, a preloader can support the first impression. Choose a background that is close to the hero section and a spinner in an accent color. If the logo is part of the campaign, add it, but do not make it too large. The check is simple: after the preloader disappears, the user should immediately see the main offer, not wait for the background to finish loading.

Portfolio with heavy images

For a portfolio, a preloader helps smooth out the moment when the project grid or gallery is still assembling. But do not use it to hide poor optimization. First compress images and review lazy loading, then enable JUX Preloader as a soft visual transition. If the gallery still jumps after the splash screen disappears, the real issue is in the gallery or the template.

Corporate site with branded splash screen

For a corporate site, a logo on the loading screen can make sense if the site does not open instantly because of fonts, banners, and external widgets. The setup should stay disciplined: a neutral background, a restrained spinner size, and a logo without fine text. If it lasts only briefly, that version can look professional.

Temporary redesign phase

Sometimes a preloader helps during a redesign phase when some pages are already updated while others still use the old visual structure. A unified loading screen creates a more consistent first impression. But this should be treated as a temporary solution. Once the redesign is complete, review whether the preloader is still needed or whether the site is already fast and stable enough without it.

How to test JUX Preloader on different page types

One successful test on the homepage does not mean the configuration is ready for the entire site. A Joomla site rarely consists of identical screens: the homepage may use one module set, an article page another, a form page a third, and a search or dashboard page a fourth. The preloader sits in front of all of this, so it needs to be tested as a global layer rather than a standalone decorative block.

Start with a page map. You do not need to go through hundreds of URLs. Choose one representative from each important type: homepage, standard article, form page, gallery or slider page, login page if present, and any page where the user takes an important action. That set will surface problems faster than randomly refreshing unrelated sections.

Homepage

On the homepage, large images, fonts, sliders, and promo blocks are usually most visible. The preloader often feels most natural there, but that is also where it is easiest to hide a real page-weight problem. Check two states: the first open after clearing the cache and a repeat visit. If the site is already fast on the repeat visit but the preloader still creates a noticeable pause, the setup may be too intrusive.

Articles and blog pages

On article pages, users come for the text. In that scenario, the wait should be almost invisible. If the splash screen feels as theatrical there as it does on a landing page, it may interfere with reading. Use a calmer style or disable the effect entirely if the pages open without visual jumps.

Forms, lead capture, and login

Pages with forms require special attention. The preloader should not appear after form submission in a way that causes the user to miss an error message or success confirmation. Test a sample form submission, a validation-error return, reopening the page, and button behavior. If the site uses an AJAX form, watch the browser console closely: a conflict may show up not on the first load, but after a user action.

Galleries, portfolios, and visual components

On gallery pages, a loading screen is often useful, but validation should include the moment after the preloader disappears. If the gallery reflows, images resize, or the grid jumps, the problem remains visible to the visitor. In that case, fix the gallery, image sizes, and lazy loading, and keep the preloader only as a short transition.

What to record after testing

For each page type, record three things: whether the loading screen appears, when it disappears, and whether any errors remain after it is gone. You can store that in a short admin table even if it is never published on the site. A log like this helps during future Joomla, template, or optimizer updates: you will quickly see what changed and where to look for the cause.

Also save the working set of values separately: selected style, background color, spinner color, size, and logo status. If the site starts behaving worse after another round of changes, do not go back to random settings that are only "roughly how it was before." Return to a validated configuration. For a system plugin, this small record saves time: the administrator can see which combination has already been tested and avoid repeating the same cycle of cache clearing, page reloads, and console checks.

If several people maintain the site, add one simple rule to your notes: whoever changes JUX Preloader settings must also test at least one form page and one visually heavy page afterward. That reduces the risk of a nice effect on the homepage accidentally breaking a more important user flow.

Testing takeaway: a configuration is only ready for a live site after it has been checked across different page types. If the effect looks good on the homepage but interferes with a form or dashboard, enabling it cannot be considered safe.

Limitations, accessibility, and careful improvements

Every loading screen has limitations. It covers the content, uses animation, and adds a visual layer. That means the setup should account not only for design, but also for accessibility, perceived speed, mobile behavior, and template compatibility.

Do not turn animation into a mandatory performance

The longer and brighter the animation, the faster it becomes tiresome for repeat visitors. For most sites, a short spinner is enough. If your version of JUX Preloader includes extra controls for timing or behavior, use them carefully and validate the result. If it does not, do not try to compensate with heavier animation or a larger logo.

Accessibility and motion sensitivity

Some users do not tolerate active animation well. If the site is aimed at a broad audience, choose a calm style without sharp flashes, frequent blinking, or extreme contrast. This matters even more for medical, educational, government service, corporate support, and user-dashboard sites.

If you need to respect user preferences such as reduced motion more precisely, do not invent hidden plugin settings. Check the documentation, template code, and the available classes in the browser. Without confirmed selectors, it is better to stay with safe interface settings: a calm style, moderate size, and a non-aggressive background.

Why this guide does not include a ready-made CSS snippet

For JUX Preloader, open sources do not confirm any stable CSS classes that could be safely used in a universal snippet. That is why there is no code here that says "paste this selector and everything will change." Advice like that would be weak, because it might not work in your version or could conflict with the template.

If you need a custom adjustment, take this path instead: open the developer tools, find the actual preloader classes on your site, make the change in the template's custom CSS, verify the result, and save a note for future updates. Do not edit the extension's own files or Joomla core files, because an update could overwrite those changes.

Why the preloader does not work or gets in the way of the page

JUX Preloader troubleshooting should move from simple to complex. Start with plugin status, cache, and basic settings. Then move on to conflicts with scripts, the template, the optimizer, and the logo. Do not start with reinstallation before you have checked the obvious causes.

The preloader does not appear on the site

Symptom

The plugin is installed, but there is no loading screen on the public page.

Possible causes

The plugin is not published, the wrong installation file was used, the page is being served from cache, an enabled optimizer has changed the script-loading order, or you are testing a page where the effect is too brief to notice.

What to do

• Check the plugin status in the Joomla extension list.
• Open the settings and save the basic configuration again.
• Clear the Joomla cache and browser cache.
• Test the page in a private window or a different browser.
• Temporarily disable JavaScript combining and deferred loading if you use an optimizer.

If the preloader appears after disabling optimization, configure an exception or use a gentler optimization mode. If it never appears at all, go back to the installation package and the documentation.

The loading screen appears but does not disappear

Symptom

The visitor sees the background and spinner, but the content stays covered even after the page has loaded.

Possible causes

The script responsible for hiding it did not run because of a JavaScript error, conflicts with the template, or was moved into the wrong place by an optimizer. In some cases, a heavy logo or a third-party script that delays page readiness is the cause.

What to do

• Open the browser console and review the errors.
• Disable the logo and test the basic spinner setup.
• Temporarily turn off JavaScript optimization and page cache.
• Check whether the symptom repeats on a standard page without complex widgets.

If the issue appears only on one page, look for a conflict with a specific module, gallery, slider, or form. If it happens on every page, inspect system cache behavior and script-loading order.

The colors and logo look wrong

Symptom

The background is too bright, the spinner is hard to see, the logo is stretched, or the placement looks awkward.

Possible causes

The contrast is too weak, the uploaded logo file has unnecessary empty margins, the spinner size does not fit the mobile view, or old CSS is still being served from cache.

What to do

• Go back to a neutral background and a high-contrast spinner color.
• Check the logo without a slogan and without extra empty space.
• Reduce the spinner size and test at mobile width.
• Clear the Joomla cache, browser cache, and optimizer cache.

Roll the setting back if the visual splash screen starts competing with the content. A preloader should be a short transition, not the main feature of the site.

After enabling it, the site feels slower

Symptom

The page technically loads, but the user waits longer before getting access to the content.

Possible causes

The preloader appears even where the page is already ready quickly; the logo is too heavy; the effect adds an extra visual layer; or the real performance issue was hidden rather than fixed.

What to do

• Compare the page with the plugin enabled and disabled.
• Optimize images, fonts, and third-party scripts.
• Use a calmer style and a smaller logo.
• Disable the preloader on the site if it does not provide a noticeable benefit.

When the setup makes the site feel slower, the best rollback is to disable the plugin temporarily and fix the underlying performance issues first.

When JUX Preloader is the right choice

JUX Preloader is a strong fit for a Joomla site that needs a controlled, visually clean, and not overly complex loading screen. Its strength is the simplicity of its configuration: choose a style, background, spinner color, and spinner size, add a logo if needed, and verify the result. That is enough for many landing pages, portfolios, corporate sites, and visually driven projects.

The extension is worth using if you are prepared to validate the effect not only in the admin panel, but on the public-facing site as well. The healthiest workflow looks like this: install it on a staging copy, enable a basic configuration, verify that the preloader disappears properly, align the colors with the template, test the mobile view, clear the cache, and only then move the setup to the live site.

If that is the workflow you need and you are ready to validate it on your own site, you can download the installation package from the download block and start with a safe test. Do not enable the effect at full intensity right away: for the first run, a calm style, a contrasting spinner, a neutral background, and the logo turned off is the better choice. After that, add branding and visual details only if they truly improve the user's first contact with the page.

If instead you need a progress bar rather than a full-screen splash, display rules for individual pages, or more complex AJAX transition scenarios, compare JUX Preloader with alternatives ahead of time. The right choice here is not the most dramatic spinner, but the loading experience that genuinely helps the specific site without getting between the user and the content.