Search…

X3 Photo Gallery Support Forums

Search…
 
User avatar
alexhenes
Experienced
Topic Author
Posts: 568
Joined: 28 Sep 2006, 16:13

Performance Improvements

27 Nov 2014, 18:37

I used http://developers.google.com/speed/pagespeed/insights/ to evaluate mobile and desktop site performance.

After moving to a more powerful server all of the server response time issues have been resolved.

There are however a number of recommendations Google is making for improving both desktop and mobile performance.

1. Desktop & Mobile "Should Fix!"

Eliminate render-blocking JavaScript and CSS in above-the-fold content
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.
Remove render-blocking JavaScript:
http://merelyafleshwound.com/public/js/ ... magevue.js
Optimize CSS Delivery of the following:
http://merelyafleshwound.com/…css/image ... 1411280929
https://fonts.googleapis.com/…talic,bol ... old,xsmall

2. Mobile "Consider Fixing"

Prioritize visible content
Your page requires additional network round trips to render the above-the-fold content. For best performance, reduce the amount of HTML needed to render above-the-fold content.
The entire HTML response was not sufficient to render the above-the-fold content. This usually indicates that additional resources, loaded after HTML parsing, were required to render above-the-fold content. Prioritize visible content that is needed for rendering above-the-fold by including it directly in the HTML response.
Only about 1% of the final above-the-fold content could be rendered with the full HTML response
Alex
https://www.merelyafleshwound.com
https://www.goldenbikeshop.com
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements

28 Nov 2014, 04:50

I would like to let you know that we have put a lot of effort into optimal performance for X3, and that you can't blindly read the suggestions that are offered by Google about this. It would be like having a computer analyze a 5-star menu and ask it "Do you think this will taste good?".

To be a bit blunt, we don't need suggestions here from google, because we have already done it better than any bot could recommend. I could write a long blog post about this, but let me break it down to your comments for now:
alexhenes wrote:1. Desktop & Mobile "Should Fix!"

Eliminate render-blocking JavaScript and CSS in above-the-fold content
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.
Remove render-blocking JavaScript:
http://merelyafleshwound.com/public/js/ ... magevue.js
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.
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:2. Mobile "Consider Fixing"
...
Only about 1% of the final above-the-fold content could be rendered with the full HTML response
Imagevue X3 is a modern application, that fades in the page once the main imagevue javascript is loaded. This is a single file, and technically speaking google is correct, but if we allow the page to render before the imagevue application is loaded, the layout will be incorrect. This is just google-bot analyzing based on basic guidelines ... Once the first "page" in X3 is loaded, there are no more assets loads or "rendering paths" anyway, but thats why we need to load the app on the start page.

Imagevue X3 is an ultra-modern application. Once the application is loaded, there is no more rendering issues at all when navigating between pages. Google is analyzing from a single-page perspective ... If we wanted to make that test look good, it would not benefit the application from a human perspective.

Furthermore, performance-testers do not justify how fast and performant X3 is ... Why? Because X3 loads above average amount of of data and resources from the initial page it is being accessed. From there, pages are loaded dynamically, no more JS or CSS assets need to be loaded (except for a few optional plugins like disqus on-demand). If you have the preload option enabled, it doesnt even load anything from the server ...

Does X3 seem slow to you?

For more info on performance
http://mjau-mjau.com/blog/preload-website/
http://mjau-mjau.com/blog/new-website/ (scroll down to "performance" section)

There is always room for improvement, but not these two suggestions made by google-bot ...
 
localhost
Experienced
Posts: 156
Joined: 20 Sep 2011, 07:09

Re: Performance Improvements

28 Nov 2014, 06:15

All I can say is... my website runs faster now than when it was on Wordpress. I've got some great feedback from the FB photography community I was in. Once the X3 is out of Beta I will announce this to them.
 
User avatar
alexhenes
Experienced
Topic Author
Posts: 568
Joined: 28 Sep 2006, 16:13

Re: Performance Improvements

28 Nov 2014, 11:18

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.
Alex
https://www.merelyafleshwound.com
https://www.goldenbikeshop.com
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements

28 Nov 2014, 14:20

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.
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.

I seem to remember checking your website a few days ago, and at that point you were editing with preload:true, which would certainly be one explanation for initial slow down.

As mentioned in the docs, things may run slowly in a phase while- and after you are adding pages and galleries. This is because X3 needs to process each page and/or ajax call from scratch when being viewed for the first time, reading files and subfolders, and create the correct html- and json (ajax) outputs for all requests. As the pages are visited (by you or anyone else), these files are progressively added to cache, and your server will progressively speed up as page requests can just be fetched from the cache. 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 ...

