Search Results for 'optimize'

Results from the Forum
Simion C.
tagDiv Staff

Hi,

That’s probably caused by the caching or the optimization. Depending on which plugin you use, I suggest checking options that optimize the CSS. Try disabling CSS related optimization options from the plugin you are using to see if the issue is solved.

I don’t think I’ve seen such an issue before, so I’m not sure why this happens or what to suggest exactly. It is a bit strange that it’s affecting only the homepage.

I’ll check the page more and if I find something I’ll let you know.

Thank you!

Atyllo
Participant
#0

Hi,

First of all, thank you for your previous reply regarding Flex Blocks and background images.

I’m trying to optimize my website as much as possible for Google’s Core Web Vitals, especially on mobile, and I’d like to make sure I’m using Newspaper in the best possible way.

My website is:
https://actugeekgaming.com/

My latest PageSpeed report:
https://pagespeed.web.dev/analysis/https-actugeekgaming-com/aomr1s8vst?form_factor=mobile

At the moment my mobile score is around 50–60, and I’d like to improve it significantly while keeping Newspaper if possible.

Here is what I’ve already done:

Removed the homepage video background.
Replaced the hero section with a normal image.
Optimized all featured images.
Enabled WP Super Cache.
Enabled Jetpack CDN.
Upgraded to PHP 8.2.
Removed unnecessary plugins.
Added preload for the LCP image.
Contacted support regarding Flex Blocks using CSS background images.

I understand that Flex Blocks use background images by design, and you’ve suggested creating a custom Module Builder template using an element instead.

Before rebuilding my homepage, I would like to ask a few questions:

1) What are the official Newspaper recommendations for achieving the best possible Mobile PageSpeed score?
2) Which homepage modules or blocks are the most performance-friendly?
Are Flex Blocks still recommended for the first visible section, or would you recommend using a Module Builder layout instead?
3) Are there any Newspaper or TagDiv Composer settings that should be disabled to improve Core Web Vitals?
4) Do you have a performance optimization guide specifically for Newspaper?
5) Do you know of any websites using Newspaper that consistently achieve 85–90+ Mobile PageSpeed scores?
If so, could you share a demo or explain what makes them different?
6) Apart from replacing Flex Blocks, is there anything else inside Newspaper that commonly hurts LCP or overall mobile performance?

My goal isn’t simply to increase the PageSpeed score, but to build a fast, modern news website while continuing to use Newspaper.

Thank you very much for your advice!

Simion C.
tagDiv Staff

Hi,

That’s the perfect result. Litespeed is indeed a very good, and most importantly free alternative, to WP Rocket. For website owners who wants to optimize the website and achieve the best result, every tip and small detail matters.

Thank you!

Simion C.
tagDiv Staff

Hi,

That’s correct. In the backend the page content is made out of shortcodes. The content can’t be analyzed there. It can be analyzed in the frontend where the content is actually displayed, via live page scanners if available in the SEO plugin, browser extensions or other tools.

I see that the SureRank Pro plugin has a frontend page analyzer -> https://prnt.sc/FMClw5C5g3tS This is quite a nice feature, and will allow you to actually analyze and optimize the page based on the content it displays on the website. Those are the same settings that are available in the backend. So you could optimize pages from the frontend.

Thank you!

Paniki2300
Participant
#0

Hello guys,
When I create a new page or post, I use the SureRank Pro to optimze my SEO. It has worked fine on other themes, but since pages and posts are created in TagDiv Composer, the WordPress Editor is full of Tagdiv codes, to provide the expected layout on the frontend.
But this gives me an issue with my SEO plugin, as it cant find relevant keywords and more when trying to optimize the content, due to the code in the editor.

– So how can I optimze the content, using this plugin to ensure the relevant SEO optimizations?

Please see this screenshot:
https://e.pcloud.link/publink/show?code=XZ3kicZufVz5AbanefmuDPmu0YVjkjQLbRk

Cheers!

Simion C.
tagDiv Staff

Hi,

The issue with the sticky sidebar could be caused by optimization plugins, especially if it works when you check logged in, but not when logged out. I see you are using WP Optimize and maybe also Perfmatters. I suggest to deactivate these temporarily, then check if the sticky sidebar is working correctly for the website visitors.

