I'm having trouble finding a solution to this problem. I have a site much like http://giphy.com, that runs a lot of animated gifs. The site currently runs a high cpu of 40-50%. I need to find I solution to lower the CPU usage without having to remove images because the images are chosen by the users. The site can have between 20 to 30 little animated gifts at a time. Any help would be greatly appreciated, Thanks
Unless you can combine all gifs inside a single file and display it at one. you're out of luck
Related
I'm optimizing my website and attempting to enhance the Largest Contentful Paint, but the only item that appears to require work are the optimised CSS files made with W3Speedster; here is a link to the Google speed test I performed. I want the LCP to be less than 2.5.
Any advice would be greatly welcomed; thank you!
That does not mean it takes over 3 seconds to render the content.
The rendering of you page from start render to document complete is only about 0.100 seconds.
You server is your biggest problem. It's slow.
The best thing you could do for your pages is either eliminate shareaholic.js, or get it to load sooner. It appears there may be some sort of lazyload. I does not load until 1.8 seconds. That is likely the reason the page rendering starts too late. That and too many font and CSS files. The Browser cannot begin rendering and till it has all the CSS and font files. shareaholic.js is your 15th file being loaded. There are 5 images being prefetched before this js.
You need to get the page to start rendering sooner. You could join some of the CSS files together to reduce the number of files being retrieved.
It's just your ads. :)
You'll most likely not be able to make it any faster. Maybe a little bit. I reduced it from 4 seconds on Cloudways Nginx servers to under 2 seconds on WPX Apache servers.
The problem is, when your ads are loading in the beginning a bidding war takes place. It's only after this they can load in the ads. So it'll always take time.
If I were you, I'd change the host to something like WPX, they will also help you make it as optimized as possible, with ads. If not changing the host, I'd focus on the CLS. Much bigger factor and easier to do something about.
I began to create a project, was following in the footsteps of this project "https://github.com/jamesmontemagno/Hanselman.Forms" but when I begin to navigate the menu items get the following message:
[Mono] [0xba013240] hill climbing, change max number of threads 4
[Mono] [0xba894098] hill climbing, change max number of threads 20
and also realized that is catching the menu
Hill climbing is when the number of threads is increasing to help with throughput as it is under some heavy load.
All that is happening here is there is some intensive work going on in the background. You can just look at the code and debug to where it performing a lot of work and optimize those functions.
On Android I also find large images will cause this issue rather quickly. Reduce the size of images (it must be the size not the quality as that doesn't make any difference).
I know this is probably not the best SO question ever because I don't have the relevant code (I don't know where it is and I can't find it). If anybody has seen this problem before or knows what is causing this I can't tell you how much I would appreciate it.
I have a storefront and the images in the storefront are showing up rotated 90 degrees to the left for no apparent reason.
The actual source files of the images are normal, if you look at the actual .jpg used in on the site they are upright.
How or why would they be showing up rotated? Is this some setting or a bug in WooCommerce?
Note
Yes, I've disabled every addon and used only WordPress and WooCommerce and the result is the same. Different themes yield the same result as well.
I discovered the problem in case anybody stumbles across this later down the road. The issue is with Apple's exif data and rotation information they store within each image. It is apparently not compatible with most computers and when you upload a picture from a mobile device from Apple (ipad, iphone etc.) you are likely to experience this phenomenon.
There is little than can be done about it, shy of uploading the images to a computer and manually fixing the orientation of all rotated images before using them.
I have a huge image that is going to be uploaded to my server. The width and height are for example: 2000x2000. I have multiple places in my code where I need the image to be 1000x1000, 250 x 110 or like 100 x 50. When they upload the image, should I make ASP automatically re size to these dimensions and save them on my webserver like image-250x110, image-1000x1000, image-original, and image-100x50 or is it fine to just to get the original image and re size on the fly through the code then show it to the users. I'm asking this because I'm worried that if too many people go on your website, re sizing the original huge image all the time would take alot of processing power and slow down the app. Or would something like this would be fine: http://www.hanselman.com/blog/NuGetPackageOfWeek11ImageResizerEnablesCleanClearImageResizingInASPNET.aspx
Your certainly want to resize the image when its uploaded since resizing a huge image of 2000 by 2000 pixels can easily take 2 seconds, even on a fast server. That's a delay your users are unlikely to appreciate.
What you posted, ImageResizer, is going to be your best solution, for many reasons, including:
There are a lot of potential problems when writing your own resizer, as detailed in 20 Image Resizing Pitfalls, including performance and stability issues.
If you redesign your site and want to change those image dimensions... it will be painful.
With ImageResizer, you only have one image - the nice big original image. All subsequent versions are served up (and cached) via the URL call. Note that the cacheable-version of ImageResizer requires a license.
ImageResizer will likely do a better job resizing images than yours will, both in quality and in file size, and also comes with filters, watermarking, and other features.
Resizing on the fly is a really bad option as it will eat up CPU.
If you can't pay for the cacheable version, you CAN use ImageResizer to resize the images on upload and save off the 3 versions or so of the images that you want.
I've used both methods -- written my own and used ImageResizer... ImageResizer is the way to go in my opinion.
I need to create a site that is very graphics-heavy (torn paper backgrounds with transparent shadows over textured graphics, etc.) One way that I was thinking of saving on file size was to drop all my background elements into one PNG. The issue is that this file is now 180k. If I break it up into various GIFs and a couple PNGs then it would be closer to 70k.
Does it really matter? What is "too large" these days for file size? Will anyone notice if the file is 180 or 70k?
If your users have fast access to your site (like, in an intranet), 180k is hardly a problem. If, on the other hand, the site is used by The Generic Older Person With A Humorously Slow Connection, it's probably going to be a problem. If your users use GPRS, but have endless patience, it's probably not going to be a problem. If the site gives out a million dollar to whoever has the patience to wait out the load time, transfer speeds are not an issue. And so on.
What I'm saying, it really depends on your requirements and constrains. This requires you to know (and subsequently tell us, for us to be more helpful) many things before you can get it close to right.
To avoid those pesky downvotes for very-valid-answers-but-simply-doesn't-please-someone, here's my answer:
180k divided by a standard ADSL modem transfer rate = 180kB / 100kB/s = 1.8s = endurable.
Is there a reason not to use the smaller images? It sounds like you've already broken it up, so why not go with the smaller, faster method?
From a pure relativistic point of view, 70k will take only 38% of the download time that 180k would (approximately). If you're expecting high traffic or want fast load times, every bit helps.
You have to compare the time it takes to request all the separate images and the time it takes to download the one large one. The issue is with HTTP requests.
I suggest you run some tests with Google's Firefox extension, Pagespeed to see if there is a huge difference between the large png or the separate ones.
One benefit I can think of, besides fewer HTTP requests is that your site will load all at once instead of gradually as all the graphics are downloaded. The bottom line however, as Henrik said is that it depends on your requirements.
I'm sure you're aware that splitting into multiple images means additional connections to the server to retrieve them, with associated lag on each, and the additional size of the request and response headers.
Since browsers restrict the number of active connections to each server (browser version dependent) this may end up taking longer than retrieving a single image. The usual workaround to lift the limit is to use a separate "images" server, or a DNS alias that maps to the same host.
And unless you require animation, I'd always recommend PNG over GIF.
Make sure that the site looks fine with images disabled first (so alt tags, width and heights set, correct colours used) and then split the images based up into groups. Group all of your buttons into one image if possible (using css sprite sheets), and all of the borders into another. Keep large images in separate files (so site background, headers).
The more images you have, the more the browser can parallelize the requests. However, if you split them up too much then different images will load at different times, making parts of the site pop in. It's a bit of a trade off, but that's the joy of programming :)
The better your site looks before the images are visible, the less the user will mind the speed of downloading the images.