Once you leave your X3 website editing alone for a few hours (or maybe a day), as long as it gets browsed through so the cache gets fully populated, your X3 website will easily outperform any wordpress and most other CMS pages. Also taking into consideration that X3 is a modern heavy-duty application, that is meant to serve high-quality images in an advanced interface.

weak server?
Just to prove that X3 quickly speeds up and can run swiftly even on weak servers ... Our own demo gallery probably runs on a weaker and more over-shared hosting environment than most, and yet likely has the most visitors. See the diagnostics page, only 64MB ram!

Yet does this gallery seem slow? I think not ...

Let's check at pingdom.com
http://tools.pingdom.com/fpt/#!/cKIzJ7/ ... m/demo/x3/
Image
Performance grade 93/100, and faster than 62% of all tested websites. Not bad, but keep in mind that's just half the truth ... Unknown to pingdoms speed score criteria, but easily noticeable by human visitors, the pingdom-test has also loaded the entire website up front (json) so only images need to get loaded when navigating other pages. Additionally, this page includes 3 ultra-highres images (>2mb total) for the slideshow, and complete application javascripts, CSS and fonts.
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements

28 Nov 2014, 14:25

I like to write long posts like the above because I am passionate about it ...
 
User avatar
alexhenes
Experienced
Topic Author
Posts: 568
Joined: 28 Sep 2006, 16:13

Re: Performance Improvements

29 Nov 2014, 11:23

Good stuff... glad performance is on your mind... makes a huge difference when dealing with volume.
Alex
https://www.merelyafleshwound.com
https://www.goldenbikeshop.com
 
User avatar
radapple
Experienced
Posts: 29
Joined: 28 Sep 2006, 15:35

Re: Performance Improvements

29 Nov 2014, 12:29

I am very happy with the speed of x3, I agree with localhost, beats wordpress great, great job karl, let's not forget that the base are the photographs and in this x3 is the top.
http://pureapixel.com/
 
User avatar
Bulletproof IT
Experienced
Posts: 134
Joined: 04 May 2013, 04:36

Re: Performance Improvements (File Resizing & Caching)

12 Dec 2014, 13:11

Hi Karl!
How are you doing? Any plans for Christmas and New Year? :D
X4 perhaps? hahahah

Well done on the comprehensive replies and additional details to make things clearer. Much appreciated. However I was confused with what you said below...

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?

#Q: If Visitor 2 accesses the home page, but logs in and goes around the pages, does ANY of the cached content get displayed to Visitor 2 that Visitor 1 accessed and previewed?? When Visitor 3 turns up who is on a mobile device, an is a guest, what resources must be generated for them?

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??

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.

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.


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.

I am half a sleep here working on Powerpoint for tomorrow. Better get back to it rather than making heads or tales of what I just wrote! :P
Thanks again Karl for all your hard work.
Thank you.


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 ... .....
» I Imagevue X3 «
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements (File Resizing & Caching)

13 Dec 2014, 06:46

Bulletproof IT wrote:Hi Karl!
How are you doing? Any plans for Christmas and New Year? :D
X4 perhaps? hahahah
Gonna put on a little more weight at least ...
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?
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:#Q: If Visitor 2 accesses the home page, but logs in and goes around the pages, does ANY of the cached content get displayed to Visitor 2 that Visitor 1 accessed and previewed?? When Visitor 3 turns up who is on a mobile device, an is a guest, what resources must be generated for them?
The frontend output is the same, regardless if the visitor is logged in to the panel or not. Also, X3 is "responsive", meaning it does not create different output templates- and pages per device. Once all your pages are visited, all pages/templates are nicely cached, regardless of what device used or if the user is logged in to the backend or not. It works slightly different in regards to images, because images are served by javascript based on a calculated size that fits the device screen/pixelratio ... If visitor A views a page from a macbook 13", then visitor B on a windows 13" will likely be served the cached files. However, new images may need to be cached for first visitor to that page from an iphone retina device, while consecutive visitors on a device with a similar size/pixelratio will thereafter be served the cached images ... Ultimately, once your page gets traversed by a multitude of devices, your images will get cached in all combinations of sizes. Keep in mind, this also depends on the gallery layout you have selected, and how the images "respond" on smaller screens ... In many cases, a mobile device could easily request the same image as a large desktop, because column layouts respond. This should be an "invisible" process, where eventually everything including all image combinations are nicely cached, so that your website operates at maximum speed with minimal processing overhead.
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??
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.

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. In most scenarios, your images will likely just be created at 3-4 of these sizes (depending on layout). You need more than 3 sizes of images btw ... Just consider the slideshow thumbnails, which are 100px (and require 200px in retina mode). It does not hurt your server to have a range of smaller images to serve the request, which will benefit both the quality and bandwidth of the visitor.
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 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: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.
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: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.
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!
 
