Top Man Digital: Site Acceleration — WebP and PageSpeed Control

Version 1.1.3

- Fixed the mapping of WebP copies to images whose names contain Cyrillic characters or spaces.

- Fixed the search for sizes of such images and stopped re-queuing already processed files.

Version 1.1.2

- After the demo period ends, module screens open for viewing with an explanation instead of the message "Module failed to load".

- Change rejections are displayed in Russian; the save button in the module settings is unavailable until the license permits changes.

- A failed reinstallation no longer deletes tables and settings saved when the module was removed.

- Removing the module unregisters the OnGetFileSRC event handler, which previously remained on the site.

- Includes fixes from 1.1.1: administrative screen layout (margins, measurement table, PageSpeed key field).

Version 1.1.0

This update is built from version 1.0.0 and includes all changes released thereafter. It can be installed on any intermediate version: if some updates did not reach the site, nothing will be missed.

ONE-CLICK MANAGEMENT

Previously, going from installation to an accelerated page required six conscious steps, one of which was a screen with fifteen checkboxes, all of which were unchecked in a fresh installation. Now, on the "Overview" tab, two buttons are placed side by side that cover everything the store needs: "Enable Acceleration" and "Prepare Image Copies".

The first button automatically selects a safe set of options: WebP via the picture tag with the original as a fallback, lazy loading on scroll, reserved space for images, and priority for the main image of the first screen. Each of these adjustments either takes effect or leaves the page unchanged—the layout will not break. The button does not touch anything that replaces the URL without a fallback, changes the tag itself, or writes to a cache that cannot respond differently to different browsers; these remain separate solutions. The set is applied on top of saved settings, so a manually configured site retains its configuration.

The settings screen opens to what the store owner has an opinion on. The fifteen checkboxes are organized into three levels: the basic level is open by default, while "Advanced Features" and "Manual Configuration" are collapsed. Numeric parameters are no longer the first thing a person sees, and the emergency stop is shown only when it is activated, not as a constant secondary question next to "acceleration enabled".

PAGESPEED MEASUREMENTS BEFORE AND AFTER

The "Overview" tab shows what the Google Lab says about the main page before enabling acceleration and after: score, Largest Contentful Paint, First Contentful Paint, Time to Interactive, Layout Shifts, and page weight—for both mobile and desktop. The PageSpeed key is specified once on the "Settings" tab; it is stored separately from site settings, does not appear in the change history, is not included in exports for support, and is never displayed.

back. The measurement is performed by a queue task because Google launches a real browser, and the response time ranges from twenty seconds to one minute. The module cannot determine which measurement to consider as 'before': each record indicates whether acceleration was active at the time of capture.

IMAGES

Animated GIFs are served as WebM video: for 32 real animations, 362 MB of source files are replaced by 30 MB of video. Animations are also converted to animated WebP where video is not suitable. A separate checkbox has been added to declare the main image in the head; it is disabled by default and helps only when the image is inserted by a script or a slider built in the browser. Site icons—favicon and the family of apple-touch-icon, android-chrome, mstile, safari-pinned-tab—are no longer converted or replaced: their addresses are read not only by browsers. The module has learned to detect the dimensions of thumbnails from upload/resize_cache, so such images now receive reserved space and lazy loading.

STABILITY

The module requires PHP 8.2—this was verified only by the installer. If the PHP version is switched to a lower version after installation, any administrative page on the site, including pages of other modules, crashes with a parse error, but only for users who have rights to the module. Now the version is also checked at runtime: if it is below 8.2, the module is not connected by the core, does not register a menu handler, and does not start tasks, while its pages display a clear message with the required and actual version. The site continues to work as if the module were not installed.

Structural page validation now accounts for elements intentionally added by the module: previously, an added link tag would reject the entire page, causing it to silently lose all substitutions. The map cache no longer opens the output buffer—previously, pages responding with a redirect would crash with a cold cache. Three administrator actions were unavailable due to a missing operation map entry; the "Overview" screen no longer requires the integrity of the entire module to generate a report.

Version 1.0.16

Built from 1.0.13, published in the cabinet. The update also includes changes from 1.0.14 and

1.0.15 and installs on any of them.

