Talk:Woodworker Supreme Recipe Index

Cutting Down Filesize

This page, along with Weaponsmith Supreme Recipe Index, is far and away the largest page on the wiki and - per Lotroadmin here - generates way too many requests on the server. Notice especially that the filesize provided by Special:LongPages includes only the text; this page contains almost 300 icons between 3 and 6 kb, or about 1,200,000 bytes (1.2 mb) of image. A couple of ideas for paring things back a little:

1. Spin the Legendary Item sections off onto a separate page and link between the two
2. Condense some of the recipe info
3. Using sprites (Lotroadmin's suggestion)
4. Axe all the icons

I've listed these in order of preference. Clearly just dropping the icons would make the most difference (the amount of wikitext on the page is a drop in the bucket compared), but would also drop a lot of the visual appeal of this page and we'd probably have to do the same on the other indexes for the sake of consistency. I'd have to ask Lotroadmin for clarification on how using sprites reduces the pageload, but that would be a complicated solution at best, requiring us to either link directly to item files (instead of using [[File: ]] links and/or creating lots of new image files.

On the text side, there's a lot of duplicated information that could be condensed through clever reworking of the tables (e.g., all legendary items of the same level/quality have the exact same ingredients). Given the 300-pound gorilla in the room (1.2 mb of icons), though, expending effort on this seems a little trivial. This brings us to my first suggestion, which is to just split the LIs off. This is a logical place to break up the page (another option would be to peel off all guild content, which might actually make more sense since that could be applied to all of these crafting indexes) as there are enough of them that the new page doesn't seem too small on its own (the LI section actually accounts for almost 60% of the page text). This certainly won't reduce the number of icons in use, but it might mitigate the amount of requests made at once whenever someone accesses this page. I'll probably go ahead and do this (and on the Weaponsmith page, too) in the near future if no one objects or has any other suggestions. Sethladan 12:19, 17 June 2012 (EDT)

It's rather interesting to see "apachetop" (real-time server statistics) as it reported around 200 requests for the page with about 30 requests/second, which works out to be about six seconds. The page appears to load a lot faster than that though. I don't feel the total size of the page is the problem, but the number of elements required to download for a given page is. This is where a sprite would come in handy for the images, which I think the icons can add value just like text can.

An interesting thought here is that this would be the best and perhaps worst page for SMV? Good in the since that the item(s) properties could be used to create this page and tables. Bad in the since that it could be built dynamically causing server load issues (not unlike the number of requests per page). If anyone is up to the task, I would love to see what kinda obstacles we could face here. Just a thought.... --Lotroadmin (talk) 01:52, 24 August 2012 (EDT)

Oops. I forgot to come back to this, didn't I? :-P When you mean item properties, you mean the ingredients, the craft xp, and the like? I could add SMW properties to the crafting template (since I need to make another pass on it anyway) and we could give that a try. I guess if it had to check every single property on the fly, then it really wouldn't be much improvement, heh.

Also, how does the sprite thing work? I know you have the main page icons set up that way - you just link to them as background images in the CSS? Do they have to be all in one image like File:Mainpage-icons.png?

Kind of a relief to know that it's not the total amount of information that impacts the server, although you're right in that the page clearly doesn't take six and a half seconds to load. I wonder which are the 200 requests being made for this page, though? There are about 125 calls to Template:Recipe-cooldown from all the legendary and guild recipes, if those are included in that number. Sethladan 11:22, 24 August 2012 (EDT)

I would have guessed that images and icons where browser cached and that way be less of a problem, and then not just cached for this page but wherever the same icon is used, maybe I am wrong? I seldom access this page so cannot complain about loading time, but I have noticed that all vendors with more than a dozen or so items always takes time, just try any random Supplier and test. So definitely this is worth looking into, what is causing the extra burden?

While you are investigating that I go add more content in the other end, hehe. -- Zimoon (talk) 11:59, 24 August 2012 (EDT)

Sprites normally include a number of icons just like File:Mainpage-icons.png and you can see the wiki code <div id="s4" class="s4"></div> on the main page and also the snippet from MediaWiki:common.css

.s1, .s2, .s3, .s4, .s5, .s6, .s7, .s8  {
background:transparent url("images/0/0c/Mainpage-icons.png") no-repeat top left;
width:60px; height:60px; float:right;
}
.s1 { background-position: 0 -5px; } 
.s2 { background-position: 0 -70px; } 
.s3 { background-position: 0 -135px; } 
.s4 { background-position: 0 -200px; } 

It can be a painful adventure. If there was a notion of consistent images for a given topic, then it would make sense to have it as a sprite. Otherwise I would consider this too much effort to code up, and would recommend that we wait to see how MediaWiki deals with this. I did this on the main page since the images will rarely change and is the the most viewed page, and is a win win win (did i get that right :) ). These pages might be a win win lose

