johan
37e5497923
Drop the redundant documentation/marketing/ nesting inherited from the plugin repos, so files sit at marketing/<plugin>/<page>.md. These paths become raw URLs pasted into Elementor pages and ACF fields, so they are much cheaper to change now than once sites reference them. Fixes the four cross-plugin links for their new depth, and corrects the README, which still pointed at the abandoned per-repo documentation/ folders instead of this repo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
18 lines
1.3 KiB
Markdown
Executable File
18 lines
1.3 KiB
Markdown
Executable File
# 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.
|