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

[Ben Lobaugh]

I agree to disagree!

*snicker*


On 1/2/13 3:46 PM, Mike Schinkel wrote:
> 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? :)
>
> -Mike
>
> 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.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers