Full Lightning features list

Core performance

• sessions are created only for visitors that keep cookies
  Bots and scrapers that don't keep cookies no longer spawn rows in the session table — which puts an end to the classic problem of the OpenCart session table bloating to gigabytes.
• optimized Twix template engine
  Recompiles heavy TWIG templates into something close to the old, blazing-fast TPL, saving up to 70ms of CPU time on complex templates.
• optimized event handling
  The event system is one of the most expensive parts of the OpenCart core. Instead of constantly re-scanning handler tables, Lightning builds ready-made lookup lists, so events fire dozens of times faster.
• frequently-used data preloaded into a single pack
  Menus, translations, the category tree and product counts all load from one PHP file at OpenCart startup — which eliminates the 30–40 repetitive queries that would otherwise run on every page.
• faster replacement for OpenCart's file cache
  The stock cache stores each entry's expiry right in the filename, so every single read has to scan the whole cache folder with a wildcard (glob) — and it scans the entire folder again on every request just to purge stale entries. With thousands of files, that drags the whole shop down. Lightning reads each entry directly by its exact filename (no scanning), keeps a copy in memory, and runs the full folder cleanup only once every half hour.
• deep optimizations for the Journal 3 theme
  A faster built-in mega-filter and many of Journal 3's slow internal routines.
• vQMod performance fixes in OpenCart 3

Database speed

• caching of slow SQL queries
  Queries slower than 0.05 sec are cached, and the matching cache entries are intelligently dropped the moment a related table changes.
• SQL query optimization
  Rewrites heavy catalog queries on the fly so MySQL can use indexes instead of full scans and on-disk sorts: it strips needless checks and functions out of sorting, drops unused rating, discount and special-price subqueries, swaps the costly ORDER BY RAND() for a fast random pick, and simplifies category-tree lookups. Off by default.
• product-count caching
  Removes the heavy counting query (SQL_CALC_FOUND_ROWS / COUNT) that runs on category and filter pagination.
• useful database indexes added automatically on install
  Lightning creates the missing indexes on key OpenCart tables, speeding up typical product and category lookups.

Page caching

• caching of critical pages + product pages
  The "critical" pages are the most resource-hungry to generate: home, categories, manufacturers and specials. You can also cache every page except the types you list in the settings (route).
• minor bots get cached pages only
  Every bot except the important ones (Google, Bing, Yandex, Meta, X and the major AI crawlers) gets a 503 Check later response when the requested page isn't cached — so minor bots barely touch your shop's resources. You can grant specific bots full access in Access Control.
• background cache pre-generation
  The cache is first pre-built two clicks deep from the home page; then every visit kicks off background pre-generation two clicks out from the page just visited — so with enough pre-gen speed the next page is already cached, and with steady traffic the busy parts of the site warm up fast.
• product change tracking
  When a product is edited, deleted or added, only the affected pages are dropped from cache, so the shop always shows current data. It catches both changes made through OpenCart (checking whether the product actually changed) and external ones, by watching the product's date_modified field (usually updated by outside scripts).
• live mini-cart inject into cached pages
  A logged-in shopper with items in the cart sees their own cart right on the cached page — the block is swapped into the finished HTML for the current visitor.
• compare and wishlist counts inject into cached pages
  The compare and wishlist counters stay accurate on top of the cached page.
• cached pages reuse for logged-in customers
  A single cached version serves both guests and signed-in customers — Lightning works out the difference between the two and converts a guest page into a logged-in one (and back) on the fly.
• currency convert right in the cached page's text
  Prices are recalculated into the visitor's currency directly in the HTML, so you only keep one cache set in your base currency.
• individual modules load over AJAX on top of cache
  Frequently-changing blocks (recently viewed products, for example) are fetched in a separate request, so they show personalized content while the page itself stays cacheable. You choose which modules load via AJAX in the settings.
• AJAX request caching
  Repeating AJAX responses from cacheable pages are served from cache too — the interface feels snappier.
