optimalisatie

Hi Prafulla Kumar Sahu,

Thank you for reporting the issue!

In regards to the first question. If you included those files on the exclude list, they should not be included in the async configuration. Could the issue be related to a page cache (not displaying the latest configuration)?

In regards to loading from the footer. The config is placed in the header but loadCSS will be started on domready.

Hi bandish2189,

It appears that there is a conflict with a different plugin. We did not receive a similar report before.

Regrettably, there is not much that we could suggest except for advanced tracing the cause of the conflict.

Thanks a lot for reporting the issue! The issue has been resolved in the latest update.

We’ve commented in your 2nd topic.

Hi bhagawadkrishna,

Thank you for reporting the issue and for providing extensive details!

Regrettably, we did not receive a similar report before.

It appears that the plugin is not loaded on your home page which is why it doesn’t output CSS. It may also be possible that a different plugin overtakes the PHP output buffer.

An option is to copy and paste the query string (?extract-css=cfd55c688b438b9d7a3aacc9cbe91f43&output=download) on a different URL / page to see if the plugin is loaded. The issue may be restricted to your front page.

If you are unable to find a direct cause, it may be best to find an alternative solution to extract the full CSS.

We are developing a new plugin that will provide a robust method for extracting CSS. It will take several months however until it is ready.

I found the following in Google, it may provide a solution:

https://krasimirtsonev.com/blog/article/csssteal-chrome-extension-that-extracts-css

Considering the lack of options, we will try to publish a new solution faster.

Hi Gulshan,

Thank you for reporting the issue! It was caused by an unset option when using the plugin for the first time.

The issue has been resolved in the latest update.

Hi milanparmar22,

By default the critical CSS input field is a CodeMirror editor with CSS Linter that will start linting as soon as CSS is entered. When entering a large amount of CSS or on a low power device this may cause javascript to crash.

You can disable the CSS editor using the option Use a CSS editor with error reporting (CSS Lint using CodeMirror). directly below the Critical CSS editor.

• This reply was modified 7 years, 1 month ago by optimalisatie.

Hi Colin,

Our apologies for the late reply. It is possible to disable the plugin conditionally by defining DONOTABTF in functions.php.

Example:

<?php
define('DONOTABTF', true);

Hi sirtaptap,

Thank you very much for your feedback!

The Service Worker solution has been quickly setup, it will be done with a higher quality in our upcoming Advanced Optimization plugin.

After some research we discovered that the ABTF Service Worker does cache the start_url correctly but that the Google Lighthouse test produced a false negative. Google reports the following regarding the issue:

One shortcoming of this audit is that it inspects the cache contents directly, rather than asking the service worker to resolve the start_url request. This can produce a false negative result if your cache is missing a resource that matches the exact value of start_url, even though in real scenarios the request resolves successfully because the service worker redirects to another resource in the cache. Conversely, the audit can produce a false positive result if your cache contains a resource that matches start_url, but your service worker redirects the request to a non-existent resource.

https://developers.google.com/web/tools/lighthouse/audits/cache-contains-start_url#more-info

We’ve filed a issue at Github:

https://github.com/GoogleChrome/lighthouse/issues/4312

If you have a suggestion for an improvement, please let us know!

The next update will enable to set the cache age (per individual page) so that it will be possible to cache pages on CloudFront for 7 days or more, ensuring that the international cache will be ready when a page receives just 1 visitor per week.

CloudFront simply obeys the HTTP cache headers so it would be possible to control the cache manually as well by setting HTTP cache headers.

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

Hi!

Thank you for your first feedback to this plugin! We apreciate it a lot!

In regards to your question. You should look at cache invalidation an action taken by Amazon to clear the cache of one or more assets (pages, images etc.) on all it’s international nodes. I presume that this process is costly and that it is the reason why they provide a limited monthly budget of 1000 invalidations and charge $0.005 USD per invalidation (a path charged as 1 invalidation could match multiple pages using a wildcard, e.g. /* for all pages or /category/* for pages in a category).

More information can be found in the documentation: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

Dynamic content caching based on cookies

In regards to support for dynamic content based on cookies, e.g. a logged in user cookie, that is possible. CloudFront provides options to fine grain caching behavior using advanced settings. It is possible to cache based on cookies, HTTP headers and query strings so that it supports selectively caching of dynamic
content for the same page URLs. There are no extra costs for this feature.

Hi Emilybkk,

Thank you very much for your feedback!

The critical CSS management system will be completely redone in the next update of the plugin. Your request for URL based selection of pages will be considered for the new system.

Hi antforshaw,

Thank you for your feedback! The described problem is not a bug.

When using the proxy for stylesheets any relative paths within the CSS will be broken. The proxy does not modify CSS, it only serves the content from a local cache URL.

To prevent font awesome from being proxied it is possible to enter a part of the URL (e.g. simply fontawesome) in the proxy exclude list.

To resolve the leverage browser caching issue in Google PageSpeed Insights it may be an option to include the font awesome code in the critical CSS (we usually create a conditional critical CSS entry with the “append to any” option enabled specifically for fonts). As font awesome is very big, it would be best to specifically include the parts that are used on the website. You should then remove the font awesome CSS from the page. This could be done with the Remove List option on the CSS optimization settings.

Please let us know if you manage to resolve the issue!

Thank you for your feedback!

The issue will be resolved in the next update.

The proxy checks for HTTPS support using the PHP $_SERVER variable HTTPS. It appears that there are some servers where this variable is undefined.

https://stackoverflow.com/questions/1175096/how-to-find-out-if-youre-using-https-without-serverhttps

The issue will be resolved in the next update of the plugin.