IPB 4.0 Performance Feature Requests

[MGBrose]

I'd like to start this topic to get some discussion going on how we'd like to improve IPB 4.0 out of the box performance. Please don't move away from this topic focus (other 4.0 requests should be placed in a separate thread)

These aren't necessarily ordered in order of importance, but

1) Better CDN Compatibility with versioned css/js filenames:

Current Setup:

The current cache url often won't change after you make edits to css/js, which means for us using CDN's that are "pull" cdn's like amazon cloudfront have a bit more difficulty getting fresh files pushed out properly. Push CDN's shouldn't have much of a problem, but pull is probably just as common (if not more common than push).

Right now here is what I have to do manually, every time I update a theme to get maximum benefit from CDN's.

for include js/include css files within a theme:

<if test="csstominify:|:$this->settings['use_minify'] AND count($this->minify)">
		<link rel="stylesheet" type="text/css" media='screen,print' href="{$this->settings['css_base_url']}min/index.php?ipbv={$this->registry->output->antiCacheHash}my_v01252013-2&amp;f={parse expression="str_replace( $this->settings['css_base_url'], PUBLIC_DIRECTORY . '/', implode( ',', $this->minify ) )"}" />
	</if>

for more details here is the full writeup I wrote on Amazon CloudFront IPBoard setup and file versioning: http://community.invisionpower.com/resources/articles.html/_/server-resource-management/cdn-minify-guide-r625

I have to insert my own custom date perameter to show myself

A) when the filename was last changed/updated on the cdn and

B) to have a fresher cdn content

How Versioned Filenames would improve it:

Versioning for certain CDN's like Amazon Cloudfront is far quicker and easier than trying to purge old CDN data. And honestly doing that for 3 themes (2 regular themes, and 1 mobile) everytime I implement custom changes is becoming a huge hassle.

File Versioning css/js will make IPBoard overall out-of-the-box more CDN friendly.

2) Official support for Varnish or Nginx Cache

This one might be a pipe dream, but official support for one of these would be really nice. It would greatly reduce the hassel of running one of these systems, and possibly give us all performance benefits beyond our wildest dreams :)

Purge Header integration should would be ideal (at a bare minimum), their are plugins for this like nuno's but I think most performance junkies would agree this should be integrated with the core.

3) Responsive Desktop/Tablet (mobile still should be treated separately though)

Responsive makes sense for desktop and tablet, but for mobile, responsive designs often can hurt performance and user experience. Unless responsive is done perfectly (in a way where it was far less http requests than our current mobile theme) it will be best to keep IPB mobile themes.

Mobile is especially sensitive to # of http requests, and request sizes. Despite 4g growing in availability we need to think 3g compatibility /optimization for smartphones.

4) A light(er)weight default mobile theme

Roughly 1/3rd or 30-35% of internet traffic is from mobile devices now, we should respect that by offering the highest performing mobile theme we can to IPB communities.

The mobile theme has been much improved over previous versions, but it can and should get even better.

• Symbol Fonts > Images Sprites Any necessary icons should evolve away from sprites and into Symbol Fonts(current optimization trend, where you use vector fonts instead of images to conserve bandwidth, which is especially important for mobile users) with CSS applied to color and stylize them.
  
• Image Compression: All pngs should be compressed with png-outi (ideally no images for a mobile theme all css) I was able to save about 35 kb by compressing existing mobile images with pnggauntlet mobile_ipb_default_vs_optimized_images.zip
  
• All Mobile Theme Images should be sprites: All PNG’s/Images should be in a single sprite image (again ideally no images, symbol fonts is best) More specifically rarrow.png, f_unread, f_read, should all be in spirtes.

5) Responsive Image Scaling

Instead of setting a single resolution for thumbnails or images that are uploaded, it would be awesome to set it as a percentage of content space available for the image (up to 100%% max, and would never scale beyond original image size).

6) Lazy Loading

Nuno made an excellent plugin for this, which I'm currently testing compatibility with of IE 8 (the oldest version of IE I'm still seeing significant traffic on), if applying this technology is compatible with all major browsers IE 8 and newer, we should see excellent performance benefits here, especially for forums that are image/media intensive.