The other issue is probably unrelated and could be caused by security plugins, or maybe object caching. If there is code there in the theme panel, but after modifying and saving the old code is still there, it’s most likely object caching. Besides Perfmatters and WP Optimize is there another cache active on the website, like Redis perhaps? Or maybe something from the hosting/server.

Thank you!

Simion C.
tagDiv Staff

Hi,

Sure, I’ll take a look and try to provide suggestions. I believe this is your website https://product-strategist.com/

I checked a few post pages and for me the loading speed is usually below 1 second https://prnt.sc/k0jMr6tL1b_Z That’s certainly not very slow. I see you are using Litespeed which is a very good plugin. You could try the option to delay the JS https://docs.litespeedtech.com/lscache/lscwp/pageopt/#js-settings-tab this one here https://prnt.sc/-qSiTgI_hUMf which would make it faster, but it could also cause problems with how the page looks or works, please test it carefully.

The images are optimized and they are lazyloaded, which is very good.

One suggestion I would make is to delete the standard pack plugin -> https://prnt.sc/ARUZDej2rw2C this is not required for the theme demo you installed. Deleting it it stops resources from it from being loaded unnecessarily.

Maybe also try delaying the loading of the mega-menu, there is an option for that -> https://prnt.sc/y0F9L98R-gEf
Also try delaying the loading of the footer -> https://prnt.sc/hGvAdiY8wm3I

If you try a few of these there should be improvements. But there could also be issues, so please test carefully.

Thank you!

Simion C.
tagDiv Staff

Hi,

The website is very slow, as if the caching is not working at all or something is consuming all the website resources. Looking at it with the browser inspector the page appears to be cached by WP Optimize. I’ve used this plugin before and the website should be much faster with it.

I noticed that there are a lot of admin ajax requests made by the Ad rotate plugin https://prnt.sc/iTqlq3PQCXq7 I believe those requests are related to this setting from the plugin https://prnt.sc/VwTLdQuvYk4S which is and was known for causing serious problems with the website performance. I suggest testing to see how the website loads without this plugin. Make a quick test, deactivate it, clear the cache, then check the website. Or disable the stats tracker and test https://prnt.sc/vAgJ7054BkTT

If the situation is the same, it must be something else. In that case I suggest to send us an email at contact@tagdiv.com and provide access to the website, so we can take a closer look.

Thank you!

Davidjurado
tagDiv Member

Hi Calin,

Thank you for your response. I have already tried the revisions and even installed a completely new template from the Cloud Library, but the ‘6 zones vs 0’ error persists. My hosting provider has also optimized the server (PHP limits, LiteSpeed, and ModSecurity disabled), but we haven’t found a solution.

As you suggested, I have just sent an email to contact@tagdiv.com with the subject: ‘URGENT: persistent “Layout sync error” (6 zones vs 0) – sportlifeathletes.com’.

In that email, I have provided the WP-admin and hosting credentials so your team can investigate the backend. I look forward to hearing from you there.

Best regards,

David

Reyking74
Participant
#0

I am experiencing a persistent Facebook Sharing Debugger / Open Graph issue on a website using the Newspaper theme by TagDiv:

https://www.serenissima.news/

The Facebook Debugger consistently returns HTTP 403 and fails to properly retrieve Open Graph metadata from article pages.