With SMV, I believe one could use the item template to populate the SMV tables with useful information. The data would be stored in the database twice, but the user would only have to enter in the data once. You can then use links and categories as always, but now you have another avenue to search or build a page based on the property. i.e. search which item has the most might in a table form. i.e. features found in the dedicated item database sites.

As for who's calling for this review/change. This is the largest and recently one of the most viewed pages (really all of the ones like these are) so impacts server load and is slow for the user. if your browser cache is empty, there's a lot to download here which does tax the webserver with about 200 requests when on average most pages have less than 10 requests. Do consider any templates, wiki code, etc as a server side cache as one server request (cached on server after the first view), there will be a few javascript and css requests as well. MediaWiki does a great job taking those 300 template calls and generates a gzip version of this page on first view, which is very powerful feature. But....if you tracked what your browser is doing you would see 3 load.php requests(js, css and php/html), standard images and then ~196 icons it needs to download. Check out this (website optimizer for this page.. rather interesting

--Lotroadmin (talk) 16:54, 24 August 2012 (EDT)

Yeah, interesting. Then ... looking at the page as such I notice many duplicate icons under different names. That won't solve the big issue but it may be worthwhile tracking down those. I am not very into image processing but wonder if there is some good recognition applications around. I assume the files are not 100% identical as such (different compressions or slightly off from screenshots, etc.) but if a fair similarity could be determined it would be easier to manually sift through the results.

But, that would just address a part of the bigger issue. -- Zimoon (talk) 17:25, 24 August 2012 (EDT)

It definitely needs doing, if only for housekeeping. Though I'm curious as to how much difference such a consolidation would make. Even if the page is downloading one icon to use in a dozen places, is that still a dozen calls? And given as the files are only 2-3kb each, how much of a dent would that make on the size? Or further, if we were to make sprite sheets from our current collections of generic item icons (ie: Category talk:One-handed Sword Icons), even if it were one collection tailored just for this page? - JnK (talk) 17:44, 24 August 2012 (EDT)

"downloading one icon to use in a dozen places, is that still a dozen calls?" -- No, the local browser is smart enough to avoid, and unless you turn off its file cache the icon will sit there until it is purged, or eternally if you view it often enough. Talking per user those sizes are not the real issue but the number of calls is; but considering the amount of visitors it begins to amount to something.

I was thinking the same, why not sprite-ing the generic icons and crap almost all singles?

-- Zimoon (talk) 19:34, 24 August 2012 (EDT)

Fortunately, a lot of people have been pitching in with identifying and consolidating duplicate icons (most of the icon category pages have reference charts for people to see which icons have been identified as "generic"), so the number of those has really fallen lately - tempered, of course, by people adding new ones at times and Turbine being artistic and inventive. If we did decide to convert some icons to sprites, the icons would line themselves up pretty nicely in this regard because there are usually sets of common through incomparable versions of each basic icon.

Re: SMW properties, that was pretty much my understanding, too, but I wasn't sure what you meant by dynamic vs. static pages (maybe that was on another discussion). If, for example (in a hypothetical future), we changed the tables on this page to ask each recipe page what items were its ingredients (assuming that the ingredients had been set up as properties of a recipe), would that count as dynamic because someone could update the recipe page? Would all that information have to get retrieved each time someone loads the page? Or is that what we're hoping to find out? :-P Sethladan 20:22, 24 August 2012 (EDT)