In the Create React App documentation inside the Adding Images, Fonts, and Files section, they say :
importing images that
are less than 10,000 bytes returns a data URI instead of a path. This
applies to the following file extensions: bmp, gif, jpg, jpeg, and
png.
The reason for them is :
To reduce the number of requests to the server
But is it specific to how React works (updating the DOM for example) or it's a wide spread practice in web development in order to reduce load times?
This is not a practice that's particular to React. Whether something gets rendered via React or by ordinary HTML, if an image is rendered using a data URI, if the data URI exists in the code already (either bundled inside the JS or hard-coded into the HTML), no additional requests to the server will have to be made.
In contrast, if you have something like src="theImage.png", that'll result in a request to the server to download the image.
it's a wide spread practice in web development in order to reduce load times?
Yes.
If, for example, the web server was using HTTP 1.1, and you had, say, 25 images with srcs pointing to different files, the sheer number of separate requests could present a problem - regardless of whether React was being used or not.
(HTTP/2 mitigates this problem at least somewhat - see here)
Related
Situation:
React code generates a base UI
It has to use data from a JSON file (generated by another script that I can manage) to load different UI elements like text boxes and dropdowns dynamically
Options I've considered:
Place it in src/ folder and import it (e.g., import data from '../data.json';)
Place it in public/ folder
I've seen Using the Public folder (CRA Docs) and couldn't find this scenario in the use cases mentioned
Load it dynamically via an XHR request (from backend API)
Right now, the UI functions independently. I'll have to create a backend API server exclusively for serving this JSON file.
Is there any other option that is useful here?
Other points that may be relevant:
Although it's static, there may be changes to the JSON file from time to time (say, every week or month)
The size may increase gradually in the future, but not by a huge margin (say, to 100 MB or so - it'll still be around 10-20 MB)
I'm using CRA and npm run build to create the build. I have never configured webpack manually before. I don't know much about it.
The size is actually 7 MB now. Minified size is 1.9 MB.
I ran into a problem that I have never faced before developing a PWA with translations.
I state that I have always and only developed multilingual applications in Vue, React, Angular, and at the moment I am using Svelte.
I have always used simple practices, translation with a json dictionary and sending the Lang variable to the server for data acquisition in the requested language (set in the Headers).
All of this was fine until I encountered the need to receive the translated meta tags for the requested content immediately, during SSR, upon landing on the page. But as you know, at this stage there is no access to localStorage or similar, which is why it is impossible for me to acquire the meta tags in the requested language, since I do not have access to the variable set in the browser. How do you act in this case? I'm not interested in finding a specific solution for a certain framework, but a possible technique.
For Svelte I found this half solution, which allows me to obtain the slug / lang / from the address and use it in the server during the rendering phase, in order to obtain the data already translated on the server side.
Can I consider this a good solution?
I don't know what are you returning from the API, but if you have localized user defined content on backend, then this solution is good. If you are translating the app itself, you maybe you can give Tolgee a try, which supports SSR. https://tolgee.io/integrations/svelte
Is it generally better performing to use an image by referencing it with an url or by downloading it, saving it to some directory, and then importing it in a component?
Eg
<img src="images.google.com/example.png" />
vs
import Example from './static/example.png';
<img src={Example} />
Since React doesn't have any means of loading or serving image data, this question is inherently about other tooling, like Webpack.
Storing images locally and loading them via webpack has the benefit of being able to process them with your Webpack loaders, which enables things like inlining them (via base64 resource URLs) when they're small enough and fingerprinting them. You'll still want to deploy those final assets somewhere that gets wrapped in a CDN, though.
Referencing remote images via string URL alone has the advantage of not having sizeable binary images bloating your SCM repository, not needing to import each image explicitly (remember, there are no glob imports in Webpack), and reducing your webpack build times.
I suspect most React apps are going to end up using both, usually in different use cases. I always use local images for logos and app assets for example, whereas I'll reference external files for any user-uploaded content or larger JPG/PNG assets.
CDNs are usually preferred for delivering static files such as images. Due to the fact that the Google Cloud CDN caches your files through its edge servers, your visitors will have their static content delivered to them from the closest point of presence instead of originating from the same server your application is running from.
Having your static content served and cached in multiple geographical locations around the world ensures an optimal content delivery time.
Developing locally however, you may notice that having your static content locally is faster. This is normal, because you're fetching an image over the internet vs from your local hard drive. However, once your app will be deployed and running (say from Canada), visitor A who is from Eastern Europe may be experiencing slower delivery times than visitor B who is from the States. Because you are serving a global customer base from one geographical location, your visitors from the a completely different timezone will receive an unfair treatment in the time it takes for their content to be delivered.
In another perspective, why not both? Have your application serve static content from a CDN but also have your static content on the same application folder and gracefully fall to the local one if the CDN fails.
TL;DR
Serve your images from a CDN ( url ) if you have a large customer base for optimization.
I'm making a React app that needs a pretty big (about 1 or 2 MB) json file and I'm trying to figure out how to include the data in a way that will minimize loading time for the user. I'm pretty new at webpack but so far I see two options:
Add the data to the React source and import it into the jsx
Put the json in the static file directory and fetch it within the jsx
One other constraint is that multiple pages will be loading the same data, so I was thinking that maybe fetching would be better since the user would have the json cached after the first load.
I'm still pretty new to this and I might be missing something big so I appreciate any info you could give.
Importing a JSON file at build time to bundle it with your code is certainly possible. However I would say keep the JSON as a separate file and fetch it with AJAX. A few reasons why:
With caching, if you bundle it with your JS file, any time you make an incremental change to your code you need to re-bundle your code and JSON, causing your users to unnecessarily re-download a 1-2 MB file just to get the code updates even if the JSON part hasn't changed. If the files are separate, the browser can cache each independently and only re-download when there's a change.
What if users don't need the JSON? Is it 100% necessary in every use-case? Keeping the JSON separate means you can load it only at the actual time it's needed for use instead of preemptively.
You mentioned needing the JSON on multiple pages - if it is cached, theoretically they will download it only once even if it's needed across multiple pages.
You may want to read up on how to leverage caching so that your server provides the proper headers for browsers to effectively utilize caching.
I am using a Hosted CMS which does not allow server side access. And unless I am mistaken CSS3 Pie requires server side code to work properly. (.htaccess)
Is there a way to use CSS3 Pie (or another similar type of service) without server side access?
There are three ways:
add the mime type using .htaccess
Use the supplied PHP file to add the mimetype
Use pie-js: http://css3pie.com/documentation/pie-js/
As mentioned on their page:
Advantages of the JS version
Since it is a normal .js file, PIE.js does not suffer from some of the
more annoying limitations of the PIE.htc behavior:
You can load PIE.js from a different domain than the HTML page. You
don't have to worry about your server not using the correct
Content-type header for the file. Referencing the PIE.js file via a
relative path is simpler since you only have to do it once in each
HTML page. It is more easily integrated within JavaScript libraries.
Disadvantages of the JS version
Unfortunately there are some significant drawbacks to using PIE.js,
which is why the .htc behavior is still the recommended approach for
most users:
Invoking it requires writing some JavaScript, which means your styling
is scattered between CSS and JS code. The .js file blocks the parsing
of the page while it is loading, whereas the .htc file loads
asynchronously. You have to wait until the page's DOM has completely
loaded before applying PIE.js to elements, whereas the .htc behavior
applies itself while the page is still loading. This means the "flash
of unstyled content" problem is much greater with PIE.js. PIE.js
cannot automatically attach and detach itself from elements which are
dynamically added to/removed from the page's DOM, so you have to write
code to handle that yourself.