Add marketing docs from dotjuice-elementor-tools, dotjuice-elementor-tools-pro, and dotjuice-pagespeed
This commit is contained in:
15
marketing/dotjuice-pagespeed/documentation/marketing/advanced.md
Executable file
15
marketing/dotjuice-pagespeed/documentation/marketing/advanced.md
Executable file
@@ -0,0 +1,15 @@
|
||||
# Advanced
|
||||
|
||||
Server-side tuning for sites that want to squeeze out every remaining bit of overhead.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
Beyond what shows up in a page's HTML, WordPress runs background processes that cost server resources regardless of whether a specific site actually benefits from them — a dashboard polling mechanism firing every fifteen seconds, a legacy remote-publishing protocol most sites never use, and WooCommerce's own scripts loading in full even on pages that have nothing to do with shopping.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed lets you throttle or disable WordPress's Heartbeat API (the background polling that powers autosave and "someone else is editing this" notices), disable XML-RPC if you don't use remote publishing tools, and stop WooCommerce's cart and shop scripts from loading on pages that aren't part of your shop.
|
||||
|
||||
## The result
|
||||
|
||||
Less background server load, and WooCommerce's overhead confined to the pages that actually need it.
|
||||
19
marketing/dotjuice-pagespeed/documentation/marketing/caching.md
Executable file
19
marketing/dotjuice-pagespeed/documentation/marketing/caching.md
Executable file
@@ -0,0 +1,19 @@
|
||||
# Full-Page Caching
|
||||
|
||||
The single biggest lever for WordPress speed, and the first thing any performance audit will tell you to fix.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
Every WordPress page load runs the same expensive process from scratch: connect to the database, run dozens of queries to assemble the content, execute PHP for your theme and every active plugin, then finally send HTML to the browser. For a typical visitor, that's the difference between a server response in a few milliseconds and one that takes the better part of a second — before a single image or stylesheet has even started downloading.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed builds a static snapshot of each page the first time it's requested, then serves that snapshot directly to every visitor after — bypassing WordPress, your database, and PHP entirely. It's the difference between a librarian re-writing a book from memory every time someone asks for it, versus just handing over a printed copy.
|
||||
|
||||
Mobile and desktop visitors get their own separate cached versions automatically, so responsive layouts and mobile-specific content are never mixed up.
|
||||
|
||||
Cached pages don't go stale, either — the moment you publish or update a post, its cached copy (and your homepage) are cleared instantly, and the plugin can even pre-warm the new cache in the background so your first visitor doesn't pay the "empty cache" cost.
|
||||
|
||||
## The result
|
||||
|
||||
Server response times measured in single-digit milliseconds instead of hundreds — the foundation every other optimisation in this plugin builds on top of.
|
||||
17
marketing/dotjuice-pagespeed/documentation/marketing/cdn.md
Executable file
17
marketing/dotjuice-pagespeed/documentation/marketing/cdn.md
Executable file
@@ -0,0 +1,17 @@
|
||||
# CDN Integration
|
||||
|
||||
Serve your optimised stylesheets and scripts from a CDN hostname, with a single URL change.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
If you already use a content delivery network to serve assets closer to your visitors geographically, your CSS and JavaScript still need to point at that CDN's hostname rather than your own server for the benefit to apply.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed rewrites the URLs of your stylesheets and scripts to point at your CDN hostname automatically, once you tell it what that hostname is — no manual find-and-replace across your theme or plugins required.
|
||||
|
||||
## The result
|
||||
|
||||
Your optimised CSS and JS served from your CDN with one setting, instead of a manual hunt through every place a stylesheet or script URL is generated.
|
||||
|
||||
*Note: this rewrites stylesheet and script URLs specifically. If you're looking to move your entire media library — images, uploaded documents, and so on — onto a CDN, that typically requires a dedicated media-CDN plugin or your CDN provider's own WordPress integration alongside this feature.*
|
||||
17
marketing/dotjuice-pagespeed/documentation/marketing/css-optimisation.md
Executable file
17
marketing/dotjuice-pagespeed/documentation/marketing/css-optimisation.md
Executable file
@@ -0,0 +1,17 @@
|
||||
# CSS Optimisation
|
||||
|
||||
Fewer, smaller, smarter stylesheet requests — one of the fastest ways to improve how quickly a page visibly appears.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
A typical WordPress page loads CSS from half a dozen sources or more: your theme, Elementor, WooCommerce, and every plugin with its own styling. Each one is a separate request the browser must complete before it can safely paint the page — and by default, the browser won't show anything until every one of them has loaded. That's render-blocking, and it's a direct hit to your First Contentful Paint and Largest Contentful Paint scores.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed combines your local stylesheets into a single optimised file and strips out everything that isn't needed to render the page — comments, unnecessary whitespace — without touching the actual styling. Fonts and CDN resources you don't control are left exactly as they are.
|
||||
|
||||
For sites that want to go further, asynchronous CSS loading removes even that single combined stylesheet from the critical rendering path entirely: the browser paints the page using a small snippet of essential "critical" styling you provide, while the full stylesheet loads quietly in the background and takes over once ready.
|
||||
|
||||
## The result
|
||||
|
||||
Fewer HTTP requests, a smaller total payload, and — when paired with critical CSS — a page that visibly renders before its full stylesheet has even finished downloading.
|
||||
15
marketing/dotjuice-pagespeed/documentation/marketing/database.md
Executable file
15
marketing/dotjuice-pagespeed/documentation/marketing/database.md
Executable file
@@ -0,0 +1,15 @@
|
||||
# Database Cleanup
|
||||
|
||||
Every WordPress site quietly accumulates clutter. This clears it out.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
Post revisions pile up every time you save a draft. Abandoned auto-drafts never get deleted. Spam comments sit in your database waiting to be emptied. Plugins leave behind transient cache entries and orphaned metadata long after they're no longer needed. None of this is dramatic on its own, but on a site that's been running for a few years, it adds up to a noticeably larger, slower-to-query database — and a heavier backup every single time.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed gives you one-click cleanup for the most common sources of database bloat — revisions, drafts, spam, expired cache entries, and orphaned data — with a live view of how much each category is currently holding. Prefer to set it and forget it? Turn on scheduled cleanup and choose how often it runs automatically.
|
||||
|
||||
## The result
|
||||
|
||||
A leaner, faster-to-query database and a smaller backup — housekeeping that used to mean a manual phpMyAdmin session, now a single click.
|
||||
15
marketing/dotjuice-pagespeed/documentation/marketing/html-optimisation.md
Executable file
15
marketing/dotjuice-pagespeed/documentation/marketing/html-optimisation.md
Executable file
@@ -0,0 +1,15 @@
|
||||
# HTML Optimisation
|
||||
|
||||
Trim the document itself, and stop paying for features WordPress loads by default that most sites never use.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
WordPress ships with a handful of scripts and behaviours switched on for every site regardless of whether it needs them — emoji support for older browsers, embed discovery scripts, and more. Combined with unminified HTML output, that's requests and bytes spent on nothing your visitors actually benefit from.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed minifies your final HTML output, strips WordPress's legacy emoji-detection script that modern browsers don't need, and gives you the option to disable oEmbed discovery entirely. On top of that, it automatically appends `font-display: swap` to your Google Fonts so visitors see readable text immediately in a fallback font rather than invisible text while the web font downloads — and it can add DNS prefetch hints for any third-party domain you rely on, shaving connection setup time off those requests.
|
||||
|
||||
## The result
|
||||
|
||||
A smaller HTML document, fewer unnecessary background requests, and text that's always visible to your visitors, never hidden waiting on a font file.
|
||||
17
marketing/dotjuice-pagespeed/documentation/marketing/images.md
Executable file
17
marketing/dotjuice-pagespeed/documentation/marketing/images.md
Executable file
@@ -0,0 +1,17 @@
|
||||
# Image Loading
|
||||
|
||||
Load what's visible first, and make sure the one image that matters most for your score is never held back.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
Images are usually the heaviest part of any web page, and by default every one of them competes for bandwidth the moment the page starts loading — including the ones several screens below the fold that a visitor may never even scroll to. At the same time, Google's Largest Contentful Paint metric usually points straight at your biggest above-the-fold image, so if that specific image gets deprioritised by generic optimisation, your score suffers even though "everything is optimised."
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed applies native lazy loading to every image and iframe below the fold, so browsers only spend bandwidth on them as a visitor scrolls close — without any JavaScript library, and without the blank-placeholder flash some older lazy-load techniques cause.
|
||||
|
||||
At the same time, it recognises your designated hero image and does the opposite: forces it to load with maximum priority and never lazily, so the exact element Google measures for Largest Contentful Paint is always fetched as fast as possible.
|
||||
|
||||
## The result
|
||||
|
||||
Bandwidth spent where it counts, on what's actually visible — and your single most important image, prioritised rather than accidentally deferred.
|
||||
@@ -0,0 +1,17 @@
|
||||
# JavaScript Optimisation
|
||||
|
||||
Keep the browser's main thread free for what visitors actually came to see, instead of tying it up running scripts they don't need yet.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
JavaScript is expensive in a way CSS isn't: the browser has to download it, parse it, and often execute it before it can continue rendering the page — and a lot of what loads on a typical WordPress page (analytics trackers, chat widgets, marketing pixels) has nothing to do with what a visitor sees in the first few seconds.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed combines and minifies your local scripts to cut down on requests, then goes further with two complementary techniques: deferring scripts so they run after the page has rendered rather than blocking it, and — for scripts that genuinely don't need to run until a visitor interacts with the page at all — delaying them until the first scroll, click, or tap.
|
||||
|
||||
Every exclusion is handled automatically. jQuery, Elementor's own scripts, checkout and payment processors, and any script carrying page-specific data are detected and left untouched, so the aggressive optimisations apply only where they're safe.
|
||||
|
||||
## The result
|
||||
|
||||
A page that's interactive sooner, because the browser isn't stuck executing a marketing pixel's JavaScript before it can respond to a click.
|
||||
29
marketing/dotjuice-pagespeed/documentation/marketing/overview.md
Executable file
29
marketing/dotjuice-pagespeed/documentation/marketing/overview.md
Executable file
@@ -0,0 +1,29 @@
|
||||
# Dotjuice Pagespeed
|
||||
|
||||
A free, professional-grade performance plugin for WordPress. Full-page caching, CSS/JS optimisation, image lazy loading, database cleanup, and Core Web Vitals improvements — all from one dashboard, no configuration expertise required.
|
||||
|
||||
## Why WordPress sites are slow by default
|
||||
|
||||
Every time an anonymous visitor loads a WordPress page, the server rebuilds it from scratch: dozens of database queries, PHP execution for the theme and every active plugin, then the HTML is assembled and sent. Do that for every visitor, every time, and even a well-built site struggles to load in under a second — which matters, because page speed affects both how visitors experience your site and how Google ranks it.
|
||||
|
||||
Dotjuice Pagespeed attacks this from every angle a real optimisation audit would cover:
|
||||
|
||||
## What's included
|
||||
|
||||
**Full-page caching** — the biggest single win. Once a page is built, it's saved as a static file and served directly, skipping WordPress, the database, and PHP entirely on repeat visits. This is what takes a server response time from around a second down to a few milliseconds.
|
||||
|
||||
**CSS & JavaScript optimisation** — combines and minifies your stylesheets and scripts, removes render-blocking CSS from the critical path, and defers or delays JavaScript that doesn't need to run immediately — all without breaking Elementor, WooCommerce, or the other plugins your site depends on.
|
||||
|
||||
**Smart image loading** — modern native lazy loading for everything below the fold, paired with automatic priority loading for your hero image so the Largest Contentful Paint metric that Google measures isn't accidentally delayed.
|
||||
|
||||
**HTML & resource hints** — HTML minification, removal of WordPress's default emoji and embed scripts nobody asked for, DNS prefetching, and preconnect hints that shave milliseconds off every third-party request.
|
||||
|
||||
**Preloading** — automatic cache warming the moment you publish, so your first real visitor never pays the "cold cache" tax, plus a one-click sitemap preload for warming your entire site at once.
|
||||
|
||||
**Database housekeeping** — clears out the post revisions, spam comments, and expired transients that quietly bloat every WordPress database over time, with both one-click cleanup and a scheduled autopilot mode.
|
||||
|
||||
**Built for real WordPress sites** — every optimisation is written to work alongside Elementor, WooCommerce, and the plugin ecosystem, not against it. Scripts with dependencies, localized data, or webpack bundles are automatically detected and left untouched rather than broken.
|
||||
|
||||
## The result
|
||||
|
||||
A faster time-to-first-byte, fewer render-blocking requests, better Core Web Vitals scores, and a leaner database — delivered through sensible defaults that work out of the box, with room to fine-tune every setting as you learn what your site needs.
|
||||
19
marketing/dotjuice-pagespeed/documentation/marketing/preload.md
Executable file
19
marketing/dotjuice-pagespeed/documentation/marketing/preload.md
Executable file
@@ -0,0 +1,19 @@
|
||||
# Preloading
|
||||
|
||||
Stop waiting for the browser to discover what it needs — tell it in advance.
|
||||
|
||||
## The problem it solves
|
||||
|
||||
Browsers work through a page's resources largely as they discover them, request by request. That discovery process itself takes time, and for the resources that matter most to how fast a page *feels* — your hero image, your web fonts, the third-party services your theme relies on — that delay is pure waste.
|
||||
|
||||
There's a second, quieter problem too: the very first visitor to a freshly published page pays the full "build this page from scratch" cost, because nothing has been cached yet.
|
||||
|
||||
## How it helps
|
||||
|
||||
Dotjuice Pagespeed tells the browser exactly what to prioritise: your designated hero image loads with maximum urgency, key web fonts are preloaded before they're needed, and connections to services you actually use (analytics, fonts, embeds) are opened in advance rather than discovered mid-page.
|
||||
|
||||
On the server side, the moment you hit publish, the plugin quietly visits the new page itself in the background — so by the time a real visitor arrives, the cache is already warm. And with one click, you can do the same for your entire site at once.
|
||||
|
||||
## The result
|
||||
|
||||
Your most important image and fonts, prioritised instead of left to chance — and a cache that's always warm before a real visitor needs it.
|
||||
Reference in New Issue
Block a user