Also note that pages primary image source the large image which is much bigger than needed. On a large screen (1920px 1080px resolution) the primary image is scaled down to 384px which is still 116px less than the medium size. Changing out the primary image path alone cuts down the primary image bandwidth by more than 3 times, would speed up the page load time, and of course would have a positive impact on SEO. If SP had 50,000 page views in a given day you would theoretically save 3.4 Gigabytes per day from this change alone.

95.6KB (large image)
-27.4KB (medium image)
= 68.2KB (differential, bandwidth saved/image)

68.2 * 50000 = 3.4GB of bandwidth saved in a single day!

Josh Lewis wrote:Also note that pages primary image source the large image which is much bigger than needed.

The problem with changing to use smaller images is that the smaller image isn't always available. In some cases, when the size of the original image is too small, there are no large, medium, or even small versions of images. And it's not a quick check to see what sizes are available. So in the cases where we're using images on pages, we usually opt for "original" because that's the only one that will definitely be there.

As for using "large" sized images, those are needed on pages when viewed on certain devices. The smaller images are not large enough to meet the need on most tablets without significant loss of resolution.

Montana Matt wrote:

Josh Lewis wrote:Also note that pages primary image source the large image which is much bigger than needed.

The problem with changing to use smaller images is that the smaller image isn't always available. In some cases, when the size of the original image is too small, there are no large, medium, or even small versions of images.

This can be fixed with a simple conditional logic checker when loading the image:

Code: Select all

<?php
   $fileName = '364161.jpg';
   $largeSrc = 'https://www.summitpost.org/images/large/'.$fileName;
   
   if (@getimagesize($largeSrc)) {
      echo 'Success large';
   }
   
   else {
      $mediumSrc = 'https://www.summitpost.org/images/medium/'.$fileName;
         if (@getimagesize($mediumSrc)) {
            echo 'Medium image';
         }
         else {
         $smallSrc = 'https://www.summitpost.org/images/small/'.$fileName;
            echo 'Mini image';
         }

   }
   
?>

I tested this PHP code on my own server to validate that it works. Of course you will want to replace 364161.jpg with the image you are currently referring to and replace 'Medium image' with a small snippet of HTML to load the proper images. I kept it as text for your testing pleasure. I also set it up so that it only checks for a medium or small image size if a large image doesn't exist so that it doesn't have to make a query for other sizes unless absolutely needed.

Montana Matt wrote:As for using "large" sized images, those are needed on pages when viewed on certain devices. The smaller images are not large enough to meet the need on most tablets without significant loss of resolution.

I see the scenario you mention as seen here (browser scaled down to around 939px):



However making a primary image cover most of the screen for a page doesn't really enhance the user experience. It makes for more scrolling. Unless it was properly integrated to feel like a cover design with text placed just right it makes it more awkward in my honest opinion. If a 500px max-width was set when sourcing from the medium directory it would prevent the image from being stretched. Here's what it would look like in tablet view:



I know this because what is shown was made using actual code.

Josh Lewis wrote:This can be fixed with a simple conditional logic checker when loading the image

I had implemented that code in the past and it is far too slow to use in production.

Montana Matt wrote:I had implemented that code in the past and it is far too slow to use in production.

So your saying it's faster to load a large image (instead of medium) than it is to check if a large exists and swap accordingly? If so sounds like PHP is a bit slow with logical checkers.

Did the past version of the PHP code check the medium image regardless to if the large image loaded? I could see that being an issue.

Josh Lewis wrote:So your saying it's faster to load a large image (instead of medium) than it is to check if a large exists and swap accordingly?

Yes. The check actually loads the image into PHP memory, so you're actually downloading the image 2 times with the code you showed (once when you check what size is available and again when you serve the page).

Josh Lewis wrote:Did the past version of the PHP code check the medium image regardless to if the large image loaded?

I don't understand the question.

Basic question here:
When an image is uploaded, is its size (either dimensions or bytes) recorded? I know that its byte-size is apparently checked against the 8Mb size limit, therefore it is a knowable value. Can the size of the image somehow be stored in a database to use as the reference for the logical check instead of downloading the image to do that check? Then there would only be one loading--the final loading.

Klenke wrote:Basic question here:
When an image is uploaded, is its size (either dimensions or bytes) recorded? I know that its byte-size is apparently checked against the 8Mb size limit, therefore it is a knowable value. Can the size of the image somehow be stored in a database to use as the reference for the logical check instead of downloading the image to do that check? Then there would only be one loading--the final loading.

