I have a ReactJS application. I have 100 images(icons) of country flags. I need to use them in my application. I have 2 ways to do so, want to know best way to do so such that -
1) I only have to make 1 hhtp call to get the images
2) It is the most optimum way to handle this scenario.
Method 1 - I can sprite all the 100 images. And then make 1 http call to get the image and make use of background positions to get correct image.
In this method I wanted to know if
a) If using CSS Sprites is the modern way of doing so? Any better way?
b) If using CSS sprites, any tool to create a Sprite image and get the correct position values?
Method 2 - In my project, currently all images are inside a /src/images folder. If I put the 100 images inside this folder, it will make 100 http calls. Correct me if I am wrong. Can I put them inside /public/images folder so that the images are bundled and not excess http call is to be made? (If I reference any image file in public folder I get the error - 'Relative imports outside of src/ are not supported.') Anyway, where do you usually place images, inside /src/images or /public/images? What are the advantages in either?
I would go with the second option. Depending on the tooling, you can use Webpack or other bundlers to compress (gzip or Brotli compression).
You can optimize images to make sure they are not overly large and properly formatted, then compress and serve from a reverse proxy server.
To further boost performance, you can defer off-screen assets so that the images that you need are loaded as they are needed which lowers the initial fetch size.
Lastly, you can use in-memory caching, S3 (or other cloud storage), and a Content Delivery Network (like Cloudforce, Akkimai, and others), to store images in the cloud in close proximity to the user. CDNs are optimized to deliver such static assets and might be something to consider incorporating.
With such a heavy usage of images, I would suggest that you LazyLoad the images with option 2.
Consider a case where you have 100 products on your web page. If you request all the 100 product images at the same time and at the very beginning, it would slow down the load time. With lazy loading, we would only load, let’s say, 30 images that are visible to the user initially. Then, when the user starts scrolling down the page, we will keep loading more images. This would help improve the initial load time and the user experience. There will be cases where the user doesn’t scroll down the entire page and hence some images would not get loaded at all. Thus, you also end up saving on bandwidth costs for image delivery.
Since you are using reactjs, there are many packages available for this. Here I'll suggest one of them but feel free to explore more: React-Lazyload
You can even deliver the images through some CDN to further fasten the loading. Also, resizing them to actual needed size is a good way. Moreover you can also use JPG encoded at 80-90 quality as it won't make much of a difference in image quality, but reduce the file size dramatically.
Related
What bundle size in KB should I consider splitting at? At what point does weight become too heavy that I should split it out. My whole bundle without splitting is around 800KB so it loads relatively fast. I am just trying to figure out if it should be around 10KB/ 100KB, etc... Moment.js takes around 50KB, so I am trying to figure out if I should split out all modules that contain moment for example.
If I don't code split does that mean overall it provides a better user experience once they load the initial page since every other page would load faster? I get this would lead to a bad first experience of loading the page, but am just trying to figure out the tradeoffs.
Haven't found any good resources with this information. I am using create react app.
800kb is not super big but still, the smaller your bundle is, the better.
I think the main problem having only one bundle is that, if you change one single character in your app, all your clients will need to download everything again.
Let's take an example:
You see a typo in your code. You already have thousands of users who downloaded the 800kb bundle with this typo.
You push a fix (only one character change).
All your users need to download the whole bundle again (yes, they need to download Moment.js again). Be it 1*800kb or 8*100kb, they will still need to download 800kb of data. (related question)
What you want to do, is to split your chunks in a way that allows users to only download the files that changed. For the other files, they can be cached, so no need to download them again. So in the example above, you don't want your users to download Moment.js again because... it didn't change at all.
I suggest you to read this very nice article about how to split your bundle:
https://medium.com/hackernoon/the-100-correct-way-to-split-your-chunks-with-webpack-f8a9df5b7758
You can also add one level of split by creating "per page" chunks. Here is how to do it with React: https://reactjs.org/docs/code-splitting.html
If you make changes on Page A, your users won't have to download the chunks for Page B again.
So i stumble on this component called lazyload.
What does it do and advantage and disadvantage of using it ??
Just curious about it because i watch some of john papa's videos and he keep mentioning it.
They idea of lazy load is that you only load something when you need it.
For example: at startup of your application you might not need a library to validate your form fields. (you only need it when someone actualy fills in a form and submits it).
Lazy loading makes sure its only loaded when needed.
The Plus:
Reduced start/load times & size.
Packages/data that are not used by the current user, will not be loaded.
Minus:
You have to have more seperate packages you can't minify and bundle them together.
More request to the server (because you can't bundle them).
could have a load on first use experience, the first time user does something the application needs to load some extra stuff.
conclusion & advice
So consider the size and the lifecycle of your application. If the application is small and you package all in one. probably the simplest approach would be to package everything in one. it's a bit of a longer load time, but after that the javascript gets cached in the browser anyways so it doesn't matter after first load.
Reasons you want to lazy load:
You want to be able to update seperate parts of the applications (thus not bundle it)
Application becoming problematically big. you want to cut it up in smaller parts.
You don't bundle your javascript files (great example here before angular was requirejs).
You have a lot of different types of users using the system each with completely different set of scripts.
Every page uses completely different set of javascript. (not likely when you use angular)
I’m writing webpage that will display hundreds of pictures. Problem is size of image(+-5MB). This images are background-image of div. I use JS for changing this background-image.(sometimes 1 per sec.) Is there any way how to shrink those images or how to speed up loading? (I can't modify this images by Photoshop or another similar SW. I must use the original.)
What do you mean you must use the original if you wish to shrink the images? In my opinion the file size is not suitable for a web application and you must decrease the file size of these. If you have access to a server side technology like PHP or ASP.NET you can modify the images before displaying them using libraries like ImageMagick (http://php.net/manual/en/book.imagick.php) or ASP.NET Sprite and Image Optimization Library (see http://www.hanselman.com/blog/NuGetPackageOfTheWeek1ASPNETSpriteAndImageOptimization.aspx) but these will use resources to process and thus your site will still have an performance overhead.
I advise you to modify your images using a tool and don't have the server or browser modify these. If you don't have access to a tool like Photoshop or GIMP you can use online tools to create reduced versions of your originals like Yahoo's smush.it - http://www.smushit.com/ysmush.it/
Not the best answer but I hope it helps.
I have a number of JavaScript functions like the following on my page:
function fun1(){...}
function fun2(){...}
function fun3(){...}
function fun4(){...}
I may use fun1 in one or two pages, but the other functions only for specific pages.
My question is: should I include all the functions in one file like script.js or include specific functions for specific page? Which one is better for speed optimizing?
I guess your question is about optimizing page loading speed.
I would suggest grouping them as mush as possible in a single js file.
Otherwise, you would have to load a lot of small js files, increasing the page loading time.
Consider minifying your JS files too.
Depends on the size of the functions, your visitors' access patterns, your cache settings and other circumstances. The speed of downloading a file depends on how many TCP packets the server has to send. (Packet sizes tend to be around 1,5K.) Increasing the file size only matters if means the file needs to be broken into more packets (the client-size delay of processing a script which needs not be run is negligible), so if your scripts are short (you should of course minify them first), its best to alwaays bundle them. If you expect the average visitor to need all scripts eventually, it's again best to send them in one file. If, however, the average visitor won't need some of the larger scripts (for example one part is only needed at upload, and only 0,1% of the visitors ever uploads something), it might be better to send them separately.
The .js files are cached by your browser. So you can include as many functions as you like in a single file. If you split them into separate files that much of additional calls are made from the browser which slows down the loading page.. Also you can compress the js files if you are concerned about the size of the .js file ..# http://javascriptcompressor.com/
It depends a lot on how your server is sending out these files. If you have Firebug, open up the Net tab and inspect your JS files. If you see a Last-Modified entry in the Headers tab, it means that you are better off putting all your JS into one file. If you don't see it, it's best to split things up into page-specific files.
In my opinion, there are four main methods of speeding up your page-load times:
server headers -- this one is more complex to set up, but if you control your server settings or if you are willing to serve your JS via a dynamic page (PHP or ASP), you can send extra instructions to the browser to cache specific content for specific periods. Since your JS files are likely to change quite infrequently, it's usually pretty safe to do this for them. You basically just need to set the Expires header to some point well into the future. This means that the browser will not need to request the file at all if it has it in the cache. This makes the most sense if you have visitors who come back again and again. If you get a lot of one-hit visitors, this won't make a difference. This does mean that if you change these files, many browsers won't pick up the change; thus you should either change the file name or append something to the query string like this: <script type="text/javascript" src="/sitescript.js?v=1.1"></script>. This can be a maintenance problem if you have more than a few static HTML pages.
numbers of files -- in my opinion, this is where you get the biggest bang-for-buck savings. I'm nearly certain that most browsers still support only four active requests at a time. That means that if your web page has five images, the last image won't get requested until one of the previous images completes loading. And if your site has 50 images and 3 CSS files and 10 JS files, it's going to take a while to clear all those requests. Remember, even if you are sending Last-Modified headers, the browser still needs to check if the content has changed, so it needs one of those request slots. If you can combine all your images into a single images (using CSS sprites) and all your JS into a single file, your pages will load significantly faster.
file size -- as the web speeds up, this gets less and less important. If your server does not support content compression, it's a pretty good idea to minify your JS, though the time savings are overrated in my opinion. This does make maintenance somewhat more time-consuming and live debugging nearly impossible, but it definitely brings file size down quite a bit. If you have a LOT of JavaScript (maybe ~150KB+?) or if you know your visitors are coming from slower networks (for example, people on a corporate network), I would recommend doing it. If your server DOES support compression, the savings are actually negligible.
script placement -- when the browser hits a <script src="..."> tag, it halts all rendering until the script has loaded and executed, which means an inevitable delay. If you put your scripts in the middle of your page, you'll note that half the page loads and then pauses. To speek up rendering, place as many of your <script> references as you can at the dead bottom of the page. Scripts that you need at the top of the page can go there, but the more <script> clutter you have up there, the slower the page will render. Any code that gets executed by onLoad or DOMReady can safely go at the bottom of the page.
Yahoo has a really quite amazing list of optimization tips at their Best Practices page.
How could I prevent my page displaying an unstyled view while the page is loading ?
I think its probably because of the order of loading different JavaScript-files.
Is there a best-practice, for example loading plugins before my own code ?
Should every jQuery/.js-function called after document.ready or windows.load ?
link to page
Thanks
YSlow will give you some good ideas for starting points on this page. Quoting from running it on your www.cewas.org:
Grade D on Reduce the number of DOM elements. There are 1489 DOM elements on the page. A complex page means more bytes to download, and it also means slower DOM access in JavaScript. Reduce the number of DOM elements on the page to improve performance.
Grade E on Make fewer HTTP requests This page has 11 external Javascript scripts. Try combining them into one. This page has 5 external stylesheets. Try combining them into one. Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Some ways to reduce the number of components include: combine files, combine multiple scripts into one script, combine multiple CSS files into one style sheet, and use CSS Sprites and image maps.
Grade F on Compress components with gzip. There are 15 plain text components that should be sent compressed ... Compression reduces response times by reducing the size of the HTTP response. Gzip is the most popular and effective compression method currently available and generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip.
Grade F on Add Expires headers. There are 61 static components without a far-future expiration date.... Web pages are becoming increasingly complex with more scripts, style sheets, images, and Flash on them. A first-time visit to a page may require several HTTP requests to load all the components. By using Expires headers these components become cacheable, which avoids unnecessary HTTP requests on subsequent page views. Expires headers are most often associated with images, but they can and should be used on all page components including scripts, style sheets, and Flash.
To add my own 2 cents: you might want to hide all elements until the entire page loads. This seems to be what you intend with the progress bar, but the sheer number of elements and scripts/styles on your page seems to be preventing it. You could load the bare minimum subset of CSS/JS/HTML to set up the progress bar and then load the rest of the elements in some asynchronous Javascript, only showing the full page once they have all loaded (a la Gmail).
The main problem with your site is the fact that you are attempting to load everything in one go at initial page load. Web developer toolbar's document size report shows a total of 1.1mb of content - that would be nearly 750kb of images and 385kb of scripts. Loading this amount of content in one go is really not recommended, especially for slower connection speeds.
The obvious solution would be to hide everything and only display it when the scripts are ready, but this is a really bad solution - your visitors will be looking at upwards of 10 seconds or more of a blank page. What you should be doing is to restructure the site - rethink your architecture for this. Websites aren't meant to be downloaded in one go - there's too much data, and one of the reasons why users dislike Flash sites, because Flash has to download all of the assets in one go, and therefore users are forced to sit through long waiting times.
You should either breaking up the pages into normal HTML documents, which will load traditionally, or use ajax to load the contents sequentially. Have your script intelligently reorder the loading of contents - front page contents first, then as the user chooses where he's going, the site behind his back loads the assets for those pages. Images are the big problem here - you have .7mb of them, and loading all of them blocks the loading of the site, including scripts, by a very long amount of time.
These aren't easy task by any means, but this is the best method for rectifying the problem.
Some more immediate solutions to your problems include most of what #matt b said - enable gzip compression, combine all your scripts and stylesheets into a single file, etc. You should also consider using CSS sprites for your images to reduce the number of HTTP requests. There's a large number of jQuery plugins that are prime candidates for consolidation, and you're also loading jQuery twice - adding nearly 100kb to the amount of things you need to load.
I assume you are using an external stylesheet?
If you simply embed all your styles in the page, it will not show up unstyled.
Also, place the style sheet definition before any javascript code in the header.
It is commonly know as FOUC - Flash of unstyled content. The options in the answer above make eminent sense but it may still be impossible to eliminate in all circumstances. Initially it was and IE problem but has recently happened a lot more in Safari and is probably to with the underlying method used in the browser application itself and therefore may not be remediable.
Sometime addins such as jQuery and typekit can exacerbate the problem hence paying close attention to and testing different scenarios for loading them.