PAGESPEED MEASUREMENTS ON THE OVERVIEW

The Overview tab shows what the Google laboratory says about the main page before enabling WebP and PageSpeed control.

acceleration and after: evaluation, largest element paint, first paint, time

blocks, layout shifts, page weight — for mobile and for desktop. PageSpeed key

specified once on the Settings tab; it is stored separately from site settings, not

does not appear in the change history, is never included in the export for support, and is never displayed

back. The measurement is performed by a queue task because Google launches a real browser and

responds in a time ranging from twenty seconds to one minute. The module cannot determine which measurement counts as 'before': each

record whether the acceleration was active at the time of capture. The emergency stop now skips the measurement and

continues to halt everything that modifies the site — otherwise the 'before' measurement could not be taken.

ANNOUNCEMENT OF THE MAIN IMAGE

A separate checkbox, disabled by default: the largest image on the first screen is declared

in the head with a preload directive. This helps only when the image is inserted by a script or slider,

assembled in the browser; the browser already finds an image written in standard markup using the img tag

in advance — on the demo stand, the difference between six measurements was within the margin of error.

The hint in the settings explains how to check your specific case using the PageSpeed report.

SITE ICONS ARE NOT TOUCHED

favicon and the apple-touch-icon, android-chrome, mstile, safari-pinned-tab families are not

converted or replaced: their addresses are read not only by browsers, and a WebP copy is not needed for them

by anyone.

PROTECTION AGAINST UNSUITABLE PHP VERSION

The module requires PHP 8.2 — this was checked only by the installer. If after installation the PHP version

switched below (in the hosting panel, for the cron task under the old binary, during the copy migration

of the site), any administrative page of the site, including pages of third-party modules, crashed with

parsing error — and only for those who have rights to the module. Now the version is also checked at runtime: on PHP below 8.2 the module is not connected by the core, does not register the menu handler, and does not start tasks, while its pages show a clear message with the required and actual version. The site continues to work as if the module were absent.

FIXES

The structural page check now learns to take into account elements that the module intentionally adds; previously, an added link would reject the entire page, and it would silently lose all substitutions. Messages about remote server failure specify the cause — status, size, or type — rather than "policy". The check prevents starting a long network request from the path serving the page.

THE PAGE NO LONGER FAILS ON REDIRECT

The cache, which the module uses to store information about the page's images and scripts, was opening the output buffer. PHP prohibits opening a buffer inside an output buffer handler, and the module enters such a handler on certain paths—for example, when the page responds with a redirect: the buffer is flushed before the Location header is sent. There, this is not a failed cache write, but a fatal error: instead of being redirected, the visitor received an empty page with an error message.

Version 1.0.14

Built from version 1.0.13, published in the cabinet.

ANIMATIONS CAN BE SERVED AS VIDEO

The heaviest content most websites serve is animated GIFs, and no image format

handles this well. A test on 32 real animations: 362 MB of source files,

108 MB in animated WebP and 30 MB in WebM video. On the homepage of one site, four

animations weighed 30.0 MB and were reduced to 3.0 MB.

A new checkbox "Show animations as video instead of images" on the "Settings" screen, in the group

regarding images. The module additionally encodes each animation into WebM and inserts it on

the page using a video tag — without control buttons, silent, auto-plays and loops, so

for the visitor it still looks like a GIF. The original img tag remains inside

as a fallback: a browser that does not support video will show exactly the same animation as

before. The class and style from the image are transferred to the video, and the alt caption becomes aria-label.

The checkbox is unchecked by default, and there are two reasons for this. ffmpeg is required on the server — without it

nothing is built and the checkbox does nothing; the presence of ffmpeg and support for the VP9 codec

displays a "Server Check" screen. And this is the only substitution that changes the tag itself:

If styles in the markup are written for the img tag (for example, '.banner img { width }'), they will not apply to video

— such templates should be checked visually.

Images with srcset and images inside the picture tag are not affected by this mode: video cannot be

placed inside a picture, and a single file does not respond to a set of sizes. Animations in these cases

receive a standard picture wrapper with an animated WebP, as before.

On the 'Module Settings' screen, a limit appeared for 'How much time is allowed for encoding one

animation' — 45 seconds by default. The encoder never works longer than the task

