Site significantly slower with Advanced CSS/JS Aggregation enabled

Means the css file is not getting generated... what sub modules are enabled and give the latest dev of advagg a try. I'll be releasing RC-5 fairly soon.

Bundler is a tradeoff between the first page load time and page load times of pages 2-10+. See #1158740: Defer parsing of JavaScript for some explanation.

Are you still getting the redirect issue with your CSS?

on a page that is throwing the redirect issue, can you do an ?advagg-debug=1 on it, grab the output from watchdog and attach that as a file here.

if you do ?advagg-debug=1 on that page that is generating the loop it should dump about 100kb of debug data in watchdog.

it's a permissions issue on that site. ?advagg-debug doesn't work if you don't have the correct permissions to run it. admin/user/permissions look under advagg module and check the "bypass advanced aggregation" box that corresponds to the correct role for your user.

my 50 cents

don't have time to fix, but maybe this feedback will be helpful

1. if you are using colorbox module - there is inline js setting connected with "Next >" and "< Previous" buttons.
It looks like this: "« Prev" "Next »", those little utf arrows Polish character "ę" (maybe other national utf characters too) prevents Drupal from displaying debug information in /admin/reports/dblog
possible solution: "nl2br(htmlentities(print_r($data, TRUE))));" in advagg.module is not a good idea

2. if you are using colorbox module and Advanced CSS/JS Aggregation/ JS Compression -> Enable packer, advagg cannot regenerate js_* related to colorbox files - it falls in loop
possible solution: turn off Enable packer or advagg should check if packer works like it should

3. if you are using Tao base theme, Tao overrides some core drupal styles, it does it by defining *.css files in it's own tao.info, but those files does not exists in theme folder - they don't have to, tao just needs override, but at some point advagg canno regenerate css_* files - it falls in loop
possible solution: create empty css files in tao direstory or advagg should aggregate virtual empty files

other than that my site is cutting edge fast :)

You probably did, but... It's tricky

After disabling colorbox module, and removing definition of non existent css files from Tao info file, please:
1. Manualy empty 5 advagg MySQL tables (not using advagg module button, but by SQL command). Tables are: advagg_bundles, advagg_files, cache_advagg, cache_advagg_bundle_reuse, cache_advagg_files_data
2. On advagg administration pages click "Rebuild AdvAgg Cache"
3. Optionally empty browser cache.

Then please check if problem with looping still persists.

hmmm... more general tracing:

1. Look for the page that is looping
2. As a user with right permission (ie. admin) add to the end of URL "?advagg-debug=1" to force debug dump
3. At the same time using Firebug (Firefox plugin) in tab "Net" look which css/js file generates looping (307 redirect)
4. Let's say the filename is "css_7456....css", at /admin/reports/dblog/debug dump - look which files are aggregated into "css_7456....css".

I know it's not a fix, but it gives you good start point to track problematic css/js files. At least You know which modules gives you headache.

At my instalation those were css/js files related to theme/module from my previous comment. Now my site works brilliant.

Got part of the solution to the missing file issue and the bundler. The main issue is if the bundler decides to place a file that is missing in it's own bundle or the bundle contains all missing files then advagg will try to write an empty file. If that is the case, advagg will not write the file to the filesystem. In order to prevent this issue from occurring in most cases, I will now bundle missing files with a bundle that has actual files.

The other part of the solution has to do with only 1 file being used in the aggregate and that is missing; example is print.css. In this case I need to have a special empty css file that I can reference to. Call it css_00000000000000000000000000000000_0.css (make it pass the MD5 filter with all them 0's so the file gets cached for a year on the clients browser).

This patch addresses the first case; working on a good solution for the 2nd case. Issue being, if the missing file is added, that file now needs to be included in the aggregate and advagg needs to not use the special empty css/js file case. This special case doesn't account for all potential uses, async with the css_emimage module comes to mind; in that case I will continue to save an almost empty css file. But I do have to take into account other async issues so I will need more logic in the code that advagg.missing.inc runs.

This patch has been committed. Leaving issue open, will mark as "fixed" when I address case #2.

Going to mark this as fixed. With this patch, Advagg should now be able to write an empty file and not throw a fit about it, going off and deleting the empty file (this behavior is to get around potential issues with directly writing to S3 if you where wondering). I've added in some checks that sill account for the S3 issue and isn't dumb like it used to be. The empty file (css_000...000_0.css) doesn't work because of the async mode.