User avatar
Bulletproof IT
Experienced
Posts: 134
Joined: 04 May 2013, 04:36

Re: Performance Improvements (File Resizing & Caching)

14 Dec 2014, 19:55

Aaahhhhhhhh Ok, that makes far more sense.
Good. So only 1 template is ever called and pushed through the engine. That is a great idea to keep everything "harmonious" and optimised. Great work.

We should be doing a weigh in before and after the holidays. I'm going for high protein and low carbs! I'm not sure if its possible over Christmas with all the Booze and the Grub! :D
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.
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. :D
OK, I am glad we agreed on that! i.e. Scaling... /w800-q90/2.galleries/2.landscapes/ocean.jpg | Dimensions: 800px × 533px (scaled to 629px × 419px) | Size: 134.52 KB (137,746 bytes)


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).


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?
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?)

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.)

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....


Oh you're funny. I love the "automagically"! hahah Very good. :) Do you mind if I register / trademark that?
Why not just let X3 deal with it automagically?

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!!! :)

Thanks mate. You are a genius! :D
I am really looking forward to the performance improvements of X3.1!
mjau-mjau wrote:
Bulletproof IT wrote:Hi Karl!
How are you doing? Any plans for Christmas and New Year? :D
X4 perhaps? hahahah
Gonna put on a little more weight at least ...
» I Imagevue X3 «
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements (File Resizing & Caching)

15 Dec 2014, 04:30

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).
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 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?
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: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?)
If you change the layout, it will likely definitely calculate image request based on new layout.
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.)
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: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....
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: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!!! :)
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 ...
 
User avatar
alexhenes
Experienced
Topic Author
Posts: 568
Joined: 28 Sep 2006, 16:13

Re: Performance Improvements

18 Dec 2014, 21:37

I received a crawl warning in Google Webmaster Tools stating "Some URLs in the Sitemap have a high response time: This may indicate a problem with your server or with the content of the page."

This is interesting as I have created a sizable cache (252MB) using the Screaming Frog SEO Spider and the following user agents.

- Googlebot Regular
- Googlebot for Smartphones
- Chrome
- Firefox
- iPhone
- Android Mobile
- Android-Tablet

Cache
224MB images
29MB pages
336KB templates
253MB total

preload = false (things seem to slow down significantly if I set this to true)

In addition during the SF crawls I get a significant number of timeouts (set to 30 seconds) and I have to resubmit the URL for crawl. I am crawling with 1 thread. The same URLs never timeout twice in a row.

I have also experienced very slow response times when bring up the site myself... and I have to reload the page to get the site to come up. I can't seem to figure out a pattern.
Alex
https://www.merelyafleshwound.com
https://www.goldenbikeshop.com
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements

19 Dec 2014, 02:14

@Alex: I have noticed earlier that your server was slow at times earlier ... As of checking a random page right now from an airport, it seems quite fast:
http://merelyafleshwound.com/canyoneeri ... az-canyon/

pingdom:
Image

Other times, your website seems to stall ... It could be time of day, it could be overshared resources, it could be anything ... However, X3 will not "randomly" make a page load slow if it is loaded nicely earlier.

Then I checked another page ... 14.5 seconds??
http://merelyafleshwound.com/travel/
Image
Image
The page loads MUCH faster 2nd time I loaded it ... basically the PHP request processed in 0.4 seconds:
Image

Based on the above, I can conclude the following:

1) That page, and many of your pages are not cached. Un-cached pages will take longer time to process first time they are visited, depending on your server.

2) If for some reason the page was already cached (doubtful), and it still "randomly" takes 12 seconds to load OR suddenly loads fast, then you have a big problem with your host.

3) Your server has limited abilities, although I cannot tell you exactly how limited it is. Let us compare it with our X3 server, which is on the lowest-price shared hosting (Mediatemple):

Loading an un-cached page "tooltip", 2.4 seconds PHP processing for the page output:
Image
After cache, 0.7 seconds processing, similar to yours after cache, and proved that the cache works nicely essentially just passing through the cached file:
Image

I would be curious to know who the host is, and what they are charging, because we will have to deal with this question repeatedly. Most hosts are over-sold, over-populated and sharing scarce resources, and that is how they make money. This is also why we are setting up our hosted service, because we can make sure that does not happen.

Although we are only running a single website that owns all resources, our new hosting services it doesn't even spend any longer time with cached than uncached pages
Image
 
User avatar
mjau-mjau
X3 Wizard
Posts: 12964
Joined: 30 Sep 2006, 03:37

Re: Performance Improvements

19 Dec 2014, 02:16

Also, I am not sure about if you re still editing with preload=true, but this is a one-time cached affair. Check our entire preload site object cached:
https://www.photo.gallery/demo/x3/services/site.json