is considered occupied: if these two numbers are set inconsistently, the smaller one is taken, because

an encoder that has outlived its lease is a task assigned to the second processor, and two

processes write a single file. The queue handler, which runs directly within the visitor's request, does not handle video tasks at all: it has only one second for everything, while encoding takes tens of seconds.

FIX, IMPORTANT WHEN ROLLING BACK THE VERSION

If a parameter existed in the saved settings that the installed version of the module did not recognize, the module would reject the entire set of settings, and the site would silently stop speeding up. No errors or history entries were generated: settings validation occurs before the module has a chance to write anything. This happens after rolling back the module to a version older than the one that saved the settings.

Now, an unrecognized parameter is discarded, while everything else continues to work. On the "Settings" screen, a banner appears listing such parameters with a hint to save the settings again; this is sufficient for the list to disappear. Saving still does not accept an unrecognized parameter: there, an error can still be corrected.

Additionally, settings that a version cannot read now have their own response on the screen. Previously, this state was displayed with the same words as "nothing is enabled," leading the site owner to check the checkboxes, among which there was nothing to find.

Version 1.0.13

The update applies to both 1.0.11 and 1.0.12: it includes changes from both versions.

THE ADMINISTRATIVE PART HAS BEEN COMPLETELY REDESIGNED

All seven screens of the module have been rewritten with a unified design. The module's operation on the site

has not changed in any way: no settings, no saved parameters, and no processing stages

have been touched.

What has changed on the screens:

Settings. Checkboxes are grouped with headings; three clarifications that previously existed on

on a separate screen, they are placed under the checkboxes that enable them. The website tab, which is governed by

general settings, now directly states that changes cannot be made here and why, instead of showing

a screen of grayed-out unavailable fields without explanation.

Module settings. Sixteen numeric limits are arranged into four semantic groups with

labels, and allowed ranges are aligned in a column. The checkbox to run the queue processor on a

schedule has been moved to the top as a separate block: previously it was located below all the numbers.

Server check. The summary is divided into 'ready for work', 'for contacting support' and

'copy retention period'. A check that failed to execute is now explicitly written as 'failed'.

this line had an empty cell read as "no comments". Each verdict is marked

with a symbol, not just a color.

Background tasks. Two runs are shown identically, with a progress bar. The line for

the cron scheduler, the nginx rule, the check code, and the server capability fingerprint

now have a "Copy" button: previously they had to be selected with the mouse across line breaks.

Overview. The work result is shown by two large numbers. Messages about other modules that modify

pages are no longer marked with a green checkmark: the module cannot distinguish antispam from

a competing accelerator, so this is a note, not an assessment.

History and support. Pagination has been added at the bottom, and the wide table scrolls.

inside itself, without stretching the page.

License and demo. When the demo ends, the purchase block becomes the first on the screen. Five

The consequences of the demo ending are divided into what stops and what remains; read as a single list, they amounted to five losses.

FIXES

WebP copies now reach pages where the template wraps each image in a picture tag. The module did not touch such images at all—and correctly so, if the author set their own variants via source. But an empty wrapper without a single source sets nothing, and now a copy reaches there: for a browser that reported support for the format, the address is substituted on the spot; for others, a source is added inside the existing tag, while the original image remains as a fallback. On a tested page, three ready copies out of four reached the browser.

In the changelog, two events were shown with service codes instead of Russian names.

FROM VERSION 1.0.12

For sites with the Composite Site feature enabled: the core runs page handlers a second time on the copy that goes into the full-page cache, while the module had a flag set to "work once per request". Of the two copies, exactly one was processed, and never the one that is then served to all visitors. A measurement on a client site showed: the page received 54 substitutions during generation, but none when served from cache. Now the module distinguishes copies by their content.

The settings screen warns if the Composite Site feature is enabled, and lists three settings that cannot work on a page served from cache.

A conflict with thumbnail modules that reopen the file by its address has been addressed: on such sites, the "serve copies to all browsers" setting is set aside to prevent the page from crashing with a GD library error.

The "Fine-tuning" screen has been removed: fourteen of its fifteen fields were already checkboxes on the "Settings" screen, and the remaining three were moved there as well.

Version 1.0.12

