Bandwidth usage with Levels

[koala]

I've noticed ever since we switched from our old MMUI home-made website to the Levels ReadyTheme that our bandwidth usage has increased substantially.

I worked with Miva support on a few tweaks and they've blocked search bots from parts of the world we don't do business in (ie: China & Russia), but these tweaks have only made a small impact on bandwidth usage.

I'm thinking maybe the culprit are the high res. photos on product pages. Do all of these images pre-load or are they only downloaded by the users device once they're clicked on?

I'd like to get this figured out as an extra 300-400 GB of data every month is quite expensive :)

Has anyone else noticed their bandwidth usage increase with this theme?

*/-edit-/* - I may have answered my own question and I feel silly for not looking closer at this. On the PROD page under the Product Display Layout Image Machine section, there is of course a "Preload Images" checkbox which was ticked off. Would unchecking this be the answer?

[Matt Zimmermann]

By default, all images are downloaded on accessing a web page. A way around this would be to use JavaScript to "lazy load" the image which would delay the actual loading of them until either a user interaction or the page is scrolled for the images to come into view. There are a few other items, like deferring script file in the head tag and at the bottom of the body. If support cannot assist you with these, our professional services team can get them done for you.

[koala]

The way I understood image loading is that the "large" image that is linked from a thumbnail would never actually load until the user clicks on the image link in question. I thought perhaps the "preload" option in Miva then would mean that it's loading these high res. versions in the background, even when the user hasn't explicitly called for them to be loaded.

[Matt Zimmermann]

That is correct; I missed the second part of your question. The solution I was referring to will help with any images which are already part of the code that have a valid SRC attribute.

[koala]

Ah yes, thanks Matt. I think the lazy loading idea is great if someone wanted to continually load products on a category page, rather than paginate them.

[Bruce - PhosphorMedia]

You might consider using more aggressively compressed images on the home page (the single page most often accesses) and ones that are the correct size for the desktop display at least. (Those images are being 'shrunk' to fit...and I don't see how they are used full size anywhere on that page.

Also, you might consider NOT loading any resource on the home page that isn't necessary for the home page. While this doesn't always make sense for other pages (as they will need those resources eventually) the home page is usually a very large chunk of your entire bandwidth source traffic.

[koala]

You might consider using more aggressively compressed images on the home page (the single page most often accesses) and ones that are the correct size for the desktop display at least. (Those images are being 'shrunk' to fit...and I don't see how they are used full size anywhere on that page.

Also, you might consider NOT loading any resource on the home page that isn't necessary for the home page. While this doesn't always make sense for other pages (as they will need those resources eventually) the home page is usually a very large chunk of your entire bandwidth source traffic.

Yeah I've debated changing those. I just used the sizes that Miva had in the default frame work, figuring maybe the larger sizes are used. I think in tablet mode, they're higher res.

Our homepage is only 7% of our traffic, or something like that, so it's not too big of an impact

[William Davis]

We just got slammed as well from referring IP 94.236.198.60 (Bulgaria). I need to reach out to MIVA tech Support as well.

One module I am going to miss when we finally launch our M9.6 store from MM4.24c next week is Sebenza "Fatal Error Plus". This module would notify merchant via email whenever someone requests to view a MIVA Merchant dynamic page that either never existed, or no longer exists. The visitor will then be (302) redirected to an alternate static error page to facilitate the requestor in finding the information requested, or something similar.

The module has several very insightful email render tokens, and we made very good use of it. The email subject and body may seem verbose, but rest assured it was as a result of many tweaks caused by robots, some good (e.g.: McAfee SECURE, etc...) and some bad.

Sample email:
Screenshot 2016-11-20 13.41.00.jpg

For example, why we choose to display IP address in the subject line so we can create a email rule based where they were coming from and type of error).

Why they links, and error legend? Back then MIVA error codes were not well documented, the links were configured in a way that when clicked on would perform a specific type of key phrase search on a specific site making it easier to research, at least for us. As we learned what each error meant, we would update the error coded legend.

I have no doubt these types of problems are no where near as common today as they were back then, nevertheless it would be great to have a module like this.

[koala]

I'd really like to figure this out. We actually went from about 150 GB of data transfer in July to 1.2 TB last month.

[William Davis]

I'd really like to figure this out. We actually went from about 150 GB of data transfer in July to 1.2 TB last month.

You and I both. I just opened a ticket. Can you please report back on you r finding regardless where they lead you?

[koala]

You and I both. I just opened a ticket. Can you please report back on you r finding regardless where they lead you?

Yes sir, I just re-opened an older ticket of mine from back in September so that they have a bit of history on our issue. I'll keep you updated.

I'm mostly worried about the potential cost. If we're paying for an extra terrabyte of data transfer that isn't genuine, that's a ton of money.

[koala]

I don't really like my response from Miva on this one...

Part of the issue I'm having is that when you take our most-visited pages and look at the data usage, the numbers simply do not line up.

As an example, our home page is 1.7 MB. Assuming you weren't caching anything, you'd have to load that page 700,000 times to equal the 1.2 TB of data we used last month. Our entire website last month did not receive 700,000 visits, across all pages.

It's a very perplexing issue!

[William Davis]

I don't really like my response from Miva on this one...

Part of the issue I'm having is that when you take our most-visited pages and look at the data usage, the numbers simply do not line up.

As an example, our home page is 1.7 MB. Assuming you weren't caching anything, you'd have to load that page 700,000 times to equal the 1.2 TB of data we used last month. Our entire website last month did not receive 700,000 visits, across all pages.

It's a very perplexing issue!

Hmm, you might want to consider installing your own free Open Web Analytics software that parses and analyzes raw Web server log files, then export report to excel if you need to further your research -just an idea. Let me know how it works please.

[koala]

Thanks Bill, I'll take a look into that when I get some time!

[koala]

A small update on my end. We're still using way more bandwidth than normal, but I have noticed it's dropped a fair bit from it's peak.

Our actual site visitors and page views have all remained fairly consistent, so I don't know what to attribute the new "drop" to, but it's at least somewhat encouraging.