I look forward to other performance junkie input. I'm going to try to rope in some of the other IPB Optimization pro's into this thread.

[bfarber]

Some of these ideas aren't bad, but are a lot more challenging to support in an out of the box scenario than you might think.

[MGBrose]

Some of these ideas aren't bad, but are a lot more challenging to support in an out of the box scenario than you might think.

Thanks I appreciate that input!

if I could get any one of them, I'd take the CDN fix though. It would save me the most time, and is a pretty simple fix!

[TSP]

Some of these ideas aren't bad, but are a lot more challenging to support in an out of the box scenario than you might think.

Could you give more insight into what you consider to be challenging and not?

We would like Varnish cache support.

With regards to the cachebust-stamp on js and css-files, that could probarbly get changed to a new timestamp every time the skin was changed and/or recached.

[bfarber]

Could you give more insight into what you consider to be challenging and not?

We would like Varnish cache support.

With regards to the cachebust-stamp on js and css-files, that could probarbly get changed to a new timestamp every time the skin was changed and/or recached.

Sure

1) Better CDN versioning could be done, and I would like to do this as well. Seems it would just be a matter of appending the timestamp as you mentioned to the anti-cache key in the URL.

2) Officially supporting Varnish or nginx can be challenging since people can configure their servers in different ways. There is also the "official" title to deal with to (if anything went wrong and we offered official support, we'd be obliged to help solve the problem). There have been community-based feedback on how to do this already, so I'm not too sure what would be needed on our end to boot.

3) We are considering a responsive design for 4.0. It would include the mobile interface as well, however.

4) Image compression is not a problem and we do that periodically, but really saving a kb here or there amounts to very little in the scheme of things for most sites. Using symbol fonts and image sprites is NOT simple for the average admin (or even skinner) to use, so this is not an easy thing for us to incorporate into a base release. Nothing stops you from doing it now though with your own skins.

5) While I understand the suggestion, this doesn't really pertain to performance improvements.

6) Interesting concept, but not sure how necessary it is in most cases.

[Stritix]

These are my suggestions:

It would be nice if administrators could remove warnings from users warning history. While you are currently able to remove the warning points, you are unable to remove warning messages which are permanently stuck with user accounts.

If it's possible too, it would be nice if administrators could clear name change history.

[Dmacleo]

would like to see actual nginx webserver supported, really just provide a rewrite rule for it and its good.

yeah proxy nginx to apache is good for some but I am liking just using nginx w/o apache.

then varnish cache in front would be nice.

you know, all the cool stuff the cool kids play with :P

[Dmacleo]

actually the cdn versioning is something I would have expected you guys to be looking at now (for 4.0) as you are running (as a provider) cdns.

[Makoto]

would like to see actual nginx webserver supported, really just provide a rewrite rule for it and its good.

try_files  $uri $uri/ /index.php

Done.

[Dmacleo]

iirc thats what I am using, what I meant was if they provide that along with the apache one in the seo settings then its basically all good.

[Tibi]

METAs please! Need everywhere :smile:

[MGBrose]

try_files  $uri $uri/ /index.php

Done.

When I mention Nginx & Varnish in the same sentence I was referring to the ability to have "safe" micro-caching out of the box. I think thats what Dmacelo referenced as well, (were both optimization junkies)

Sorry I should have been more transparent.

Also Dfarber thanks for the input it all seems very reasonable, do you think well see better CDN support prior to IPB4?

[Makoto]

When I mention Nginx & Varnish in the same sentence I was referring to the ability to have "safe" micro-caching out of the box. I think thats what Dmacelo referenced as well, (were both optimization junkies)

I'm aware. See the part that I quoted.

Microcache isn't going to be really useful unless your forum is getting extremely heavy spikes in traffic anyways.