The main issue was for sites with 'Composite Site' enabled: the module provided almost no benefit, and this is now fixed. The core runs page handlers a second time on the copy that goes into the full-page cache, while the module had a flag set to 'work once per request'. Of the two copies, only one was processed, and never the one that is then served to all visitors. A measurement on a client site showed that during generation the page received 54 replacements, while the version from the cache received none, and this occurred on every request. Now the module distinguishes copies by their content: identical bytes are not processed a second time, while the other copy receives its own processing.

The settings screen warns if 'Composite Site' is enabled and lists three settings that cannot work on a cached page: direct WebP delivery, background replacement in styles, and replacement of lazy loading addresses. All three depend on information reported by the specific browser, while a cached page is served identically to all users, including browsers without WebP support. On such sites, copies are served via the picture tag, where the original remains a fallback option. We recommend disabling the composite feature.

Conflict with thumbnail modules has been resolved. Such a module retrieves the image address and reopens the file; upon obtaining a copy address in WebP format, it crashes with the error 'imagecopyresampled(): Argument #2 must be of type GdImage, false given', because the GD library on most hosting providers cannot read WebP. Now, the setting 'serve copies to all browsers' automatically stops applying if a module of this type is installed on the site, and the settings screen indicates this; copies continue to reach visitors via page markup, while the thumbnail module receives the original file. The following modules are checked: mystery.thumbs, wd.thumbs, niges.imageresize, aspro.thumbs. The checkbox does not need to be unchecked: it will work again if such a module is removed.

The 'Server Check' screen now includes a section about the browser cache duration for copies—the very one that

which speed reports complain about. The header is set by the server serving the file, and the image request is not seen by PHP at all, so the module cannot set the expiration itself but can prepare a rule. The section shows whether the module's own rules are recorded alongside copies (storage year and "immutable" mark, placed by the installer), what Apache sees, and prints a ready-made line for nginx with paths to your site.

The "Fine Tuning" menu item now has its own icon.

Six pre-release review issues have been resolved. The rule stating that "nothing depending on a specific visitor enters a page that is cached as a whole page" did not work: such a page was identified by response headers, but the page on its way to the cache does not carry them. Now the module asks the platform whether caching is enabled at all. Cleaning up temporary directories no longer follows symbolic links — on shared hosting a neighbor could have left a link anywhere. The thumbnail module identifier, when unable to connect to the database, answered "none exist" and thereby removed protection exactly when something was already wrong; now unknown status is read as "do not include". The server check opens only the site name taken from the platform, not what is written in the request header. The page checksum is calculated after cheap checks, so a site with response processing disabled no longer pays for it on every page.

Separately, eight pre-release review issues have been resolved. Among them is a significant one: the rule that prevents browser-dependent substitutions from entering a page cached for everyone did not actually work — it asked for flags from the response itself, but the page on its way to the cache does not carry them; now the module asks the platform whether caching is enabled at all. Cleaning up temporary directories no longer follows symbolic links. Determining installed thumbnail modules on a database error answered "none exist" and removed protection — now unknown status and absence are distinguished. The page hash is calculated after cheap checks, not before them.

Version 1.0.11

Animated GIFs are converted to animated WebP. This format has much to offer: a test banner weighs 9.62 MB in GIF and 1.75 MB in WebP with the same animation — measured on client hosting. The copy remains an image, so it travels the same path as the rest and is served through the same wrapper, while the original GIF remains a fallback option.

Imagick is required: only it can read all frames, so on servers without it, GIFs are simply skipped. Animations are queued last and are not processed while a visitor waits for a response. A separate background run has been added for them on the "Queue" screen — one animation takes as long to prepare as a hundred ordinary images, and in a general run they would interfere with each other. The default limit for the source file size has been raised from 8 to 12 MB: this was the threshold that filtered out such banners.

A checkbox "Serve WebP directly, without picture wrapper" has appeared. Standard delivery wraps the image in a picture tag so that browsers without format support receive the original, but this places the image one level deeper in the markup — and on some templates styles like ".card > img" and gallery or slider scripts that search for the image via the parent stop working. With the checkbox enabled, the copy address is inserted directly into src, and the markup remains unchanged. Backgrounds in styles were always served directly, so enabling the checkbox brings all delivery to a uniform appearance. The copy is offered only to browsers that declare support for the format.

