Hi Kathy,
as the file is called with the function get_bloginfo('url'), it should automatically have the https adress of your blog. The problem with the redirect and long loading time is not your htaccess rule. It’s the rewrite rule of the plugin’s css file: add_rewrite_rule('a5-framework-frontend.css', 'index.php?A5_file=wp_css', 'top');
I make use of dynamical CSS, built in php and cached in the options of the plugin (in order to not build it over and over again). However, the redirection from the virtual file name to the query seems to take time.
I found that you save the most loading time by just writing the CSS inline instead of using the virtual file.
I hope that helps.
Best,
Stefan
Hi Stefan, thanks for your response… looking at the issue w/ Kathy’s site a bit more closely shows that the issue actually is that the initial request looks like:
https://sub.example.com/a5-framework-frontend.css?ver=1.0%20beta%2020160127%20FCW
which yields a 301 to
https://sub.example.com/a5-framework-frontend.css/?ver=1.0%20beta%2020160127%20FCW
which yields a nice 200 – the difference seems to be the trailing forward slash before query string…
You can see an archived waterfall showing the above on a live site at pingdom tools =)
We have altered the code at line 132 in A5_DynamicFileClass.php to include the trailing forward slash and now achieve a nice 200 response upon initial page load…
$file = (false === get_option('rewrite_rules')) ? '?A5_file=wp_css' : '/a5-framework-frontend.css/';
thoughts?
Cheers, Max
[edit: we are moving to use HTTP/2 and inlining is not a best practice for performance optimization in such context.]
Yes, one thought: How stupid can I be? 😀
I was looking into the exact same thing the other week with pingdom. I just overlooked the bloody trailing slash.
And one thing to say: Cheers! Thanks a lot for sorting this out for me, Max.
It’s thanks to people like you that my plugins seem to be good. 🙂
Cheers, Stefan