(So, essentially, 99% of IP.Board forums aren't going to make use of it. Officially supporting complex something like this for the 1% can be tricky)

[MGBrose]

I'm aware. See the part that I quoted.

Microcache isn't going to be really useful unless your forum is getting extremely heavy spikes in traffic anyways.

(So, essentially, 99% of IP.Board forums aren't going to make use of it. Officially supporting complex something like this for the 1% can be tricky)

Gotchya! Just misunderstood.

I also agree that the Nginx /Varnish are the 1%, but interest in nginx and varnish is certainly rising, and it is becoming more and more accessible as out of the box solutions with increasing plugin support for popular server/host management systems like WHM.

The only thing i partially disagree with the traffic spike thing, its useful for alot more than that. Reducing CPU Usage, Improving connect/wait times, etc.

But its alsoo great for traffic spikes too of course.

[Makoto]

Maybe. I haven't read into Microcache enough to disagree with you.

My page execution times average around ~0.03-0.15 seconds as it is anyways, and I'm not constrained on resources yet.

I might look into Microcache more, but it seems like it could be really finicky to use with IP.Board. Which is the main reason I'm not showing a huge amount of interest in it yet.

[Dmacleo]

been looking into it and it does seem finicky but I am not really good enough at nginx to know.

however if setup right I expect it would help, as its short cache there should be (when setup right) post issues and shoud only benefit.

all in all I think varnish would be better, need to get that in front on nginx first on new directadmin server.

if the unixy varnish plugin worked for nginx backend it would be perfect for me, but it does not.

learning as I go :)

[Makoto]

It's a good concept. I'm more or less happy with my current setup though, and don't see the need to add complexities that may cause unknown site-wide glitches at random. Page load times are still ~0.7-2.5 seconds on average for me, even when processing several hundred thousand visits a month on a single server :P

Though I guess my largest community only qualifies as a medium sized forum.

I'll still probably play around with this some in the future, but I find experimenting with things such as Google SPDY more interesting at the moment.

[.Nuno.]

Hi,

I don't think nginx/varnish cache would be very hard to implement. The greatest challenges would be purge content in nginx (varnish is easier) and implement a solution for view counters (varnish ESI is easy, but nginx isn't, maybe with ssi) for content like images, posts, downloads etc.

Would be needed to remove session for guests and this could leave to some unexpected behaviors that only IPB should care to handle.

I've tested a few scenarios but at this time I'm only using micro caching with nginx.

Regarding 3, 4 and 5 this is standard these days so there i hope we could see it in 4.0

About lazyload, this is a simple hack mainly for boards that publish huge amount of images like mine. It's not hard to implement and could give a push in rankings since you're not downloading images you don't see. I would like to see this has a default feature :) suite wide.

[.Nuno.]

I'll still probably play around with this some in the future, but I find experimenting with things such as Google SPDY more interesting at the moment.

I'm playing with SPDY and I'm very pleasant with it :)

I use it in production without problems ... waiting for spdy/3 in nginx.

[Makoto]

I looked into that, from what I've seen there don't seem to be many major differences between SPDY Draft 2 and Draft 3, minus flow control which has some reported issues that are still being worked on I think.

I believe that is the reason NGiNX has not yet adopted Draft 3.

I'm mostly wanting to see rate limiting support with SPDY connections. That's one "bug" that's still being worked on.

[.Nuno.]

I'm having some problems with fast reply + Chrome using Alternate-Protocol header.... Your is working?

[tpq]

We can get spikes of tens of thousands of users at a time. I'd be willing to pay for a premium Invision package if it meant that we had a reliable way to microcache. Yes, there are threads here which detail some ways varnish has worked, but there isn't anything 100% by a long shot.

I run a few other businesses and understand that tagging something as official makes it hard to support, but microcaching is here to stay so as a market leader in communication software which would be right in the wheelhouse of microcaching, I think that you guys should reconsider.

[bfarber]

We have some very interesting straightforward and powerful caching techniques employed already in 4.0 that we feel will significantly help performance for sites like yours that see sudden spikes. I'm unsure if we have blogged about them yet so I won't say much more yet, but just know - we host sites that get tens of thousands of visitors at a time, and are very aware of the special challenges they face. Any performance improvements in this regard also help our own hosting department.

[tpq]

I just gave this thread a +1 then realized that I already had. Sorry :)

[Canal World]

I might have missed it, but I would like better access to moderator tools, and better rending of the report centre and ACP, while using a mobile device.

We run a fairly skeleton staff (7 members for a largish site) many of whole spend a lot time where they do not have access to the site via a computer or tablet.

 

Daniel