Before suggesting generic hosting/firewall checks, please note the following:

  • I manage the server myself (DirectAdmin environment).
  • The server hosts many other WordPress websites on the same IP address and same Apache/PHP stack.
  • Those websites share correctly on Facebook and pass Facebook scraping without issues.
  • The issue is isolated specifically to this Newspaper installation.
  • Technical context:

  • Apache 2
  • PHP 8.3
  • WordPress 6.9.4
  • Newspaper 12.7.6
  • No external CDN or proxy layer involved
  • What has already been verified:

  • Firewall / CSF / LFD are not blocking Facebook crawlers.
  • robots.txt is not blocking facebookexternalhit.
  • Caching plugins have been removed/tested.
  • Database cleanup and wp_options optimization performed.
  • Theme Plugins were temporarily disabled for testing purposes.
  • Other websites on the same infrastructure continue to work perfectly with Facebook Debugger.
  • Important observation:

    Another WordPress site (mine, personal) hosted on the exact same server successfully returns proper Open Graph data and is scraped correctly by Facebook.

    This strongly suggests the issue is related either to:

  • Newspaper header rendering,
  • TagDiv metadata generation,
  • dynamic template output,
  • or crawler-specific behavior triggered by the theme stack.
  • The Facebook Debugger currently retrieves incomplete OG data and sometimes only partial metadata such as:

  • og = domain name only
  • missing og
  • missing og
  • Could you please provide technical insight specifically related to Newspaper/TagDiv behavior with Facebook crawlers, rather than generic hosting or firewall suggestions?

    Thank you.I am experiencing a persistent issue with Facebook sharing/scraping on my website serenissima.news, which uses the Newspaper theme by TagDiv.

    I have already performed a deep cleanup of the database and verified the server configuration. Before suggesting the usual “contact your hosting provider to whitelist Facebook in the firewall,” please consider the following:

    I am the hosting provider. I own and manage the server (DirectAdmin based).

    The firewall is NOT the issue. There are dozens of other websites on the same server (same IP) that share perfectly on Facebook without any blocks.

    The issue is site-specific. Only the installation using the Newspaper theme is failing to provide the correct metadata or is being blocked/rejected during the scrape.

    What I have checked so far:

    Metadata: Standard OG tags are present, but the Facebook Debugger is not pulling them correctly.

    Plugins: Performed a cleanup of caching plugins (WP Super Cache removed) and optimized the wp_options table.

    Isolation: As mentioned, other sites on the same server work flawlessly, ruling out any server-side IP blacklisting or Firewall (CSF/LFD) interference.

    I suspect there is a specific conflict within the theme’s header output or a built-in SEO/Open Graph setting in TagDiv that is clashing with Facebook’s crawler.

    Please provide technical insights that don’t involve “whitelisting” as that has already been ruled out.

    PolishExpress
    tagDiv Member

    Hi,

    I need to clarify something important regarding Google Discover requirements.

    Google Discover has a strict rule: the featured image in the HTML must be ≥1200 px.
    If I select 696 or 1068 in the Single Post Mobile Template, the HTML will not contain an image ≥1200 px.
    As a result, the article may not be eligible for Discover.

    This means that the recommendation to use smaller thumbnails (696 or 1068) might be good for PageSpeed, but it is bad for Discover eligibility.

    For publishers who rely on Discover traffic, the only safe option is to keep Full – 1920 px in both desktop and mobile templates, and then optimize loading via srcset, WebP, or lazyload plugins.

    Can you please confirm officially:

    Does the Mobile Template still include the 1920 px version in the HTML srcset when a smaller size is selected?

    If not, how can we guarantee Discover compliance without sacrificing performance?

    Thank you!

    Calin
    tagDiv Staff

    Hi RENATO,
    I understand that this situation is frustrating.
    From what I can still see, the cache does not appear to be functioning correctly. Since I do not know the exact configuration or behavior of LiteSpeed Cache (and this is not a tested plugin), I cannot confirm whether the issue is directly related to that plugin, server-side cache, CDN configuration, or another caching layer. There are multiple possible factors involved.
    At the moment, the mobile page you created with fewer blocks, smaller thumbnails, and more optimized content should normally provide significantly better mobile performance. However, because the dedicated mobile version is not loading, visitors are instead receiving the responsive desktop version, which is heavier and not fully optimized.
    Unfortunately, there is not much more I can assist with from the support side. I have already provided all the recommendations and guidance available, even though performance optimization and PageSpeed improvements are outside the standard scope of support. We still did our best to help, despite the fact that the support period has not been extended for more than 8 years.
    If you would like this issue to be investigated further and fully resolved, I recommend submitting a custom work request to services@tagdiv.com. Please include all relevant details and temporary wp-admin and cPanel access. The team responsible for custom services will review the situation and let you know what can be done, along with the associated costs.

    Thank you for your understanding.

    simchris
    Participant
    #0

    HI
    weird one. Not using caching plugin (only autoptimize), and cleared that entirely. Restarted PHP, remove template (loads to no posts). Uploaded again. Fully disabled autoptimize.

    Still getting the default 404 message (oops…).

    Stumped.

    RENATO
    tagDiv Member

    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.

    EWP
    Participant
    #0

    Hi tagDiv team,

    I have a Flex Block 1 (configured as “Latest news” widget in the homepage left column)
    that renders empty in the frontend but displays posts correctly in the Composer editor preview.

    DETAILS:
    – Theme: Newspaper v12.7.5 (REGISTERED)
    – Demo installed: Newsweek PRO
    – Site: https://eurowaypoint.com
    – WordPress: 6.9.4
    – PHP: 8.2.30

    THE PROBLEM:
    – In Composer editor: the Flex Block 1 shows the latest 5 published posts correctly
    – In frontend (incognito browser, logged out): the block container is generated
    (div id=”tdi_96″ class=”td_block_inner td-mc1-wrap”) but completely empty —
    no child modules are rendered inside
    – 24 published posts exist in the database
    – Other blocks on the same homepage (Big Grid Flex 1, other Flex Block 1 instances)
    work correctly and display posts
    – No JavaScript errors in browser Console
    – The block has no special filters configured (Category: All, all filter fields empty)

    WHAT I’VE ALREADY TRIED:
    – Cleared all caches (SiteGround, WP Super Cache disabled, browser hard reload)
    – Restored Homepage from a 3-day-old revision (no improvement)
    – Disabled all third-party plugins one by one (Wordfence, SG Optimizer, etc.)
    – Verified block configuration in Composer (Filter tab, Layout tab — all default/empty)
    – Forced re-save of the block (changed limit number and saved)
    – Removed custom CSS that contained :has() selectors

    WHAT I NOTICED:
    The block was working until I made some modifications today (changed page slug from
    /plans/ to /newsletter/, edited some HTML custom blocks for Subscribe links).
    The Latest block stopped rendering at some point during these changes.
    Restoring an older Homepage revision did NOT fix it.

    Could this be a corrupted block state in the database? Is there a way to reset
    the block’s internal cache or regenerate its configuration?

    Thank you for your help.

    Calin
    tagDiv Staff

    Hi,
    There will be a need to make the improvements for the list provided on the Pagespeed test.
    Also, for speed, if you are using the WP Super Cache plugin, make sure that you also use the Autoptimize plugin and CDN . There are also other cache plugins that can be used to do both caching and optimizing the site, so there is no need to have 2 plugins. For example, one of the best is WP Rocket, but you can also use free plugins like WP Optimizer and Litespeed.
    Thank you!

    Calin
    tagDiv Staff

    Hi,

    1. There is no official minimum word count for Google AdSense approval. Quality, originality, and usefulness matter more than word count. However, most successful applicants publish: 600–1200

    2. To create high-quality, valuable content using the Newspaper Theme, follow these best practices:
    – Use clean, readable layouts – Choose simple templates and avoid clutter.
    – Focus on in-depth, original content – Publish well-researched articles (800–1,500+ words).
    Optimize typography and spacing – Make text easy to read on desktop and mobile.
    – Use high-quality images and media – Add relevant visuals to support your content.
    – Structure properly – Use headings (H1, H2, H3), bullet points, and short paragraphs.
    – Improve SEO settings – Optimize titles, meta descriptions, and internal linking.
    – Ensure fast loading speed – Avoid too many ads or heavy plugins.
    – The key is combining strong content with a clean, user-friendly design.

    3. The TagDiv Composer will be used to create pages and templates, but not posts, for posts will be used the wordpress editor (Gutenberg or classic editor) – https://www.youtube.com/watch?v=SoGQ0d5kIBg

    Thank you!

    Calin
    tagDiv Staff

    Hi,m
    I just checked the website and this is taking quite a long time, even when you access an article for the first time – https://prnt.sc/8jYsXbLsEYIX what is strange is after some time when I checked a few articles, the website starts to load ok (maybe until teh cache starts to work) adn now even the videos load ok https://prnt.sc/yNgXpWg5n0l6
    In this situation is possible that the situation to can be impoved with a better cache plugin, optimize, css and js, images and the results should be better

    Calin
    tagDiv Staff

    Hi,
    Right now, the lazyload should be enabled only in EWWW Image Optimizer exlude the element using this field – https://prnt.sc/z3c1Wk5I8KP1 add there:
    tdb-featured-image-bg
    tdb_single_featured_image
    make sure each one is on a new line.
    I hope this willl help

    Calin
    tagDiv Staff

    Hi Marc,
    I just checked the website, and this seems to be working ok for visitors. Also, I see that you are now using the LiteSpeed Cache plugin.
    Now, related to the page speed results, this depends on factors like page dimensions, images, external resources, and cache…
    UNfortubatley becouse the latespeed is not a tested pluginwe can not say for sure what option to enable and what option to disable to get a better performance, but let’s start with general pagespeed settings:
    – convert images in webp format (there are cache plugins that can do this, but if the Litespeed is not doing this, the EWWW Image Optimizer can be used https://prnt.sc/DzMY6YynebbI). Make sure that only a lazyload option is enabled (the theme has an option https://prnt.sc/4pqTwHya8Awa and most likely other plugins that optimize the image to have the option)
    – enable this theme option – https://prnt.sc/Ir7qNRhstgSAhttps://prnt.sc/k2M5pc8odE1D (AGGREGATE INLINE CSS option needs to be tested with teh cache plugin)
    – disable the mobile header on desktop and desktop header on mobile (this can be done for the sticky headers, but make sure that the mobile cache option is enabled – https://prnt.sc/r3QB7-vZ4UzH https://prnt.sc/KBdRK8nc90UW
    – on mobile simply disable the mobile sticky menu https://prnt.sc/IFe6OfBzige7 and select the regular menu and set it to be sticky, also make sure that you have set a background color for it – https://prnt.sc/I6G0kypEakOM
    – use an object cache (Redis or Memcached)
    – use a CDN like Cloudflare

    I hope those first steps to help you to get a better speed.

    Calin
    tagDiv Staff

    Hi,
    The combination of settings that you should try is:
    For the theme settings under the block settings> thumbs on modules enabled the webp format – https://prnt.sc/JugAEpW8CwAv, then from template settings > image loading / layzload disable the lazyload – https://prnt.sc/4pqTwHya8Awa
    Use those settings from ewww image optimizer – https://prnt.sc/DzMY6YynebbI
    Then the WP Rocket can be set as in our guide https://forum.tagdiv.com/wp-rocket-and-newspaper-theme-optimization-guide/ but the lazyload option should be disabled
    I hope this will help you!

    cyberlab
    Participant
    #0

    Good afternoon
    We have the following installed on our website

    – Advanced Media Offloader for uploading images to R2
    – EWWW Image Optimizer for image optimization and WebP creation
    – WP Rocket
    The question arises
    how to properly configure WebP
    and which module should integrate WebP into the template and which of them should properly load images?
    1/ Who should properly load images
    EWWW Image Optimizer or
    WP Rocket or the template itself?

    2/ Integrating images into the template
    include them in the site theme and include them in
    EWWW Image Optimizer?

    3/ How to properly configure all 3 modules for correct operation, especially if all images are in R2 to speed up site loading

    Calin
    tagDiv Staff

    Hi,
    Yes, those are theme-related. What can be done is to use a cache plugin like WP Rocket (or similar) and the results inpagespeed wil be improved.
    Those files are necesary becouse are containg the theme cs and js, but with a good cache pluginor optimize css and js plugn, those can be optimized and get better performance in Pagespeed.

    thalesbrandao
    Participant
    #0

    Good evening.

    I’m analyzing our website on PageSpeed ​​Insights and two references with high transfer rates appeared – links below. Could you clarify what they are? One of the links refers to – Magnific Popup – v0.9.9 – 2013-12-27. Are these theme structures – can they be deleted or optimized? Thank you very much.

    https://www.cidademarketing.com.br/marketing/wp-content/plugins/td-composer/legacy/Newsmag/js/tagdiv_theme.min.js?ver=5.4.3.5
    https://www.cidademarketing.com.br/marketing/wp-content/plugins/td-composer/legacy/Newsmag/assets/css/td_legacy_main.css?ver=dabc3295375a4d2df3fc2a20843da2d5

    Thanks

    Calin
    tagDiv Staff

    Hi,
    I think that I know what the problem is, it uses a thumb for the image, and this, I think, is smaller 96×96 – https://prnt.sc/jVEU89qufbXg. In this situation, it is possible to be an extra plugin on your website, forcing the images to a smaller dimension to deliver an optimized image.
    I just did a test on my install and for me the author avatar is changing when I change the size – https://prnt.sc/iPfS2Ea-opAKhttps://prnt.sc/kn7dJDbfn39y

    Viewing 25 results - 1 through 25 (of 4,409 total)