Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
recifbox Posted October 18, 2012 Posted October 18, 2012 Ok i've just noticed my site take 4s to respond so for google its a fault and it impact the ranking. i have make some test and my isp (when i ping my server( respond in 6ms)) so here the screenshots : an idea ?
GIANT_CRAB Posted October 18, 2012 Posted October 18, 2012 PHP caching such as xCache, EA accelerator, etc.CDN such as MaxCDN, Cloudflare, etc.
recifbox Posted October 18, 2012 Author Posted October 18, 2012 but for the redirect that take 4sec any idea ? (from / to http://www.recifalnews.fr/page/index.html ) for me it came from ipb is any way to tweak this ? edit: xcash is running
maddog107_merged Posted October 18, 2012 Posted October 18, 2012 I think the redirect took 400ms, the 4 seconds your refering to its actually downloading the index page itself. gzip, caching, db tuning. could be anything. try google pagespeed to start https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fwww.recifalnews.fr&mobile=false
Grumpy Posted October 18, 2012 Posted October 18, 2012 The index.html page did indeed take 4047.41ms to load for me. It's too long.Additionally, the entire page took over 40 seconds to load!1. It's hard to diagnose what's wrong with your server for index page given what we have. But even without cache, it's rather a long time. There is a problem, with certainty. Though what problem, well... we probably need to go through a deep diagnostic on it. Or hire a system admin.2. You have a LOT of stuff that's loaded on first page. The total size of load just to get the index page is 8.28MB. Most of them are images, and some of them are just outright huge. You need to learn to make better images.You cannot save everything in png, especially when your photos aren't even crystal clear to begin with. The size just too large. Use PNG if and only if when the file needs lossless quality (such as clear text) and you don't need a high palette (256 color), anything other usage of PNG isn't appropriate for the web.Example: And then loading images like this... a lot of them, might I add, is just a waste.Resize your pics!!3. On the issue of redirect. Took 300ms for me. That's too long imo, but we can leave that be...
Eric Allione Posted October 19, 2012 Posted October 19, 2012 PHP caching such as xCache, EA accelerator, etc. CDN such as MaxCDN, Cloudflare, etc. I will have to look into this for sure because when I run tests at webpagetest.org or at woorank.com, I get an F on cached static content and am informed: "unfortunately your server does not appear to have a caching method". So I asked my hosting about this on tech support and they had no idea what I was even talking about and told me to dig through IPS support topics. " alt="cacheStaticContentF_zps86ec90da.png"> And that's for a $25/month reseller account at HostGator that I haven't even partitioned into other sites.
Rhett Posted October 19, 2012 Posted October 19, 2012 If you are on shared hosting, all you can do is what was mentioned above, optimize your images and reduce your amount of queries on the page. The leaner the meaner. People are not going to scroll and read 15 articles on your home page, clean that up to about 5-6 max imo.
Johnasc Posted October 19, 2012 Posted October 19, 2012 Smaller images, saved as jpegs, with the quality slider in your jpeg editor reduced to say 65-70% will make a huge difference to the size of your image files and thus the loading of your page.
recifbox Posted October 19, 2012 Author Posted October 19, 2012 Thanks for your response, this is not "sharing hosting" it's a server here the stats of the ipb threads : last pid: 72326; load averages: 0.09, 0.10, 0.05 up 119+18:29:46 09:54:01 245 processes: 1 running, 244 sleeping Mem: 402M Active, 632M Inact, 238M Wired, 59M Cache, 211M Buf, 626M Free Swap: 512M Total, 52K Used, 512M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 71537 ouaib 1 49 0 136M 48572K accept 1 0:10 3.37% php-cgilast pid: 72326; load averages: 0.09, 0.10, 0.05 up 119+18:29:46 09:54:01 245 processes: 1 running, 244 sleeping Mem: 402M Active, 632M Inact, 238M Wired, 59M Cache, 211M Buf, 626M Free Swap: 512M Total, 52K Used, 512M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 71537 xxxxx 1 49 0 136M 48572K accept 1 0:10 3.37% php-cgi So i need to reworks all the "Ipcontent" article and optimising it
recifbox Posted October 19, 2012 Author Posted October 19, 2012 First off all: i have removed articles to just 5 and i have also remove some blocks. we have installed optipng to also optimise the image automatically (i will take care also of the size of images on articles we post). How i could optimise the redirection of 300ms ?
AlexJ Posted October 19, 2012 Posted October 19, 2012 1. Your index.html took just 2 sec for me and not 4. 2. Compressing the following resources with gzip could reduce their transfer size by 41.0KiB (74% reduction). Compressing http://www.recifalnews.fr/public/js/3rd_party/camera.min.js could save 24.9KiB (77% reduction). Compressing http://www.recifalnews.fr/public/ipc_blocks/compiled.js could save 6.8KiB (69% reduction). Compressing http://www.recifalnews.fr/public/js/3rd_party/jquery.easing.1.3.js could save 6.0KiB (75% reduction). Compressing http://www.recifalnews.fr/public/ipc_blocks/compiled.css could save 2.8KiB (68% reduction). Compressing http://www.recifalnews.fr/public/style_css/css_4/ipb_collections.css could save 556B (52% reduction). 3. Use Page speed tool in firefox and you can get optimized image for your skins. You can't optimize all images but most of the skin images or static images you can. Example: Losslessly compressing could save 27.1KiB (44% reduction). See optimized version or Save as. Losslessly compressing could save 19.6KiB (85% reduction). See optimized version or Save as. Losslessly compressing could save 18.6KiB (54% reduction). See optimized version or Save as. Losslessly compressing could save 13.2KiB (92% reduction). See optimized version or Save as. Losslessly compressing could save 12.5KiB (72% reduction). See optimized version or Save as. Losslessly compressing could save 10.9KiB (58% reduction). See optimized version or Save as. Losslessly compressing could save 10.1KiB (55% reduction). See optimized version or Save as. Losslessly compressing could save 10.1KiB (68% reduction). See optimized version or Save as. Losslessly compressing could save 7.7KiB (5% reduction). See optimized version or Save as. Losslessly compressing could save 4.3KiB (50% reduction). See optimized version or Save as. Losslessly compressing could save 3.6KiB (23% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/ban/ban_n_b_i%203.JPG could save 3.6KiB (46% reduction). See optimized version or Save as. Losslessly compressing could save 3.3KiB (50% reduction). See optimized version or Save as. Losslessly compressing could save 3.1KiB (7% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/ban/ban_aquastore.PNG could save 2.9KiB (19% reduction). See optimized version or Save as. Losslessly compressing could save 2.8KiB (12% reduction). See optimized version or Save as. Losslessly compressing could save 2.3KiB (13% reduction). See optimized version or Save as. Losslessly compressing could save 2.3KiB (53% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/ban/ban1_0.PNG could save 2.0KiB (11% reduction). See optimized version or Save as. Losslessly compressing could save 945B (38% reduction). See optimized version or Save as. Losslessly compressing could save 932B (18% reduction). See optimized version or Save as. Losslessly compressing could save 862B (25% reduction). See optimized version or Save as. Losslessly compressing could save 686B (21% reduction). See optimized version or Save as. Losslessly compressing could save 546B (10% reduction). See optimized version or Save as. Losslessly compressing could save 416B (6% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/uploads/profile/photo-thumb-353.jpg?_r=1348518163 could save 408B (11% reduction). See optimized version or Save as. Losslessly compressing could save 407B (6% reduction). See optimized version or Save as. Losslessly compressing could save 406B (5% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/uploads/profile/photo-thumb-20.jpg?_r=0 could save 404B (22% reduction). See optimized version or Save as. Losslessly compressing could save 394B (8% reduction). See optimized version or Save as. Losslessly compressing could save 389B (5% reduction). See optimized version or Save as. Losslessly compressing could save 378B (6% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/uploads/profile/photo-thumb-25.jpg?_r=0 could save 374B (26% reduction). See optimized version or Save as. Losslessly compressing http://www.recifalnews.fr/uploads/profile/photo-thumb-5.jpg?_r=0 could save 372B (13% reduction). See optimized version or Save as.
Grumpy Posted October 19, 2012 Posted October 19, 2012 Okay, so the forum loads in 980ms for me. That's okay. It's not superb, but perfectly within reasonable. The front page is now loading in 2522ms. The entire page took under 7 seconds. Longest one being... Total size: 1.64MB Huge improvement. Though, I think we can still do better. Content wise, I think that's fine. Now let's try to reduce the one I bolded above. Simply from less strain, I think the page generation is a lot faster too now. Since you're on dedi/vps, there's quite a lot we can do (in no particular order). 1. Optimize mysql (Noticable impact will only come if there was a bottleneck somewhere, not necessarily in mysql. Otherwise, does get faster, but not the biggest boost) 2. Swap in a faster front end (such as nginx/varnish/etc -- a simple setup first anyway. Still has huge impact.) 3. Optimize apache (this really doesn't go far though, at best, we can just avoid stupid things. We can't do #2 after this, as #2 affects this.) 4. Optimize your xcache settings (since you said you have them) Which would you like to hit first? lol Well... if YOU feel you're okay, then we can stop. ------------------------------------- @Eric Allione Your issue is of bit different. The options don't exist for you b/c you're on shared. But, with regards to caching... just add this... Just add this to your .htaccess <filesMatch ".(jpg|jpeg|png|gif|swf|ico|css|js|pdf|flv)$"> Header set Cache-Control "max-age=172800, public" </filesMatch> Problem solved. Things are now cached for 2 days. If you want to read EVERYTHING about apache caching directives, you can read this ludicrously long article on it. http://www.askapache.com/htaccess/speed-up-sites-with-htaccess-caching.html Do note, if you change images now though (or any of the extension set above), the user may not see the image upto 2 days. New items or items under different names obviously works.
recifbox Posted October 19, 2012 Author Posted October 19, 2012 Thank you for your help Grumpy, Yes i have installed Xcash, also optipng and jpegtran, i'll resize the image you have pointed to a more resonable size. i add a 5/ So for me i see also the PHP that take a ughe time of processor time, is there is a way to include an optimise ? we can do the 4 thing in the same time :)
Eric Allione Posted October 19, 2012 Posted October 19, 2012 @Eric Allione Your issue is of bit different. The options don't exist for you b/c you're on shared. But, with regards to caching... just add this... Just add this to your .htaccess <filesMatch ".(jpg|jpeg|png|gif|swf|ico|css|js|pdf|flv)$"> Header set Cache-Control "max-age=172800, public" </filesMatch> Problem solved. Things are now cached for 2 days. If you want to read EVERYTHING about apache caching directives, you can read this ludicrously long article on it. http://www.askapache.com/htaccess/speed-up-sites-with-htaccess-caching.html Do note, if you change images now though (or any of the extension set above), the user may not see the image upto 2 days. New items or items under different names obviously works. Awesome, I will try that thanks! A quick question: what would be the repercussions of reducing that cache rule to about 1 day instead of 2? And just curious, would* my caching options become functionally better if I upgraded from reseller (aluminum) ($25/month) to VPS (level 3) ($40/month)? I would have to start with level 3 for the VPS since that's the lowest level which is managed with cPanel. I only have 4 active members... and currently a low income, but I am greedy to get my sight running faster (I haven't tried your htaccess trick yet). Edit: Also I was going to try disabling ALL my sidebar hooks and my gallery today to run speed tests. Would using this rule early taint my tests? I'm trying to isolate slow queries. Also, would the htaccess caching rule prevent my hooks from being up-to-date?—such as "recent posts" or "recent game scores"?
Eric Allione Posted October 20, 2012 Posted October 20, 2012 The leaner the meaner. Man you weren't kidding. Webpagetest.org was rating me at 10-11 seconds for full loading time. I took off all my sidebars and the gallery slidebar and it dropped to a consistent average of 2.5 seconds. So I'm re-adding the hooks one by one while doing speed test to find any ones which are slowing things down. I'm not really sure what you mean by "optimizing images" but as a start I decided to convert my pgn.fw images to .gif.
Rhett Posted October 20, 2012 Posted October 20, 2012 Man you weren't kidding. Webpagetest.org was rating me at 10-11 seconds for full loading time. I took off all my sidebars and the gallery slidebar and it dropped to a consistent average of 2.5 seconds. So I'm re-adding the hooks one by one while doing speed test to find any ones which are slowing things down. I'm not really sure what you mean by "optimizing images" but as a start I decided to convert my pgn.fw images to .gif. Great news, by optimizing the images, I was referring to reducing the file size in KB, people often just use an image they obtain an in most cases it's larger then it needs to be, you can optimize your images in a photo editing program such as photoshop and reduce the file size without much loss to the image quality. You can also play around with different file extensions as you mentioned too. Good luck and it looks like you have made a very big improvement already.
AlexJ Posted October 20, 2012 Posted October 20, 2012 Also, would the htaccess caching rule prevent my hooks from being up-to-date?—such as "recent posts" or "recent game scores"? No. Caching rule will have no effect on your "recent post or game scores" hook.
Grumpy Posted October 20, 2012 Posted October 20, 2012 @Eric Allione The cache directive only sets caching for these: jpg|jpeg|png|gif|swf|ico|css|js|pdf|flv So other pages like your .html page, or your .php are completely unaffected. The repercussion of 1 day instead of 2 is simply that users have to download every day as opposed to every 2 days. If there's an image, let's say example.jpg and no-cache is set, every time the user loads a page with that reference, they have to recheck and possibly re-download it each time (The response 304 still exists, but for simplicity, ignore). If there is a 1 day cache directive, the user, no matter how many times the image comes up, will load the image from their own hard drive and not even bother to check with you. This vastly improves loading time since the user loads so much less per page. Now, if this image was in every page (like a background image for example), and the user surfs to 10 different pages, that's a difference of 10 downloads vs 1 download. If the person comes again the day after, and you set it to 2 days, it's still 1 request (assuming the user's cache is still holding it). If you set it to 1 day, then it would be 2 downloads. If you get a vps, you open yourself to a plethora of new methods to optimize. These options cannot have previously existed for you because we're configuring the entire server to best suit your one and only one website. A shared hosting typically is geared to handle all kinds of websites, thus cannot optimize for a single solution. The speed difference will not come from what package you have. It entirely depends on 2 factors, 1. is the machine fast enough (details of the question aside...)? and 2. are you optimized to do what you do? You cannot control factor #1 unless you buy a dedicated. The package size makes zero difference, although some companies have certain load distributions based on packages which will cause an impact. You cannot control much of factor #2 due to reasons said above as long as you're on shared hosting (as in the industry term, not shared environment as that includes a vps). ---------------- @recifbox The writeup is just too damn long for me to go through that with you then.
recifbox Posted October 20, 2012 Author Posted October 20, 2012 hooooo it's sad :( (but thanks anyway :D )
Grumpy Posted October 21, 2012 Posted October 21, 2012 hooooo it's sad (but thanks anyway ) Not sure you understood. Me: Pick 1 of 4 You: Everything! Me: I don't want to do everything at once. You: It's sad.
Eric Allione Posted October 21, 2012 Posted October 21, 2012 Thank you for the detailed help... WebPageTest is giving me an A on cached static content now!I was just wondering why the suggestion for the cache timeout was so low (2 days). I took that recommended code snippet and just added a 0 to make it 20 days in my .htaccess file. I only use static images, and not many images at that (except what's in my skins). So I can't find a reason not to use a larger timer like this unless it will slow down the site somehow.However, I don't think I like the long PDF timer though because I have a research site and PDFs might be changing, can I repeat the same command and add a separate timer for PDFs? I was thinking of putting both of these commands in my .htaccess file but am not sure if this repetition is legit:<filesMatch ".(jpg|jpeg|png|gif|swf|ico|css|js|pdf|flv)$">Header set Cache-Control "max-age=1728000, public"</filesMatch><filesMatch ".(pdf)$">Header set Cache-Control "max-age=1728, public"</filesMatch>
recifbox Posted October 21, 2012 Author Posted October 21, 2012 Not sure you understood. Me: Pick 1 of 4 You: Everything! Me: I don't want to do everything at once. You: It's sad. errr was late...;read fast the forum and understanding pretty bad...sorry :D Hmmm let's say the one that can get the best impact on the things...from my pov the nmbr 2 ?
Grumpy Posted October 22, 2012 Posted October 22, 2012 @Eric Allione If you feel that your site needs faster refreshing for pdf, go right ahead, or even remove it entirely. Side note. the code appears correct. Nothing stops you from making longer timeouts, but you have to consider 2 factors. 1. Is the user ACTUALLY going to keep it for that long? If the user presses clear cache, (hard) refresh, private browsing, some anti-tracking tools, etc. then none of these settings matter. So, there's the question of how much of a difference is there between 2 days and 20 days or even 200 days? If you set it to like a year, you can pretty much guarantee the user isn't going to follow and going to be cleared sooner. 2. Expecting the unexpected. What if you changed an image on your site? It would be best if your user sees the new one asap. That's the primary trade off. And... there's one more special place you actually need to consider. User avatars... (forgot about it while I wrote it before). When a user changes his/her avatar, do you want them to see it immediately at the cost of less caching? Then you'll want to omit these special images. Avatars, which usually go in "uploads" directory (or is it upload??? check and fix yourself). Then we can change the match to something like this instead... ^((?!uploads/).)+.(jpg|jpeg|png|gif|swf|ico|css|js|pdf|flv)$ Which says, the word "uploads/" should not be in the match. =========== @recifbox I'll write something l8r... lol
Grumpy Posted October 22, 2012 Posted October 22, 2012 @recifbox Actually, questions first. OS? Control Panel (if any)? Total ram? Output of "top" if you will. :)
Recommended Posts
Archived
This topic is now archived and is closed to further replies.