Search Results for 'homepage'

Hello @Calin

I am writing to you after a deep technical audit that lasted two days, conducted by a Senior Infrastructure Engineer and Web Performance Specialist. We had to take this measure because our PageSpeed scores are stuck between 31% and 41% on mobile, despite running on a high-end VPS with persistent cache (Redis/Object Cache) and every possible server-side optimization.

Google has officially notified us regarding this poor performance, stating that our site is no longer a priority in search rankings due to failing Core Web Vitals. After a thorough investigation of the source code and database, we have pinpointed the root cause: The Newspaper theme is loading both Desktop and Mobile assets simultaneously on mobile devices.

Even with dedicated mobile pages (separate IDs), the theme “stacks” the entire desktop framework on top of the mobile one. This redundancy is killing our performance.

I need you to take this diagnostic to the tagDiv development team immediately. We need to know if and when a fix will be released. If this architectural flaw is not resolved, I will be forced to migrate to another theme or develop a custom one, as I cannot afford to lose my SEO ranking due to theme bloat.

Technical Diagnostic:

Problem: Mobile pages heavier than desktop pages
Date: 03/05/2026
Theme: Newspaper 12.7.5
Plugin: td-composer
Server: VPS Ubuntu — CyberPanel — LiteSpeed

CONTEXT
The site glostv.com uses the Newspaper 12.7.5 theme with the td-composer plugin and has a system of separate pages for mobile and desktop, where each version was built individually in the Newspaper visual editor (tagDiv Composer). The site owner reported that pages on mobile are significantly heavier than on desktop, even though there are separate and optimized mobile pages already built.

MOBILE SYSTEM ARCHITECTURE
The following pages were created as mobile templates inside the tagDiv Composer itself and are marked in the database with the flag tdc_is_mobile_template = 1:

ID 7584 — tv ao vivo Brasil (mobile version)
ID 7617 — POPULARES TOP (mobile version)
ID 8700 — Estados (mobile version)
ID 8872 — Homepage (mobile version)
ID 9944 — Política de Privacidade (mobile version)
ID 9948 — Termos de Uso (mobile version)
ID 10581 — Sobre Nós (mobile version)
ID 10597 — Política de Cookies (mobile version)

TECHNICAL PROBLEM IDENTIFIED
Problem 1 — td-composer loads assets WITHOUT any device distinction

Confirmed directly in the file:
wp-content/plugins/td-composer/legacy/common/wp_booster/td_wp_booster_functions.php

Line 362 — Composer JS loads for ALL devices:
add_action(‘wp_enqueue_scripts’, ‘load_js_composer_front’, 1000);

Line 430 — Full Newspaper CSS loads for ALL devices:
add_action(‘wp_enqueue_scripts’, ‘load_front_css’, 1001);

Line 744 — Full theme JS loads for ALL devices:
add_action(‘wp_enqueue_scripts’, ‘load_front_js’);

None of these functions have any device check. They load for both desktop and mobile equally, without any condition whatsoever.

Problem 2 — The mobile engine loads ON TOP of the desktop engine

Confirmed in the file:
wp-content/plugins/td-composer/mobile/functions.php

Line 149 — Mobile CSS loads ON TOP of the desktop CSS already loaded:
add_action(‘wp_enqueue_scripts’, ‘tdm_load_front_css’);

Line 173 — Mobile JS loads ON TOP of the desktop JS already loaded:
add_action(‘wp_enqueue_scripts’, ‘load_front_js’);

Line 184 — Mobile specific script loads ON TOP of all previous ones:
wp_enqueue_script(‘td-site’, TDC_URL.’/mobile/js/tagdiv_theme.min.js’);

Problem 3 — The flag tdc_is_mobile_template does NOT remove desktop assets

Confirmed in the file:
wp-content/plugins/td-composer/includes/tdc_state.php

Line 42:
private static $is_mobile_template = false;

Line 202:
public static function set_is_mobile_template($is_mobile_template) {
self::$is_mobile_template = $is_mobile_template;
}

This flag only serves to let the visual editor know it is on a mobile page. It does not execute any removal of desktop CSS or JS. It is purely an internal state variable with no effect on asset loading.

Problem 4 — Proof: Zero wp_dequeue for mobile anywhere in td-composer

I ran the following command directly on the server via terminal:

grep -r “wp_dequeue|deregister” wp-content/plugins/td-composer/ -n | grep -i “mobile|desktop|css|js”

The only result found was the removal of Visual Composer scripts in the backend administrative editor, not in the frontend. Throughout the entire td-composer codebase, there is not a single wp_dequeue_style() or wp_dequeue_script() instruction conditioned on mobile device detection in the frontend.

WHAT THE MOBILE BROWSER IS ACTUALLY DOWNLOADING
When a user accesses the site from a mobile device, the browser downloads all of this before rendering the mobile page:

From the desktop engine (which should NOT load on mobile):

