jcmcobra — 2013-02-08T13:53:03-05:00 — #1
Hey Good Folks,
Images probably account for at least 80% of of my site's data.
According to Google Analytics my page load times actually seem good (under 2 seconds) - except for one (18+ seconds), and it's the page that draws most of my visitors.
My thumnbails average around 15kb, but there are lots of them. Are they too big or just too many?
Maybe it'll help if I relate my image-editing process using GIMP.
I begin with an image of 3000px by 4000px that amount to 4.5MB - 6MB, and I crop as much as I can. I then scale these down so that the greater dimension will be 1100px. These are the images my thumbnails point to, and when I save them I reduce the quality to 85. I then scale these down again so that the greater dimension will be 300px, and further reduce the quality to 65. These are my thumbnails, and, as I've said, they amount to about 15kb.
Thanks for any help you can offer,
stevie_d — 2013-02-08T18:33:25-05:00 — #2
You say that this is the most popular page – is it likely to be the first page that people land on? If so then speed is an issue, and you don't want a slow page to be the first one that greets people. On the other hand, if they typically land at a different page (which loads quickly) and then come through to this one, they're already invested in the site so they are more likely to be patient and stick around while it loads.
jcmcobra — 2013-02-08T19:04:29-05:00 — #3
Yea, I was thinking of breaking the page up into several, more focused pages. With about 120 thumbnails (and sure to grow indefinitely), it could easily be done. The thing is, I'm pretty sure that'll hurt my page ranking - at least in the short run. One reason it's the most visited page is that it ranks second only to my index.
Good question. It is easily the most likely landing page, so I'm in a bit of a conundrum. I would actually like to add content and make it even more appealing to both man and machine, but that would be pointless if visitors leave in disgust.
I'm open to suggestions.
By the way, http://drumdr.com/drum-repair-histories.html is the page in question.
ryan_mcintyre — 2013-02-13T12:04:00-05:00 — #4
If I can add my 2 cents here. I think you should make each repair a separate well SEO'd page about that specific drum. While most of your traffic is hitting this page now, I think you'll find that by splitting the pages up, you'll actually deliver the desired content to the user much more quickly. I see that you have Google Analytics installed already, so what I may suggest is taking a look at the way people are currently getting to your site (are they typing in a specific drum type and the word repair for example) and split those main keywords off into separate optimized pages. When you've got that all done, you can simply put ONE thumbnail of each drum type on this page and let them navigate to the content...
Again, just a suggestion...most people don't really like the long-scroll and this could expedite them to the correct content.
jcmcobra — 2013-02-13T18:39:25-05:00 — #5
I already have a page for Djembe Repair and Tabla Repair (the two most popular drums I'm likely to repair). I'm definitely thinking of moving the histories specific to these drums from my Drum Repair Histories page to their relative Repair pages. I would then add a Doumbek Repair and a Frame Drum Repair (the two next most popular drums I'm likely to repair) page to which I would migrate the appropriate content from the Histories page. Hopefully, the traffic to my Histories page I would lose would be picked up by the Repair pages.
This is just a thought for now.
In the mean time, I've taken a closer look at Google Analytics and have come to realize that the 18+ second page load time is an AVERAGE and was due to ONE really lousy day. The average has now dropped to 9+ seconds.
I've also discovered Google's PageSpeed Insights, which analyzes your pages and offers extremely specific suggestions for improvement. Thanks to this tool, I've learned that I can reduce my thumbnails' file size by 50% or more without reducing their quality. That's huge! This is what I'm currently working on, and I intend to follow up on all appropriate suggestions.
I agree. Personally, you have to get me to swallow the hook to get me to keep scrolling and scrolling. For this reason, I'm sure that eventually I will probably break this page down eventually, even if the efforts I mention above work to perfection.
Your feedback is very much appreciated.
system — 2013-02-19T20:16:25-05:00 — #6
15kb for a thumbnail seems fine to me. I think it is just the issue of having too many accumulating. That is what causes the site to load slower.
I wouldn't go much lower and risk losing quality.
jcmcobra — 2013-02-20T20:59:03-05:00 — #7
You're probably right - there's just too many thumbnails. The thing is that Google's PageSpeed Insights specifically singles out all my thumbnails as the culprits of much of my page's poor performance AND it suggests that I scale them down. That's what I'm currently doing (a little at a time - lots of thumbnails), and I haven't noticed a loss in quality.
I'tll be a while, but once I'm done implementing all of PSI's suggestions I'll report the results.
Your feedback really is appreciated.
jcmcobra — 2013-03-23T18:50:17-04:00 — #8
So I've scaled all my thumbnails down to about half their former size (without apparent loss in quality) AND I've compressed them. According to Google's PageSpeed Insights, the page load time has been fluctuating from about 5 secs to just under 10 secs. Better, but not what I'm shooting for.
The thing is, I don't know how much credit to give Google on this. I've put my website through other page speed analyzers (Pingdom, for example) and get much better results. Any thoughts on this?
Any way, I've begun to add my repair histories on their respective pages (doumbek repairs on my Doumbek Repair page), rather than continuing to bloat the Repair Histories page. It's a shame because it's my most visited page and ranks well in the serps.
molona — 2013-03-27T08:53:08-04:00 — #9
To be honest, for the amount of thumbnails you got, I'm suprised that you got any lower figure!
john_betong — 2013-03-27T10:06:30-04:00 — #10
jcmcobra — 2013-03-27T15:46:35-04:00 — #11
So you think markup errors are contributing to lag time?
As I mention above, I've tried other analysers, including Pingdom, and have gotten much better results. That's why I'm not sure how much credit to give Google Analytics on this. I just tried Pingdom again and the result was 2.39 seconds with a performance grade of 100/100.
This is new to me. Have you had success with it? Just did a quick search and find conflicting opinions. Not only that, there's much to consider - page rank may suffer, for example.
john_betong — 2013-03-28T04:02:24-04:00 — #12
I had time on my hands so decided to download your web page, remove most of the HTML and CSS errors, uploaded images, scripts, etc to my site and also uploaded the images on to a sub-domain.
Let me know if there is much of a difference, etc
jcmcobra — 2013-04-04T19:53:04-04:00 — #13
Hey John B.,
Thank you for taking so much time to help me look into this.
Maybe you can spell out for me how what you've done helps, because I don't see it. According to Google PageSpeed Insights, your version scores an 89 compared to the 75 my current version scores. The difference in scores, as far as I can tell, is that your version leverages browser caching. This will speed up the page's performance for returning visitors, but I'm not really concerned about that. I don't expect my visitors to return again and again.
As I've already stated, Pingdom gives my version a 100/100 performance grade and clocks the page's load time at just over 2 seconds. For some reason, Pingdom had trouble accessing your server, so I wasn't able to make that comparison.
I still need to look into how serving images from a sub-domain would impact page ranking and, possibly, other SEO concerns.
john_betong — 2013-04-05T00:09:20-04:00 — #14
>>> Maybe you can spell out for me how what you've done helps, because I don't see it.
1. remove most of the HTML and CSS errors
2. uploaded the images on to a sub-domain
>>> This will speed up the page's performance for returning visitors, but I'm not really concerned about that. I don't expect my visitors to return again and again.
The page load is quicker and I do not think it is due to caching.
>>> For some reason, Pingdom had trouble accessing your server, so I wasn't able to make that comparison.
Pingdom's site is too popular and frequently I have to wait in a queue before my request is accepted. Try again and see if you can test the site.
The changes I made appear as though the page displays very quickly and the images gradually appear as they are loaded from the sub-domain. This was the goal in decreasing "Page Load Time".
evemper — 2013-04-07T06:06:55-04:00 — #15
Use gzip, header compression and HTML/CSS JS compression to reduce the page speed. Also it seems you have linked the images with your thumbnails , so try to load them via Ajax, this way you can save lots of requests as well as page size and can reduce the page load time.
jcmcobra — 2013-04-25T16:02:39-04:00 — #16
OK. I know it's taken a long time to respond. Sorry. My OS wanted to die on me, so I had to focus on that for a while.
I've taken care of item 1. Thanks for the reference to W3's validator. Great tool. I cleaned up my mark up (had HUNDREDS of missing quotation marks and forward slashes, plus a few more serious bugs [on the entire site, not just the one page]). As I said earlier, I've also begun migrating some of its content to other pages. I'm still adding new projects that don't fit anywhere else, though, so I've decreased the number of images only slightly.
Google Analytics is currently listing the page's speed at under 7 seconds. Getting better.
Still need to research what item 2 will do to the page's rankings. I have no doubt that it will improve the load speed.
Will be working on itme 3 next.
jcmcobra — 2013-04-25T16:09:06-04:00 — #17
Thanks for the suggestions evemper. This all new to me, so it'll take me a while to do the research and get a handle on it. Will report back (eventually).
I appreciate your help,