Fixed: background substitution could corrupt the markup. If the address in the style was written with escaped quotes, after substitution they returned as real quotes and broke the attribute — the element lost its background. Now the value is encoded back, and the result is verified against the intended one on the finished page.

Fixed: copy preparation could break the page. Limits in settings contradicted each other — an image of 40 megapixels requires more memory than the module is allowed.

Memory shortage causes the entire page to be interrupted. Now the requirement is calculated before work begins and verified against what is actually available to the process.

Fixed: after editing the script file, the site continued to serve the old compressed copy. The copy was selected by file address rather than content, so the corrected script was never rebuilt. Now file size and time determine whether a copy is valid, and an edit triggers a rebuild.

Fixed: Bitrix script addresses were being replaced. This broke the core rule "one address, one load" during component loading and left outdated copies of service builds. Such files are now left untouched.

Fixed: on the module settings screen, some numeric limits were wider than the operational range. It was possible to specify, for example, 50 tasks per background agent run, although no more than ten are actually taken—the number was saved and silently truncated. Now the upper limits on the screen match what the module actually enforces, and values saved by a previous version above the new limit are displayed within the allowable range.

Strengthened following pre-release verification. Animation is assembled in a temporary directory whose name cannot be predicted externally; on shared hosting this protects against file substitution by a neighboring server user. The check for whether frames will fit is no longer disabled on servers where ImageMagick limits are not set: previously, a specially prepared GIF could occupy the server for a long time on such servers. Additionally, GIFs are read not in full but within the allowed size limit, and a non-standard memory_limit value no longer causes an error in the middle of conversion.

Large catalogs are processed many times faster. The queue was replenished only by the background agent — no more than ten tasks per minute and only while someone was on the site — so the CLI worker, capable of processing a hundred tasks in one pass, was idle waiting for a queue that was being filled at a rate of ten. Now the queue is replenished by the same component that processes it, and the worker takes the site settings,

not its own defaults. On the "Queue" screen, a "Scheduled Run" block appeared with a ready line for the scheduler: containing paths to your site and the PHP on which the site runs. The line can be run in multiple threads—the task is assigned to exactly one. Measurement: 25 images in 3.8 seconds with one thread versus three per minute with the agent.

Fixed: a run through the catalog could not redo what had once been rejected. Upon re-queuing, the queue returned an existing task in any state, including one completed in vain, so the catalog run would proceed, report, and place nothing. Installing Imagick, raising the size limit, or restarting the run never helped. Now, a completed task for a file without a copy is returned to work.

Fixed: a long conversion was taken from the one performing it. Task lease lasted a minute, but converting a large animation takes longer, and the cleaner of stuck tasks would transfer it to another—the work was discarded and restarted, three times, after which the file was deemed non-convertible. The lease now survives the entire pass.

Fixed: animations were not written on hosting where the site is locked in its own directory (open_basedir). The system temporary directory is unavailable there, and the copy was written exactly there. Now writing goes to the temporary folder of the CMS itself within the site.

Fixed: images with spaces and Cyrillic in the name were not optimized at all. The address arrives encoded, while on disk the name is plain—the file was searched under a name that does not exist, and the miss appeared as an attempt to go outside the site.

Fixed: a server with configured ImageMagick is no longer downgraded by the module. Previously the module lowered its limits to its own, and on a server where a gigabyte of memory is allowed, this loaded the disk layer instead of offloading it: an animation with 204 frames hit the disk limit. The module now sets its own numbers only where the build has none, and knows how to raise them; upon hitting someone else's ceiling, it refuses once and reports the numbers.

Fixed: the run progress counter was calculating incorrectly. Both runs were reading all images sequentially, and the 'total' count was only based on its own type — a site with forty animations among five hundred images displayed '116 of 40' and continued to grow, which appeared as a hung run.

Fixed: animations were left without copies when the direct delivery checkbox was enabled. The logic excluded them entirely — GIFs in this mode have no fallback option — and copies were built but never reached anyone. Now, regular images go directly to src, while animations receive a picture wrapper: it appears only around them.

