High Sierra Topix

Looking at this current thread:

viewtopic.php?f=1&t=13874

From my workplace, am on a fast AT&T T1 line but the thread is loading so so slow. I tried both Mozilla Foxfire and IE11. Noticed all the images links are to large Flickr image files that the board software slowly loads then eventually downsizes for display within the available frame panels. In fact after about 15 minutes most of the image links had not even changed to show any loading images so might take an hour to fully load. For example first image 2048x1538 pixels 1.29mbytes scaled to 767x576. I extracted the Flickr path then directly accessed it via my URL address bar and it loaded in just a few seconds. So the packet bottleneck seems to be at HST. Is that just a temporary issue?

I always downsize my images to fit typical board Internet browser displays and then have links to larger images if someone wants to view more image details. If that is always going to be the situation as was the case in the past then board members need to know that for TR's they ought post or link to downsized images and not full out of camera originals.

Another issue is when someone posts a long TR thread with lots of images that the html has not been set up for the image dimensions required. That causes the text in a thread to jerk around continually as images slowly load that is nauseatingly annoying. If the width and height for all images on a page have already been calculated before the text in a page begins to load, then the jerking around won't occur and instead the browser will pre-allocate space for each image as they gradually load. When a jpg image without height and width information in the tags is first accessed say from another page or database, the size ought be shown in the header so the forum software could be written to operate so.

There are many html coding pages explaining how to do this. Search "pre load web page images".

David

RE image size, not much can be done with the HST software/template as far as I know (perhaps Eric will chime in as well). I've noticed slow loading times with pages containing many images as well (on a GB network). Currently, there isn't a policy as to image size for images not hosted on HST via attachments. Smaller images would definitely increase page load times, and have the added benefit of smaller dents in the data plans for those of us who browse HST on mobile devices with data limits Further, the new HST template will force a browser to resize any images larger than a certain dimension so it fits in the template (something like 650px wide max)...in other words there isn't much added benefit to embedding images larger than this dimension (larger images can still can be provided via links, and in many cases that's the only way to view them anyway due to the template size constraint - some image hosting services don't make this as simple as it could be).

I extracted the Flickr path then directly accessed it via my URL address bar and it loaded in just a few seconds. So the packet bottleneck seems to be at HST. Is that just a temporary issue?

For images not hosted on HST, no data is trafficked via HST - it goes straight from source (eg flickr) to browser. It could be that the browser had already downloaded/cached the image. With many images on a single page the browser may start loading all the images on a page at once within the template (so the browser is not only downloading many images at once, but applying the css styles to them (eg resizing)).

Another issue is when someone posts a long TR thread with lots of images that the html has not been set up for the image dimensions required. That causes the text in a thread to jerk around continually as images slowly load that is nauseatingly annoying. If the width and height for all images on a page have already been calculated before the text in a page begins to load, then the jerking around won't occur and instead the browser will pre-allocate space for each image as they gradually load. When a jpg image without height and width information in the tags is first accessed say from another page or database, the size ought be shown in the header so the forum software could be written to operate so.

This has bothered me as well, and I've looked into fixes, but turned out to be difficult to do (and especially maintain) within the forum software, and could increase page load times and server load (which we are sometimes limited by during high traffic times).