• ad-tracking URL parameters ignored
  Tags like utm_* are stripped when matching the cache, so ad clicks and search-engine referrals get a cached page instead of a freshly generated one.

Frontend optimization (higher PageSpeed scores)

• grouping and minification of JS and CSS
  Dozens of separate files are downloaded, minified and merged into one — fewer requests and less weight; on the aggressive levels, external resources from other servers are bundled in too.
• all scripts moved to the bottom of the page
  Scripts are pulled out of the head and moved to the very bottom of the page so they don't block rendering.
• an initial set of CSS (critical CSS)
  The styles for the visible part of the screen are inlined into the page body and used until the full CSS loads — the page renders instantly, with no flash of unstyled content.
• deferred loading of heavy scripts and iframes on mobile
  Chats, analytics and maps load only after the visitor's first interaction, so they don't hold up the first render.
• JavaScript turned off for bots, search engines and PageSpeed Insight
  Speeds up indexing and earns nice scores. It's safe, because everyone gets the same version of the page — JS execution is simply gated by cookies. Off by default.
• optimal GZIP compression set automatically
  The admin setting is ignored. Lightning compresses cached pages to the max (the compression cost is paid once, but the benefit lands on every hit) and compresses on-the-fly pages lightly, for the best delivery-speed balance. It also GZIPs the admin area, which makes it noticeably faster.
