[wp-hackers] Plugin conflicts with latest version of Jetpack

Mike Schinkel mike at newclarity.net
Wed Jan 2 23:46:56 UTC 2013

Hi Otto,

Thanks for clarifying.  I've learned from this thread and with clarification I think we mostly agree in principle but disagree a bit in the best way to optimize. But then that's okay as we each get to choose what works before for ourselves, right? :)


On Jan 2, 2013, at 6:36 PM, Otto <otto at ottodestruct.com> wrote:
> On Wed, Jan 2, 2013 at 11:45 AM, Mike Schinkel <mike at newclarity.net> wrote:
>> If I do an HTTP request using a free Mac tool called HTTP Client I get these headers:
>> Content-Length: 9216
>> Date: Wed, 02 Jan 2013 17:02:37 GMT
>> Server: Apache
>> Last-Modified: Sat, 22 Dec 2012 09:21:13 GMT
>> Accept-Ranges: bytes
>> Connection: close
>> Content-Type: text/css
>> That is on a bog-standard CPanel install without a caching plugin.  As you can see, no Expires header.  Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?
> If you're telling me that you think most servers are not configured
> appropriately for serving real-world content, then you'll get no
> argument from me.
> The "default" setup is never the optimal one. You need to be
> configuring your webserver correctly first, before you ever try to
> optimize your code or your content. If you're not serving
> appropriately from the ground up, then you're not doing it correctly
> from the starting line.
> A server should be configured to send correct caching headers for
> static content (which, note, is served *outside* of WordPress).
> Cache-Control. Expires. Maybe Etags if you're having issues (but
> generally ETags isn't worth the trouble). These are basics which all
> sites should configure appropriately before serving a single byte. And
> you can do this via .htaccess or nginx config files, no problems.
> I agree that most sites do not have this configured appropriately. But
> I don't agree that you should make your plugin slower and more complex
> by assuming this to be the case. The principle of KISS applies here:
> Keep the plugin simple and doing things appropriately.
> Yes, it is not particularly optimal to output a CSS link on every page
> (or even a JS link, for that matter). However, it is far simpler, and
> the workarounds to make the system smarter about it are complex and
> can cause incompatibilities if done incorrectly. And in a case where
> the system has been properly optimized, the workarounds cause no
> significant real-world gain.
>> On the other hand would you not agree that an Expires header does not help with the first page load
> Speed is important, but it is not the end-all be-all of the world of
> the World Wide Web. Simplicity matters too. Ease of development. Ease
> of use. Compatibility. If you have a non-optimal site, then optimizing
> it is a good thing, certainly. If you're writing a plugin, then making
> it more complex and more difficult to maintain and more incompatible
> with other things, in order to shave a millisecond or two off
> somebody's non-optimized site load time... probably not worth it.

More information about the wp-hackers mailing list