I actually implemented that exact solution a while back. There is a table where the dimensions (width and height) of an image are saved and I used that in some cases to determine what sizes are available. I haven't looked in a while now (it was a few years ago when I implemented this) but I believe that sometimes the size of the image is not recorded in the database but could not figure out why. So the solution didn't work as intended and I didn't go back to revisit it because there was a lot of other things that were more pressing that needed to be done on the site.

Is SP secure now? It may help with space if we could delete some of our own photos, especially ones that were created erroneously.

Scott wrote:Is SP secure now?

Yes, it's locked down pretty tightly.

Scott wrote:It may help with space if we could delete some of our own photos, especially ones that were created erroneously.

Anyone can mark any of their images or pages for deletion. I go through and execute the actual deletion every day. This seems to be the safest way to ensure nothing gets accidentally deleted or deleted with malicious intent.

What about setting up a GoFundMe page to try to generate some money to pay for running the site for a few years? Maybe this could be done in conjunction with less ads to at least keep the site up until a more viable long-term solution can be found.

I admit I'm not a GoFundMe expert (if I was I'd have one to fund my lifestyle!) and I don't know how much such a page would generate for the site.

Perhaps the easiest antidote to the ads from hell might be to find a sponsor/owner, like REI is with Mountain Project (MP). But all the “fat trimming” some members are now reluctant to do might just happen anyway (possibly along with more) if a new owner came on the scene with their own criteria. MP is not plagued with lots of incomplete pages, phantom members or a massive database of low-scoring photos. This is something to think about when we talk about finding a sponsor/owner for SP. Cleaning up our own house would certainly make SP more marketable as well as being more manageable. It’s helpful to remember a good sponsor would not kill their own vehicle of advertising by demanding ill-placed ads like we have now on SP.

The idea of any kind of SP membership fees might offend some members, but I have to wonder how committed to a quality site those members really are, if they would not be willing to allow for even a small sum annually for the privilege of participation in the development of something that can be truly great? The old saying of “putting your money where your mouth is” probably has some relevance here.

Has anyone considered Lists of John’s (https://listsofjohn.com/index.html) plan for generating funds to offset its expenses? While there are many differences between SP and LOJ, the point is that they have about 5,000 members and probably around 300 per year are motivated to go for the $20 minimum-per-year membership (they may contribute more, of course). LOJ paying members have expanded services available to them, but a basic membership is still free to anyone. LOJ has no ads or pop-ups and is pretty clean and functional.

No doubt SP has much larger operating costs, but then SP also probably has the potential to attract more members willing to pay at least a small annual fee. Perhaps some expanded privileges could go with that? Soliciting SP membership input on this idea would probably turn up some good suggestions.

Because of the large size of SP, I have to wonder if the most likely solution might involve a combination of several factors, including but not limited to some type of membership fees, a page set up to accept supplemental donations, a sponsor (or two) and trimming the SP operating expenses by eliminating empty pages and excessive photo storage costs. This approach would remind me of how doctors often prefer to treat high blood pressure these days – instead of one large dose of medication they give several smaller doses of varying medications, allowing for easier adjustments.

Despite being a SP member for more than 11 years, I still do not have a good idea of the management structure of SP or who really makes the “final decision”. But I do think that the longer we just tread water here, “hoping something will happen”, the more likely it is that SP’s problems will continue to grow while the possibilities of implementing a good cure will fade and fade until SP is gone. The ads from hell might help costs for a short time, but will ultimately be the poison that kills SP. I still would love to see whoever is in charge here recognize this and take the steps necessary to cure SP’s problems and set the stage for a leaner and more efficient SP that will be well-suited for long-term viability. I think many SP members would be happy to help, if SP management would solicit that help.

Was scrolling through a page on my phone seeing a large fixed banner ad that follows you. Closed it. Closed the second one. A third one? Okay carefully closes it. The 4th one loads which I carefully hit the close button. It redirects me to an ad site, puts the browser in full screen, and plays very loud music in the quiet area of a library. Due to how intrusive the ad was even after hitting silent it was still loud forcing me to use mute on my phone. 3GB of RAM isn't exactly a slow phone especially with minimal apps and keeping the system processes low.

Had to deal with a lot of dirty looks.