Full legacy CSS of Newspaper
td-composer frontend JS (desktop visual engine)
tagdiv_theme.min.js desktop version
td-cloud-library CSS
td-standard-pack CSS
td-multi-purpose/style.css
Desktop version fonts
From the mobile engine (which loads ON TOP of the desktop):

Newspaper mobile CSS
tagdiv_theme.min.js mobile version
Mobile specific scripts
Fonts loaded again
The mobile browser is downloading the complete Newspaper framework twice. Once for the desktop layout that is discarded and once for the mobile layout that is actually used. This directly explains why mobile pages feel heavier and slower than desktop pages. DIRECT QUESTION TO SUPPORT
Does td-composer 12.7.5 have any native mechanism to remove desktop engine assets—specifically the functions load_front_css, load_js_composer_front, and load_front_js located in td_wp_booster_functions.php—when the page being served is already marked with tdc_is_mobile_template = 1 in the database?

If yes, in which file and on which line does this asset cleanup occur?

If no, when is the development team going to release an update to fix this? It is unacceptable that a high-end theme like Newspaper forces a mobile device to download the entire desktop framework AND the mobile framework simultaneously. My server-side analysis confirms that even when using dedicated mobile pages, the theme simply “stacks” assets instead of “swapping” them.

This redundancy is causing a massive performance overhead and killing our Core Web Vitals. We have separate pages for a reason, and the theme should NOT be loading desktop junk on a mobile-dedicated template. We need a clear position on when this will be resolved so that tdc_is_mobile_template = 1 actually triggers a wp_dequeue of unnecessary desktop resources.

UPDATE — April 25, 2026
Significant new findings after deeper DOM inspection. The block is no longer empty, but articles are rendered offscreen.
What changed since my last report:

Yesterday: the block container appeared completely empty — no child modules in the DOM.
Today (verified via browser DevTools): the container #tdi_96 now contains 5 .td_module_flex elements with correct titles, dates, categories, and links pointing to the right posts.
However, the articles are rendered at top: -4729px on the public frontend — far outside the viewport, which is why they remain invisible to users despite being present in the DOM.

Detailed observations from the frontend (incognito, logged out):

Articles ARE in the DOM: confirmed via document.querySelectorAll(‘#tdi_96 .td_module_flex’) returning 5 elements with valid content.
Articles positioned offscreen: getBoundingClientRect() returns top: -4729, left: 20 for the first article. Parent #tdi_96 itself sits at normal page position with height: 234px.
Computed CSS does not explain the offset: position: relative, top: 0px, marginTop: 0px, transform: none, translate: none, inset: 0px — no positioning rule should push the elements offscreen.
No transform on any ancestor: walked up the DOM from .td_module_flex to #tdi_96 — no element has a transform or non-default position.
In tagDiv Composer editor, the block displays correctly — all 5 articles visible with normal layout. The issue manifests only on the public frontend rendering.
Block class on frontend: td_block_inner td-mc1-wrap with el_class=”td-week-slider” set in shortcode.
Image container has display: none (intentional — image_floated=”hidden” in config).
Editor still throws 8x “model does not match content” errors when opening the Homepage in tdc. These persist from yesterday and have not cleared.

Hypothesis:
The block appears to enter a ticker/slider rendering mode on the frontend (consistent with the td-week-slider class), where articles are positioned offscreen waiting for a JS animation that never executes. The editor renders the block correctly because it bypasses this ticker behavior, but the frontend runtime applies it and fails. This may be linked to the persistent “model does not match content” errors.
Concrete questions:

(a) How can I force this block to render as a standard vertical flex list (no ticker behavior) without entering Composer to edit it (since opening the Homepage in tdc shows the model errors)?
(b) Is there a way to clear the model-content mismatch from the database directly (wp_options, wp_postmeta) without going through the editor?
(c) Does the td-week-slider el_class trigger specific JS that could fail silently and leave articles parked offscreen?

I can provide additional diagnostic output from DevTools console if helpful.

No, I don’t get any messages, only when I try to edit the homepage with TagDiv. It simply doesn’t load and gives a 404 error. Similarly, when I try to create a new page using TagDiv, I get the same error. We purchased the theme license in February of this year.

We already installed SSL and the ‘not secure site’ message no longer appears.

Thank you Calin,
here is the situation: https://www.pignetotv.it/wp-content/uploads/Default-PRO-vs-Default-RTL-PRO.png
Above is the “Header Template – Default PRO”, below is the “Header Template – Default RTL PRO”: in the “Header Template – Default RTL PRO” there is a line of code (CSS code) that i don’t see in “Header Template – Default PRO”.
The exact same situation also occurs for “Homepage Template”, “Footer Template”, etc.
Thank you very much for your attention.

I need same layout between mobile templates:

Mobile Homepage Templates
Mobile Page Templates
Mobile Single Templates..

When I modify menu on homepage to be same layout mobile on every template

check attached photo

how to synchronize?

I’m attaching a screenshot that clearly shows the exact <title> tags I’m referring to.
The issue occurs both on the homepage and on individual post pages.
I would really appreciate your help in resolving this problem.

https://postimg.cc/4mWwVV4d