(0); const refAsync = useRef(0); useLayoutEffect(() => { refSync[CURRENT]++; }); useEffect(() => { refAsync[CURRENT]++; }); console.log(refSync[CURRENT], refAsync[CURRENT]); return { syncCount: refSync[CURRENT], asyncCount: refAsync[CURRENT], };};Minified code (234 bytes)import {useRef as e, useLayoutEffect as r, useEffect as t} from "react";const n = "current", o = () => { let o = e(0), u = e(0); return r(() => { o[n]++ }), t(() => { u[n]++ }), console.log(o[n], u[n]), {syncCount: o[n], asyncCount: u[n]}};export {o as useRenderCounter};The more times current is used, the more effective this optimization will be.Source code:Minified code (234 bytes)The more times current is used, the more effective this optimization will be.Using ES6 syntax in conjunction with a minifier can be a good way to shorten your code.In terms of compressibility, arrow functions are better than classical ones in everything. For two reasons. Firstly, when declaring arrow functions in a row via const or let, all subsequent const or let except the first one are shortened. Secondly, arrow functions can return values without using the return keyword. Example before optimization Source code:export function fun1() { return 1;}export function fun2() { console.log(2);}export function fun3() { console.log(3); return 3;}Minified code (126 bytes)function n() { return 1}function o() { console.log(2)}function t() { return console.log(3), 3}export {n as fun1, o as fun2, t as fun3};Source code:Minified code (126 bytes) Example after optimization Source code:export const fun1 = () => 1;export const fun2 = () => { console.log(2);};export const fun3 = () => { console.log(3); return 3;}Minified code (101 bytes)const o = () => 1, l = () => { console.log(2)}, c = () => (console.log(3), 3);export {o as fun1, l as fun2, c as fun3};Source code:Minified code (101 bytes)This is a specific case of the general rule described in the first part. There weren't such thing as spread operator in objects in ES6. Therefore, if you are compiling your library under ES6, I would recommend that you use Object.assign instead of this operator. Example before optimization Source code:export const fun = (a: Record, b = 1) => { return { ...a, b };};Minified code (76 bytes)const s = (s, t = 1) => Object.assign(Object.assign({}, s), {b: t});export {s as fun};As you see, Object.assign may apply twice.Source code:Minified code (76 bytes)As you see, Object.assign may apply twice. Example after optimization Source code:export const fun = (a: Record, b = 1) => { return Object.assign({}, a, { b });};Minified code (61 bytes)const s = (s, t = 1) => Object.assign({}, s, {b: t});export {s as fun};Source code:Minified code (61 bytes)Another optimization from the "extreme" category. If this does not affect the functional component, you can return the value from the function. The savings will be small, but they will be. It works, however, in cases when there is only 1 expression in the function. Example before optimization Source code:document.body.addEventListener('click', () => { console.log('click');});Minified code (68 bytes)document.body.addEventListener("click",()=>{console.log("click")});Source code:Minified code (68 bytes) Example after optimization Source code:document.body.addEventListener('click', () => { return console.log('click');});Minified code (66 bytes)document.body.addEventListener("click",()=>console.log("click"));Source code:Minified code (66 bytes)Another optimization from the category of "extreme". In general, trying to reduce the number of variables is a normal idea for optimization - the minifier gets rid of them if it can do inline code insertion. However, the minifier cannot get rid of all variables independently for the same security reasons. But you can help him.Look at the compiled file of your library. If it has functions in the body of which there are some variables, then you can use the function argument in your code instead of creating a variable. Example before optimization Source code:export const fun = (a: number, b: number) => { const c = a + b; console.log(c); return c;};Minified code (71 bytes)const o=(o,n)=>{const t=o+n;return console.log(t),t};export{o as fun};Source code:Minified code (71 bytes) Example after optimization Source code:export const fun = (a: number, b: number, c = a + b) => { console.log(c); return c;};Minified code (58 bytes)const o = (o, c, e = o + c) => (console.log(e), e);export {o as fun};Source code:Minified code (58 bytes)This is a pretty strong optimization, because in the end it can help get rid not only of const, but also of return keywords in the assembled file. But keep in mind that such optimization should be applied only on private class methods and on functions that are not exported from your library, because you should not complicate the understanding of your library's API with your optimization.Again, the "extreme" advice. In the assembled code, in principle, there should be a minimum number of uses of let and const. And for this, for example, all constants can be declared in one place one after another. At the same time, the advice becomes extreme only if we try to declare literally all constants in one place. Example before optimization Source code:export const a = 'A';export class Class {}export const b = 'B';Minified code (67 bytes)const s = "A";class c {}const o = "B";export {c as Class, s as a, o as b};Source code:Minified code (67 bytes) Example after optimization Source code:export const a = 'A';export const b = 'B';export class Class {}Minified code (61 bytes)const s = "A", c = "B";class o {}export {o as Class, s as a, c as b};Source code:Minified code (61 bytes)In fact, you can come up with a lot of tips. Therefore, summarizing, I decided to simply describe how the assembled minified file should look like. And, accordingly, if your output file does not match the specified description, it has a lot to squeeze.There should be no repetitions. Repetitive functionality can be allocated to functions, frequently used object fields need to be written to constants, etc.The amount of non-abbreviated code should be kept to a minimum. This includes the frequently repeated use of this, the use of nested objects or methods, etc. It is highly desirable that the minimized file contains exclusively single-letter expressions.The number of function, return, const, let and other keywords should also be kept to a minimum. Use arrow functions declared via const, declare constants in a row, use arguments instead of declaring a constant in functions, etc.And the most important thing. It makes sense to resort to extreme reduction only when all other optimizations have already been applied and only if it does not affect the functionality of your package. And also, once again, optimization should not affect the API (and, therefore, typing).It might seem to you that there is no point in extreme compression, because in my examples I got a maximum gain of a couple dozen bytes. But in fact, I specifically made them minimally representative. In real conditions, the gain can be much greater.But in the end, whether or not to resort to the use of “extreme” advice is up to you. For me, it was more of a challenge to myself about whether I could achieve the minimum possible file size. But in case you are still wondering how useful they are, I can say that they helped me reduce the size of my library from 2172 bytes to 1594. That on the one hand only 578 bytes, but on the other as much as 27% of the total packet volume.Thank you for your attention, you can share your opinion in the comments. I hope my article was useful for you - if not extreme advice, then at least general. It is likely that I did not specify something in my article. In this case, I will be happy to supplement it according to your suggestions.Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse mankaa - Jul 8 JS - Jul 26 LEANDRO - Jul 26 k.goto - Jul 3 Once suspended, yoskutik will not be able to comment or publish posts until their suspension is removed. Once unsuspended, yoskutik will be able to comment and publish posts again. Once unpublished, all posts by yoskutik will become hidden and only accessible to themselves. If yoskutik is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Alexandrovich Dmitriy. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag yoskutik: yoskutik consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging yoskutik will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.