I am new to NextJS but I have a very good experience in ReactJS and Webpack. My question is NextJS offers a package 'next/image'. I want to know or understand very deeply that why I should use their package to load an image no the default img tag.
In their doc they say a line like this We can serve an optimized image like so. What do they mean by Optimized Image and Why ReactJS or any other package not doing that?
Basically it takes the heavy lifting of optimizing images from you. The docs say:
The Automatic Image Optimization allows for resizing, optimizing, and serving images in modern formats like WebP when the browser supports it. This avoids shipping large images to devices with a smaller viewport. It also allows Next.js to automatically adopt future image formats and serve them to browsers that support those formats.
So you do not have to worry whether the users browser will support a new image format like web/p, nextjs will automatically create a load of optimized images for all device heights and widths, including fallback formats like jpgs for older browsers.
They also optimize performance:
Images are lazy loaded by default. That means your page speed isn't penalized for images outside the viewport. Images load as they are scrolled into viewport.
And care about SEO:
Images are always rendered in such a way as to avoid Cumulative Layout Shift, a Core Web Vital that Google is going to use in search ranking.
In conclusion, using next/image will make your life considerably easier by deploying a variety of techniques to improve image handling. It may not work for every image, but in that case you could take a normal <img /> tag and optimize it manually. But that will be an edge case.
next/image changes the image to WebP format when you request. WebP format reduces the size of the image while keeping the quality.
It also makes lazy loading which is great if the user doesn't see your entire page.
Related
I am building little shop application and now thinking about the faster way, how to upload images - I need images in 4 sizes. The first idea - from upload create 4 thumbnails and that's all - probably the easiest way, but what I am worried - creating 4 sizes through upload can take lot of time... that's what I don't like and I would like to avoid it.
The second idea is upload image - for example in the size 300x300 and in a moment, when I would need in the shop display thumb of this image, so in HTML and CSS I just set the value :style => 'width: 165px;'.
What you think about that? What would be the best variant?
I don't think this question relates to rails, but is a more general one.
Typically, you do want to create the images in all sizes they would be utilized. Creating four sizes at the time of upload doesn't usually take that much time (I am referring to uploading the image once and then creating the needed images on the server side based on that) - at least if you compare it to combined time of users all downloading the biggest size image and then resizing it on the fly when all they need is a small thumbnail. Normally, uploading the images does not happen that often. Generating the other images could also possibly be deferred to a scheduled job that would run nightly, so it wouldn't impact the user experience on the admin side.
That said, if your users have to anyways every time download the biggest image, it would be in the cache anyway and no extra overhead would incur if you then resize it using css wherever you need it in a smaller size. In that case I would think it would be ok just to use the biggest size. Usually you can avoid using the biggest size images on most use cases.
Use the carrierwave gem to manage your uploads. Configure the gem with multiple "versions".
As eis suggests, processing the images is not the performance bottleneck, but if you really want to get fancy use the delayed_job gem to handle the processing asynchronously.
When configuring carrierwave, you will also need to setup the actual processor. I use the full-blown rmagick, but you can use minimagick which is simpler to setup. It's all detailed in the carrierwave readme. For rmagick/imagemagick, here's a thread that touches on that.
Also, as eis suggests, images are generally cached reliably by the browser, and these days browsers do a decent job of resizing images on the fly, though generally, the better the processor, the better the results, and that's why I use rmagick.
One last note, unless you can dictate what users are selecting for upload, you will most likely need to process the image at least one. E.g., someone might upload a huge 8000 X 6000 pixel image with little compression. You would not want to serve up that image since you have less control. And once you've gone to the trouble of setting up the image processing, it's a trivial thing to add a few more output sizes to fit the various display contexts.
I have an ASHX handler that I am using to display images that are stored in a database. I display the images as thumbnails and then full size if the user mouses over them.
How can I combine the images at runtime to produce CSS sprites for use in this situation?
If it can be done does anyone have suggestions on where to start?
UPATE
It seems like most people are saying this is not a good situation to use sprites in. I'm new to the sprite concept so please bear with me.
If I am going to be loading 30 thumbnails on a page from my database everytime why would it not make sense to pass them from the server to the client as one large image instead of passing 30 individual images? Wouldn't this be faster? Isn't this the purpose of CSS Sprites?
As far as the browser is concerned, an HTTP resource is an HTTP resource and it is irrelevant if the server produced it by reading a file from a hard disk, taking data out of a database, or spewing the content of a random number generator through an algorithm that would output valid PNG data.
You just need to generate your images from the data as normal.
That said, since the images are content, CSS would be an inappropriate tool to include them in the document. You should use an <img> element.
You have a couple options.
Your handler can combine the images on the fly that it gets from the database and send the whole thing down to the browser.
OR (and I like this one better)
You create the merged image at the time the images are uploaded to your site.
The second is better as the conversion only has to happen once and therefore means that you only have to spend those resources once. It does mean you are essentially storing 2 copies of the image, but that's fine.
UPDATE
I believe I misinterpreted what you were trying to do. I thought you were trying to combine the thumbnail with the full blown image. Instead, you appear to be really asking how to combine all of the thumbnail images.
In that case, it's even more of a bad idea. As David Dorward stated CSS is used to control layout. You're talking about content. However, the semantic issue aside, in the event you want to make tweaks to the layout your going to have to modify your code which creates the sprites to begin with. What if you decide to do 35 images? Or, change that to do 18?
By going the sprite route your pretty well screwed by being forced to modify code for any layout change which is NOT good style.
To cover that last question: wouldn't it be faster? Probably not. Under this scenario you would have to create the sprite on the fly, which introduces server overhead, which slows everything down. At most it might be a wash in the delivery time. At worst, you incur a large server and development performance negative impact.
Check out http://www.RequestReduce.com. It not only creates the sprite file automatically, but it does it on the fly through an HttpModule along with merging and minifying all CSS. It lso optimizes the sprite image using quantization and lossless compression and it handles the serving of the generated files using ETags and Expires headers to ensure optimal browser caching. The setup is trivial involving just a simple web.config change. See my blog post about its adoption by the Microsoft Visual Studio and MSDN Samples gallery.
I completely agree with David. Just a quick note regarding David's last point: That's only if the images are content. However, if they were part of the layout, then CSS would be appropriate.
That said, with this use case, sprites aren't a good choice. One of the purposes of thumbnails is to cut down loading time, which a sprite would make worse for a gallery. A better pattern might be using a lightbox or something similar with two images rather than one, with the larger being requested on demand.
Sprites are not a good solution here.
To answer your update, sprites are ideal for many small images, where the overhead of a new HTTP request outweighs the few bytes being sent for a small png or gif (e.g. 16x16 icons, etc). For larger images the time of the HTTP request becomes less important overall as the download time increases.
Packing images into a sprite also means that they will execute one longer request and other requests will have to queue behind it. If the important thing is to get the thumbnails showing quickly, then make sure those get loaded first before starting to load any larger views of the same images.
Any larger files that don't display at the initial page load should be late-loaded (window.onload) or lazy-loaded (as needed by click or hover actions).
I'm in the process of optimizing a high traffic site. The site I am working on has many widgets - say 20 or so and only 7 are loaded by default. I was thinking of separating my css and image sprites for faster load times for the default widgets.
For the rest of the non-default widgets, I was thinking of having a separate css file and image sprite for each and every one. This way, when a user selects a non-default widget, I could dynamically inject the CSS file for that particular widget.
My question is - do you think this is OK to do or potentially worse for optimization since I would have more HTTP requests now since the non-default widgets would have their own css and image sprite files? Obviously though, the file sizes now would be cut down too.
Thoughts? Or anyone else who tackled the same issue?
do you think this is OK to do or potentially worse for optimization since I would have more HTTP requests now since the non-default widgets would have their own css and image sprite files?
Well, in the end that's down to mathematics and something only you can answer :) It will depend on what the actual numbers look like.
Keeping the default widgets' sprites in one file sounds obvious from what you describe.
As for the non-default widgets, If you have the technical means to do so, you could try analyzing your usage statistics. Which of the non-default widgets are being used the most? Are there some that stand out strongly from the others in terms of requests? Then build one image with all the necessary sprites for those, and keep separate images for the rest.
Also take into consideration whether the cost-benefit ratio is really good. Working out and using CSS sprites can increase maintenance costs in the long term, as updating graphics becomes a more difficult task that it was before. Now reducing the number of requests is a very important optimization technique, but there are other factors as well. Maybe the time and money saved by not using sprites could be better used somewhere else, like in improving the site's usability or buying new RAM for the server.
A couple of years ago, we had a graphic designer revamp our website. His results looked great, but he unfortunately introduced a new unsupported font by the web browser.
At first I was like, "What!?!"... since most of our content is dynamic and there was no real way to pre-make all of the images. There was also the issue of multiple languages (since we knew Spanish was on the horizon).
Anyway, I decided to create some classes to auto-generate images via GDI+ and programatically cache them as needed. This solved most of our initial problems. However, now that our load has increased dramatically, there has been a drain on our UI server.
Now to the question... I am looking to replace most of the dynamic GDI+ images with a standard web browser font. I am thinking of keeping some of the rendered GDI+ images and putting them in a resx file, but plan to replace most of them with Tahoma or Arial fonts via asp:Labels.
Which have you found to be a better localized image solution?
Embedding images into the resx
Only adding the image url into the resx
Some other solution
My main concern is to limit the processing on the UI server. If that is the case, would adding the image url to the resx be a better solution compared to actually embedding the image into the resx?
You should only need to generate each image once, and then save it on the hard disk. The load on your site shouldn't increase the amount of processing you have to do. That being said, it almost sounds like you are using images for things you shouldn't be. If there are so many different images that you can't keep up with generating them, it's time to abandon your fancy images for things that shouldn't be images, and go back to straight text. If the user doesn't have the specified font installed, it should just fall back to a similar looking font. CSS has good support for this.
see my response here
This can be done manually or using some sort of automated (CMS) system.
The basic method is to cache your images in a language specific directory structure and then write an HTTP handler that effectively removes the additional directory layer. eg:
/images/
/en/
header1.gif
/es/
header1.gif
In your markup or CSS you would just reference /images/header1.gif. The http hander then uses session (if language is user specific), or config (if site specific) to choose which directory to serve the image from.
This provides a clean line bewteen code and content, and allows for client side caching. Resx is great for small strings but I much prefer a system like this for images and larger content. especially on the web where it is typically easy to switch images around.
I had the same problem a few years back and our interface team pointed us to SIFr. http://wiki.novemberborn.net/sifr/
You embed your font into a Flash movie and then use the SIFr JavaScript to dynamically convert your text into your font. Because it's client-side, there is no server-side impact.
If the user doesn't have Flash or JavaScript installed, they get the closest web-friendly font.
As an added bonus: because your content is still Text -- Google can search and index the content -- a huge SEO optimization.
Because of caching, I'd rather add only the image url into the resx. Caching is much better for static content (i-e plain files ) than for generated content.
I'd be very cautious about putting text in images at all, CSS with appropriate font-family fallback is probably the correct response on accessibility and good MVC grounds.
Where generation really is required I think Kiblee and JayArr outline good solutions
Usually Flash and Flex applications are embedded on in HTML using either a combination of object and embed tags, or more commonly using JavaScript. However, if you link directly to a SWF file it will open in the browser window and without looking in the address bar you can't tell that it wasn't embedded in HTML with the size set to 100% width and height.
Considering the overhead of the HTML, CSS and JavaScript needed to embed a Flash or Flex application filling 100% of the browser window, what are the downsides of linking directly to the SWF file instead? What are the upsides?
I can think of one upside and three downsides: you don't need the 100+ lines of HTML, JavaScript and CSS that are otherwise required, but you have no plugin detection, no version checking and you lose your best SEO option (progressive enhancement).
Update don't get hung up on the 100+ lines, I simply mean that the the amount of code needed to embed a SWF is quite a lot (and I mean including libraries like SWFObject), and it's just for displaying the SWF, which can be done without a single line by linking to it directly.
Upsides for linking directly to SWF file:
Faster access
You know it's a flash movie even before you click on the link
Skipping the html & js files (You won't use CSS to display 100% flash movie anyway)
Downsides:
You have little control on movie defaults.
You can't use custom background colors, transparency etc.
You can't use flashVars to send data to the movie from the HTML
Can't use fscommand from the movie to the page
Movie proportions are never the same as the user's window's aspect ratio
You can't compensate for browser incompetability (The next new browser comes out and you're in trouble)
No SEO
No page title, bad if you want people to bookmark properly.
No plugin information, download links etc.
If your SWF connects to external data sources, you might have cross domain problems.
Renaming the SWF file will also rename the link. Bad for versioning.
In short, for a complicated application - always use the HTML. For a simple animation movie you can go either way.
You also lose external control of the SWF. When it's embedded in HTML you can use javascript to communicate with the SWF. If the SWF is loaded directly that may not be possible.
Your 100+ lines quote seems pretty high to me. The HTML that FlashDevelop generates for embedding a SWF is only around 35 lines, with an include of a single swfobject.js file. You shouldn't need to touch the js file, and at the most would only have to tweak the HTML in very minor ways to get it to do what you want.
In my experience not all browsers handle this properly. I'm not really sure why (or which browsers) but I've mistakenly sent links like this to clients on occasion and they've often come back confused. I suspect their browser prompts them to download the file instead of displaying it properly.
One upside I can think of is being able to specify GET parameters in the direct URL to the SWF, which will then be available in the Flash app (via Application.application.parameters in Flex, not sure how you'd access them in Flash CS3). This can of course be achieved by other means as well if you have an HTML wrapper but this way it's less work.
Why would you need 100+ lines of code? Using something like swfobject reduces this amout quite some (and generally you don't want to do plugin detection, etc. by hand anyway).
More advantages:
Light weight look cuz you can get rid of the header with all the tool bars that seem to accumulate there and even the scroll bar is not needed. This enhances the impact when you are trying to show a lot of action in a short flash.
The biggie: you get it in a window that you can drag larger or smaller and make the movie larger and smaller. The player will resize the movie to fill the window you have. This is great for things like group photos where everyone wants to enlarge to find themselves and their friends. I've done this for a one frame Flash production!
Downsides:
As with popups in general, if you are asking for multiple ones from the same site, and you want different size popups, the browsers tend to simply override the size you ask for in window.open and reuse whatever is up. You need to close any open popup so the window.open will do a fresh create. It gets complicated, and I have not been able to get it to work across pages in a website. Anyone who has done this successfully, pls post how!
Adobe should be ashamed of themselves with the standard embed, which defeats the puprose of convention over configuration. Check ^swfobject (as mentioned above) or swfin