• correct caching and compression headers for static files
  Written into .htaccess files in the subfolders (it's worth removing these rules from your root .htaccess if you added them earlier).
• optimized font loading
  Text shows immediately and the font swaps in once it's ready. Icon fonts can be loaded first, so you don't get flashing squares.
• optimized loading of banner carousels (owl-carousel)

Image optimization

• images served as WebP
  WebP images are far lighter than the usual formats. Quality is adjustable. Off by default.
• automatic cleanup of stale WebP copies
  Copies whose original is gone are removed periodically, and the stats show how much space you've saved.
• sharper detail on resized images
  Product thumbnails look crisper and don't go soft after resizing. Off by default.
• originals used for large product images
  Shrinks the image cache by 3× or more. Off by default.
• priority preload of the main above-the-fold image (LCP)
  On mobile, the largest image loads with priority — directly improving the key Core Web Vitals metric.
• image dimensions added automatically
  The page no longer "jumps" while loading — a better CLS score.

SEO

• page checksum tracking and real Last-Modified headers
  If a page hasn't changed, the search engine and the browser get an empty 304 response instead of the whole HTML — which dramatically speeds up indexing and repeat visits.
• all product links unified to the form shop.com/product-url
  The breadcrumb still shows the path to the product's deepest category. This means search engines index the shop much faster, and there are fewer page variants to cache.
• canonical 301 redirects
  The address is normalized (www / non-www, http / https) so search engines don't pile up duplicates of the same page.
• http links fixed to https on SSL pages
  Clears up mixed content warnings.
• canonical, prev and next links fixed in categories
  Fixes the links in second-level and deeper categories that used to create duplicate category pages.
• per-page product-limit protection
  The limit is capped at 200 — huge limit values are a common trick for trying to take a shop down.
• index.php?route=common/home stripped from links to the home page

Protection & access control

• search-bot recognition and fake-bot detection
  Scrapers posing as Googlebot are exposed by a reverse-DNS check and don't get the privileges of real search engines.
• Access Control interface
  Block or allow access by IP address, whole subnet (CIDR) or bot name, or serve them cached pages only to save resources.
• flood protection
  When a single address hammers the shop with requests, it's blocked automatically and a notice appears in the widget.
• malicious requests blocked
  Requests showing signs of SQL injection, and hits on forbidden service URLs, are turned away.
• real visitor IP detected behind Cloudflare or a proxy
  Blocks, stats and geo data show the visitor's real address, not the proxy's.

The Lightning widget in admin

• CPU load at a glance
  Click it to see which processes are using the CPU, including the URLs being handled.
• Clear cache button
  Clears every cache (including the system cache and the Journal theme cache) except Lightning's DB cache; the Disable button clears Lightning's DB cache.
• usage statistics
  Page, AJAX and DB caches, optimized-image stats, and average TTFB (page generation time) with Lightning and without.
• live TTFB of the last page served
  Lets you feel the shop's "pulse" and how fast it's running.
• live feed of pages being visited
  With IP, user agent and response time; click a row for full visitor details, including a map and a one-click block.
• pre-generation indicator and blocked-bot counter
  Cache pre-generation progress as a percentage, and how many bots have been turned away.
• free disk space on the server
  Helps you react in time, before things get critical.
• the widget is shown only to users with the modify right on setting/setting
  So you can hide it from your managers.

Tools

• file search across the shop
  Full-text search through the sources (.php, .tpl, .twig, optionally .js/.css) with match highlighting and jump-to-line; lines containing the DB password are masked.
• source code viewer
  With syntax highlighting and auto-scroll to a given line.
• recently changed files
  What's changed lately — handy after updates, or for spotting the aftermath of a hack.
• modifications viewer
  Every installed OCmod and vQmod modification with its XML; disabled ones are flagged.
• database tables overview
  Sizes, engine and indexes for every table, with one-click MyISAM → InnoDB conversion.
• disk space and inode analyzer
  Shows the heaviest folders in the shop by size and by file count (inodes are a common limit on shared hosting), with one-click cache and log cleanup.
• process viewer for the server and MySQL in real time
  Helps you catch a heavy or stuck query; for Lightning's own processes it shows the URL being handled.
• SQL query inspector
  Run any query with its execution plan (EXPLAIN) and cost, and add, drop or force indexes right from the browser.
• catalog optimization check
  Finds problems in the data (products with no description, missing translations, unassigned or disabled products) and fixes them in one click.
• log viewer
  Logs for OpenCart, vQmod and error_log, with highlighting and a live "tail", plus the slowest pages (index.php?li_op=lg).
• live CRON job log
  See in real time which pages are being pre-generated and how long it takes, without digging through server logs.

Alerts

• MySQL queries slower than 2 seconds
• MySQL queries returning more than 50,000 rows or over 10 MB
• fatal errors during shop operation
  Far clearer and more useful than the log.
• JS/CSS files that are linked but don't actually exist
• prompt to move to PHP 7 if the server runs something older
• prompt to enable a PHP accelerator (OPcache)
  Without it, PHP recompiles your code on every request.
• detection of Varnish, mod_pagespeed, disabled Keep-Alive or broken compression
  Any of these can get in the way of optimization.
• prompt to edit robots.txt if it couldn't be done automatically
• instructions for moving the shop to full HTTPS if it isn't done, or done wrong
• instructions for setting up the CRON job for page pre-generation

Reliability

• disk-overflow protection
  When free space runs low, caching pauses automatically instead of breaking the site.
• stuck pages aborted automatically
  A generation that hangs longer than allowed is forcibly stopped (with a stack trace), so one heavy request can't eat the whole server.
• instant 404 for requests to non-existent files
  Without spinning up the whole shop engine.
• the "little things" keep working on top of cache
  The "Who's Online" report, product view counter and ad-link click tracking all keep working, even though pages are served from cache.

Extras

• faster email on the final checkout step
  Emails (an order confirmation, say) go out in the background and don't make the buyer wait on the final checkout step, which noticeably speeds up placing an order. Off by default.
• multilingual cookie consent notice
  Many third-party implementations don't play nicely with page caching — this one does. Off by default.
• background (non-blocking) external HTTP requests
  Calls to outside services run in the background and don't hold up page generation.
• X-OpenCart-Lightning header on every response
  It carries the serve and generation time, the cache age and a breakdown by stage (PHP, Lightning, SQL, resize, WebP) — handy for keeping an eye on speed right in your browser's dev tools.
• developer API: in_cache() / cache()
  Cache the result of any function in a single line, with automatic invalidation when the listed DB tables change.
• li_sql=1 URL parameter
  Shows the execution time of controllers and queries on the page.
• li_module=1 URL parameter
  Shows module info — useful when you need a module's name to load it via AJAX.