First of all, I am not sure if your code is different for some reason or what, but the JS file you are referring to is NOT render-blocking, and it is located at the very bottom of the <body> tag. I am not quite sure why Google sees it differently, but you can check the source ... Furthermore, this Modernizr script is the first necessary script to load before any other scripts are loaded dynamically.alexhenes wrote:1. Desktop & Mobile "Should Fix!"
Your page has 1 blocking script resources and 2 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.
http://merelyafleshwound.com/public/js/ ... magevue.js
Did you know that imagevue.skin.default is a minified, concatated and compressed css file from around 30-40 CSS files combine to make X3 what it is? This CSS is above the fold, because it is required for the page content to render correctly. It is not an "add-on" or anything, but the main CSS file. You cannot add it "below the fold", just like there is no page that its main CSS file below the fold. Loading the google font is also necessary above the fold, else your fonts would jump between states after its loaded. Check an average Wordpress website, and you will probably see 20-30 separate CSS and JS files above the fold ... In X3, we have limited it to 2-3 ... We cannot optimize css delivery any better ...alexhenes wrote:Optimize CSS Delivery of the following:
http://merelyafleshwound.com/…css/image ... 1411280929
https://fonts.googleapis.com/…talic,bol ... old,xsmall
Only about 1% of the final above-the-fold content could be rendered with the full HTML response
The above is however what you will find even if you host X3 on a lightning-fast dedicated web server from the future. The google bot will still check the "critical rendering path" of the output page, and not distinguish between "slow" or "fast" output by the server. The issues mentioned were not responsible for your initial slowdown, as these issues are related to the browser rendering path, while your issue was related to speed of the server outputting processing and outputting requests.alexhenes wrote:I am happy with X3 performance now that I am on a more powerful server. The initial slow down is what caused me to look into causes... the above is what I found... and thought I would share.
mjau-mjau wrote:.... ..... Also, ALL your images need to get resized to multiple sizes, to suit a range of layouts and devices/screens ... It may take days or even weeks until every image is resized- and cached into all possible size combinations for all possible screens, because images are resized- and cached on demand. It will however be most demanding on server immediately after each new gallery creation, since no sizes exist for the images, even for the most requested size ... .....
Gonna put on a little more weight at least ...Bulletproof IT wrote:Hi Karl!
How are you doing? Any plans for Christmas and New Year?
X4 perhaps? hahahah
Yes, a single visitor will make sure the images get cached on server, thus serving the same files to next visitor faster. However, images may need to be be created in multiple sizes depending on the visitors screen ... For example, I am on macbook retina, thus images are generally requested at approximately double size. Essentially it could require a few different visits from a handful of different devices to make sure all image sizes have been created- and cached for a specific page. Basically it will create on-demand, so the most requested sizes are likely to be created quickly, and perhaps some images are created later in time once the same page is visited from an obscure non-retina older iphone device.Bulletproof IT wrote:A visitor must visit a page and request the resources (JS, CSS, JPG, PNG....) for them to be generated and cached with their permissions (guest, member, admin, custom level) as well as custom elements only visible when that combination of access is granted.
So given that Full-Sized photos/images are viewed at up to 1920x1080 (minus the browser toolbar and scroll bars, and so on. If I upload all 2MP images, 10 of them. Then only when Visitor 1 visits the website will all the files be cached... right?
Sorry but it does not work like this. An image is not necessarily smaller on a phone, sometimes it is bigger. For example you have a columns layout that wraps to a single-column on mobile devices like iphone 6 ... An iphone 6 is 750px wide, so will request the image approximately at that width. A non-retina 1600px desktop showing 5 columns, might request the images at 320px or less. Also, this depends on your gallery layout, as in many cases a lot of images sizes are not required, so it is best handled on-demand.Bulletproof IT wrote:I would have thought that we first create three of each that meet this criteria (Phone, Tablet, Desktop for 1, 2 and 3 = 9 resize of each, instead of unlimited number).)::
1. Full Size (either original or resized to max X or Y axis (e.g. Max Preview Image Width: 1200px, Max Preview Image Height: 900p.)
Will this then show that image to ALL visitors??
I am not quite sure why would predefine this ... thumbnails can be 100x100 or 200x200 or 100xaspect or 200xaspect, depending on what settings you have applied for your specific layout. In a columns layout on a large retina macbook, a "thumbnail" might even be 480x480. Why not just let X3 deal with it automagically? It is quite smart and intricate. 150px serves no specific purpose unless your layout for any given screen happens to find that to be a lucky number, which in most cases is not possible across all devices and pixel-ratios ... Iphone 6+ has a 3X pixelratio btw ...Bulletproof IT wrote:2. Other Size (used for thumbnails on)
Similar to #3 below. Resized to 150px. Then displayd at % of this size to fit visitors screen. If they are using graphics that are resized down 1% - 30% then this will prevent having generate more triplicate/quadruplicate/quintuplet/.... copies of the same thumbnails or preview or full size images and photos.
I would re-iterate, X3 does NOT create a 100% exact size only for this specific device and layout. It will lookup an array and find the best match, and this size will likely be used in several scenarios across multiple devices. We cannot serve the same image sizes for all mobiles. The browser will STILL cache it locally, and I am not sure what makes you think it will not do that.Bulletproof IT wrote:3. Multi-Device Size (Displayed anywhere between 40% and 120%)
Allows all mobile devices to access one remotly located resource, so the browser can cache it locally too. e.g. If in Desktop Mode or Mobile Mode (Meta Client) etc.
The benefit is that these images are dynamically resized, and then all Thumbnails are resized dynamicly from 90% width/height to 50% width/height, should the user zoom etc.
We don't have have images cached for every single screen resolution, but we have have a selection resized items set to best serve the device and layout that makes the request. A full-size image on an iphone 3 might be the same image served as a thumbnail on a macbook retina for instance. We got this covered!Bulletproof IT wrote:Make sense?
This means you don't have to have a preview image AND thumbnail AND xxxx resized image for very single screen resolution (or dimensions should say) and all the other factors.
Great. This is what I was getting at. I said 3 x 3 = 9. But you have 8 already defined. I was thinking, you couldn't possibly require more than 9.Btw, it does NOT create an unlimited number of sizes. It creates from within this array if widths: 100,200,320,480,640,800,1024,1280.
Why not just let X3 deal with it automagically?
mjau-mjau wrote:Gonna put on a little more weight at least ...Bulletproof IT wrote:Hi Karl!
How are you doing? Any plans for Christmas and New Year?
X4 perhaps? hahahah
Although not directly related to how X3 calculates image sizes, the columns depends on your layout settings. For instance if you are using the grid setting, it defaults to grid:3,2,1, which means 3 columns on large, 2 columns on medium and 1 column on small. If you set grid:3,3,3 (which is the same as grid:3), it will force 3 columns on ALL size screens. Similar approaches are also for the justified and columns layout method. Essentially you can have multiple columns on mobile screens also, X3 is very flexible. Regardless of what layout you select, X3 will calculate in runtime from the frontend (JS) what is the best image size to request from the server.Bulletproof IT wrote:Will 2 columns be able to be forced on 750px wide IPhones? Or will it still be forced to 1 column? i.e. Force a certain layout to certain devices? 500px and less width can have 1 column, .... (example).
Essentially, this would only be a problem first of all if you upload a NEW file, but with the SAME name as an existing image. This could get cached not only in your browser, but possibly also through the network. Essentially, a lot of this is handled in the cache settings in the .htaccess file, which generally applies recommended expiry settings to assets files so that performance is prioritized.Bulletproof IT wrote:Will there likely be any problems, similar to those experienced in X2, where stale old content is not delivered despite pressing Ctrl F5 a dozen times and clearing browser cache? I think that was a flash problem back then. I do remember you answering my questions about it. Does that make sense?
If you change the layout, it will likely definitely calculate image request based on new layout.Bulletproof IT wrote:So should you replace an image or change the way in which it is displayed (e.g. 4:3 to 5:4 or 16:9). Will it automatically inherit the new display settings, without displaying ALL the old 4:3 thumbnails or preview images? (i.e. ignore one cached image?)
Even if a request is made for a higher resolution than the original, the resizer script will never render the image at larger size than the original. The request might get cached, but it will simply "get" the original image.Bulletproof IT wrote:Given these high resolutions on retina screens, have you made the appropriate precautions to prevent images from being up-scaled? (i.e. displayed at a higher resolution than their original.)
To try to give a short answer to this, it is accounted for. To keep things under control, we only allow an array of WIDTHs ... We often calculate the request based on height, but since we know the image aspect and width, we convert the request to width based on the target-height.Bulletproof IT wrote:Yes I totally agree with the 100x100 or 200x200 or 100xaspect or 200xaspect, however, will it support AspectxXXX? e.g. Aspect x 200, Aspect x 300, Aspect x 100, whatever....
Yes Agreed. This is already how it works, and X3 does not serve pixel-perfect match to the request ... It uses a smart system that gets the requested size, and looks up the array. It also varies slightly as retina devices will often "round down" slightly, while non-retina will "round up" ... A bit too much to explain in short ...Bulletproof IT wrote:What I was getting at with the "3. Multi-Device Size" was that instead of specifcally resizing an image just for an odd display size, why not just display it at a resized size? e.g. If it needs or requests a 180x180 thumbnail, then because it is within 20% of another size, just request the 200x200 and display it at 180x180. Does that make sense? Obviously so that downloading an 18kb file, vs a 16kb file (resized for a 180px image size) would be faster to display the original 200px 18kb file.
Was just an example for odd-shaped and odd-sized 'multi-device' sized screens. I am sure you are aware there are numerous manufacturers who don't follow the rules and make them up as they go, ignoring all standards!
So I was certainly not saying that you must serve the exact size. That is why I said %. i.e. display 90% of the cached image to fit the required display size.
Alright? Because I think you missed the point I was emphasizing over the 3 displays by 3 sizes = 9 dimensions of images, rather than ad-hoc resizing. So you should be agreeing with me!!!