The default copy size limit has been raised from 8 to 12 MB — to the same value as the source limit. Since a copy is only saved if it is smaller than the original, a separate smaller limit would discard already completed work.

Minor: the module version on screens is now taken from the running code, not from the installer record, which remained unchanged after an update; the worker, having emptied the queue, continues to write instead of reporting a limit hit.

Fixed: attributes written with single quotes or without quotes were read as empty. Such images and scripts were simply invisible to the module — not compressed, not deferred, not measured. Nothing broke, so it went unnoticed: on a template structured this way, the module silently did nothing.

A checkbox for 'Scheduled Queue Processor' has been added to the settings screen. Previously, the 'Queue' screen displayed a line for the scheduler and indicated that the processor needed to be enabled, but there was no place to enable it.

Version 1.0.10

Animated GIFs are converted to animated WebP. This format offers a significant advantage: a test banner weighs 9.62 MB in GIF and 1.75 MB in WebP with the same animation — measured on client hosting. The copy remains an image, so it travels the same path as the others and is served through the same wrapper, while the original GIF remains a fallback option.

Imagick is required: only it can read all frames, so on servers without it, GIFs are simply skipped. Animations are queued last and are not processed while the visitor waits for a response. A separate background run has been added for them on the "Queue" screen — one animation takes as long to prepare as a hundred ordinary images, and in a general run they would interfere with each other. The default limit for the source file size has been raised from 8 to 12 MB; this was the threshold that filtered out such banners.

A new checkbox "Serve WebP directly, without picture wrapper" has appeared. Standard delivery wraps the image in a picture tag so that browsers without format support receive the original, but this places the image one level deeper in the markup — and on some templates styles like ".card > img" and gallery and slider scripts that search for the image via the parent stop working. With the checkbox enabled, the copy address is inserted directly into src, and the markup remains completely unchanged. Backgrounds in styles were always served directly, so enabling the checkbox makes the delivery consistent across the board. The copy is offered only to browsers that declare support for the format.

Fixed: background substitution could corrupt the markup. If the address in the style was written with escaped quotes, after substitution they were returned as real quotes and broke the attribute — the element lost its background. Now the value is encoded back, and the result is verified against the intended one on the finished page.

Fixed: copy preparation could break the page. The limits in the settings contradicted each other — an image of 40 megapixels requires more memory than the module is allowed to use.

Memory shortage causes the entire page to be interrupted. Now the requirement is calculated before work begins and verified against what is actually available to the process.

Fixed: After editing the script file, the site continued to serve the old compressed copy. The copy was selected by the file address rather than its content, so the edited script was never rebuilt. Now the file size and time determine whether the copy is valid, and an edit triggers a rebuild.

Fixed: Addresses of Bitrix scripts were being replaced. This broke the core rule "one address — one load" during component loading and left outdated copies of service builds. Such files are now left untouched.

Fixed: On the module settings screen, some numeric limits were wider than the working range. For example, one could specify 50 tasks per background agent run, although no more than ten are actually taken; the number was saved and silently truncated. Now the upper limits on the screen match what the module actually enforces, and values saved by a previous version above the new limit are displayed within the allowable range.

Strengthening based on pre-release testing. The animation is assembled in a temporary directory with an unpredictable name; on shared hosting, this protects against file substitution by a neighboring server user. The check for "whether frames will fit" is no longer disabled on servers where ImageMagick limits are not set: previously, a specially prepared GIF could occupy the server for a long time. Additionally, GIFs are read only within the allowed size limit, and a non-standard memory_limit value no longer causes an error in the middle of conversion.

Version 1.0.9

Fixed an error that could prevent the order page from opening in the personal account

(TypeError in the OnAfterResizeImage handler). The Bitrix core passes event handler arguments

in the form provided by the calling code: the standard order details component

resizes the image in such a way that instead of callback data, null is received, and instead

of dimensions, false is received, causing the handler with strict types to fail at its first line, crashing

the page. The error occurred when the "Generate copies when uploading files" setting was enabled.

All five core event handlers have been fixed, not just the one that crashed: none now

declare argument types; each checks the received data itself and silently does nothing

on unexpected input. A separate check in the test suite prohibits returning strict types

to handlers.

We recommend installing this update immediately.

Version 1.0.8

Opening a page prepares the entire page. Previously, for a single view, three images were queued for preparation, assuming the next view would continue the process. On a catalog page, there are thirty to sixty images, and on a site without traffic, there is no next view, which made it look like "conversion is not working." Now, a single view queues all missing images for the page, and immediately after the page is sent, up to twenty of them are prepared - the visitor has already received the page and is waiting for nothing. Only the queuing has become broader; the conversion itself is still limited by the same boundaries as before, and on servers where work continues until the response, nothing has changed.

A new "Fine-tuning" section is for those who find the "Settings" screen groupings too large. There, one checkbox enables several related items at once; here, the same items are enabled individually - for example, image copies without queuing when files are uploaded. The same tabs for sites, the same saving in one action, the same cancel button. Only what actually affects pages is shown; each setting is labeled in plain language.

Ordinary saving no longer resets individually set values: groupings are written over the saved values, not over the factory defaults. If values are set finely and do not match the groupings, the "Settings" screen warns about this before saving.

The field "How many first images to load immediately" no longer offers values less than 2: the module never went below that before either - the main image of the page should not be delayed - but the screen wrongly promised zero.

Version 1.0.7

The main issue has been fixed: the module will never again defer the main page image.

The counter for "how many initial images to load immediately" was being consumed by

service images - the logo and messenger icons in the header - and on a verified showcase

the entire allowance was exhausted by them before the first real image. The first-screen

banner received deferred loading, yet it is precisely this image that the browser uses

to measure page appearance speed; this also caused a noticeable layout shift. Now,

service elements - vector files and anything referred to as a logo, icon, or sprite -

do not consume the allowance: deferral begins only after the images the owner intends.

The "most important page image" mark is now assigned to the first meaningful image,

not the position previously always occupied by the logo.

Five preparation numbers upon page opening have been moved to the technical limitations

screen: how often it runs, how many images and seconds are allocated to it before and

after the response. Previously, these existed only inside the module, and on a large

catalog there was no way to retrieve them.

The word "profile" has been removed from the interface. Internally, the module still

stores settings as versions - this is what makes changes reversible - but the screen

that was called profiles was removed in the previous version, while the texts lagged

behind: the action log wrote "profile created," the license promised "publication of

profiles," and the module settings directed to a section that no longer exists. Now,

ordinary terms are used everywhere: settings created, settings applied, site settings

deleted.

Version 1.0.6

The main issue has been fixed: images of the currently viewed page are now prepared first. Previously, the queue was processed in the order of arrival, and the batch run managed to add all site files to it - 2,487 items on a tested showcase. When a visitor opened a page, its images were queued behind the batch run, and the preparation during page display worked honestly, but only for files on pages that no one was viewing. From the outside, this appeared as "conversion on the fly is not working".

Now the order is determined by who is waiting: images of the page being shown come first, then everything else, and finally the batch run. The batch run still exists to occupy idle time, but it cannot stand in front of the visitor.

During a single page display, as many images are prepared as can be processed within the allotted second, not just one. The second was the true limitation, so it remains unchanged.

Settings have become simpler once again: the profiles screen has been removed. Settings are now configured via tabs - for all sites or for a single one. Profiles, priorities, address templates, drafts, and versions were a second way to achieve the same result, but using developer terminology. This is precisely why a checkbox ended up in a profile that was not applied to the site. Internally, everything remains: settings are still stored by version, and the last change can be undone.

If the site contains a set of settings created by a previous version of the module and it takes precedence over the tab, the settings screen will indicate this and offer to disable it.

Technical signatures have been removed. On the previous screen, a setting without its own description was displayed only by its internal name, such as image.webp - it was impossible to understand what the checkbox did from such a string. Now, every setting has a name and an explanation in plain language.

Version 1.0.5

Settings have become simpler. Previously, they had to be configured via profiles: each had its own site code, priority, address templates, drafts, and a list of versions to be published one by one. All of this remains internally - it is the foundation for the ability to roll back - but it has been removed from the screen. Now, on the settings screen, there are tabs: "All sites" and one tab per site.

A site operates under general settings until "Configure separately" is clicked - then its settings are created as a copy of what is currently being served to that site, and subsequent changes do not affect other sites. The "Restore general settings" button reverts them. Instead of a list of versions, there is now a single "Undo last change" button.

Fixed, and this is the main point of this version: on sites with multiple platforms, settings could be saved to a profile that responded to no requests. The screen selected the profile based on the first active site in sort order, while visitors were served by a different one. The checkbox was saved, published, and visible on the screen - but it did not work on the site. Now, reading and writing occur in the same profile, and the screen explicitly names the one being displayed.

Fixed: the server check reported that composite cache was enabled on sites where it was disabled. The cache mode flag was read, but it remained in the settings forever after being disabled. Now, the state is queried from the platform.

Profiles can be deleted. The button appears next to a disabled profile; the last profile cannot be deleted. Version records are deleted along with it, and a deletion record remains in the action log.

The profiles screen has not disappeared and remains in the section for specialists - for tasks that the tabs are intentionally not designed to handle: a profile for a site section, separate settings for authorized visitors, and transferring settings between sites.

Version 1.0.4

Preparing copies when opening a page. Previously, images were prepared only by a background agent - a few per minute, which could take days for a large catalog. Now, part of that same work is done at the moment the page is displayed, so images on the open page are ready in seconds. Who pays the time cost depends on the server, and the module determines this itself: if the server can return the page and continue working (php-fpm, LiteSpeed) - no one pays. On others, work proceeds until the response, so there are strict limits: one image, no longer than a second, and not on every request. What your server can do is written on the "Server Check" screen. The feature is disabled by default and is enabled with a separate checkbox.

Fixed: The module itself caused layout shifts. Lazy loading hung on images with unknown dimensions - no space was reserved for them, and the page jerked during loading. On a tested showcase with 42 lazy-loaded images, 21 had no dimensions, and CLS increased from 0 to 0.31. Now lazy loading requires known dimensions.

Fixed: The module did not know the dimensions of its own copies. When replacing the file address in markup, our webp is already there, and the size was searched where it does not exist. Now it is taken from the copy data itself - the shift is gone, and such images can be lazy-loaded again.

Fixed: Batch processing did not move on a visited site. It was limited by the length of the entire queue, which is filled by normal traffic, so the batch always received a refusal. Now, in one step, it adds no more than the background worker can process.

Fixed: On servers where Imagick lost transparency, the image was not served at all. Now it is rebuilt without losses, as was already done with GD.

Version 1.0.3

Mass preparation of copies. Previously, the queue was filled only by views: open a page - the module orders three images from it. Thus, it keeps up with new files, but cannot catch up with accumulated ones, and never reaches images from rarely visited pages. In a showcase with 3,879 images, this is 43 hours of agent work for six minutes of actual conversion. Now, on the "Background Tasks" screen, there is a run through all site files: it runs in the background, resumes from the point of stop, replenishes the queue in small batches, and skips those for which a copy is already collected.

The server check warns about the Bitrix composite cache. The composite takes a copy of the page before the module changes it, so the saved pages contain neither lazy loading, nor image sizes, nor links to prepared copies. Only the visitor whose request bypassed the cache sees the changes. While the composite is enabled, of everything the module does, only the file address substitution reaches the visitor.

Version 1.0.2

The acceleration profile is now created during installation: it applies to all sites,

yields to any of your own profiles, and does nothing until the necessary options are selected.

Previously, no settings were saved before manually creating a profile.

A profile can be written for all sites at once, and the site is selected from a list rather than entered by code.

Fixed: when multiple profiles matched, the one with the higher priority number was applied, although the interface always promised the opposite. The profile created during installation therefore overwrote manually created profiles.

A profile can be disabled and re-enabled. Previously, publishing included the profile, but there was no way to disable it.

The profiles screen has been streamlined: three fields instead of six, rare settings are collapsed, creating a profile immediately opens it for configuration, and the list shows where each profile applies and which one takes precedence.

Fixed: the image preparation queue would stall. A copy that saves less than one-tenth is not served to the visitor - yet it was still counted as not ready, so the same small files would consume the entire limit on every response. On a tested showcase, three thumbnails of 1-2 KB prevented forty other images, including a 1.4 MB file, from entering the queue.