D
D
Daniil Kochkin2019-10-20 16:22:11
code review
Daniil Kochkin, 2019-10-20 16:22:11

[Code Review]. Who can check, evaluate the code and tell about the mistakes made, where it is worth changing, in the future not to allow?

Hello! I started doing layout two months or so ago. For the most part, I watched a video, read something, or asked questions here when I could not do / understand something on my own. Sometimes I tried to repeat after the authors on YouTube. Nevertheless, it didn’t work out for a long time, I wanted to write the code myself.
Now he began to practice and typeset using layouts. I guess I'll move on to learning more and learn the WordPress CMS, as well as JavaScript to spice up the pages.
The problem is that before that I would like to make at least four layouts in order to make sure that I learned the information.
At present, I have made up the first two layouts and decided to ask to see the code and say where and what mistakes were made, so that they would not become boring and would not be allowed in the future. Thanks in advance to those who respond.
First laid out site - https://deokti.github.io/GRANIT/
( Its structure )

Answer the question

In order to leave comments, you need to log in

1 answer(s)
K
Konstantin, 2019-10-20
@KaizDA

Let's try to evaluate your first site and write that I would recommend doing it in addition to what is:
1. Reduce the page size. At the moment, at the first download, it weighs 1.4 MB, which is a lot. Especially if you go from the mobile Internet. Literally, if you reduce the weight of two pictures, you can save a lot on page size. An excellent resource for reducing the size of pictures . The first BG picture can be reduced from 500kb to 100kb, the map picture can be reduced from 360kb to 50kb. If you go straight ahead, you can even think about using the WebP format, or try to fasten the lazyload.
2. Take for example a block with the class .nav-bg. There are a lot of media queries applied that change its width. It's redundant. It's easier to make this block stretch to the width of its parent ( width: 100% ) and you wouldn't have to redefine the width of this container every 50-200px. This will speed up development and simplify support in the future.
You can immediately tell about the block with the .container class , which has exactly the same trouble with media queries. Its width changes a lot and very often, although in fact it can be set once and not redefined again (at least within the current site). I’ll also say right away that it’s not very correct to set the width rigidly (clearly indicate percentages). It's better to do it as a percentage. I.e:

.contatiner {
  max-width: 980px;
  margin: 0 auto;
}

.nav-bg {
  width: 100%; // в таком случае ваше меню всегда будет равно ширине контейнера и не надо будет париться
}

3. Fonts. Fonts of the woff format are loaded on the site, you can also add the woff2 format. They will weigh a little less, which will slightly increase page loading speed. You also have formats that you can generally discard: *.eot - an old format that is supported by old IE versions, which you, frankly, support in the current case; ttf is also a heavyweight font that is comparable to woff in terms of support. Therefore, it makes no sense to evaluate it. In general, these two fonts do not affect the work of the site as a whole, but they can simply make the project cleaner by their absence from it, which is already nice. You can also pay attention to the font-display property for @font-face .
4. Returning to the pictures. In this case, product pictures should not be used in PNG format either. It is heavier and you have no transparency, which means there is no point in using them. Use better JPG.
5. Sometimes it makes more sense to use the tag rather than just . 6. Button "Callback". By default, it has the type="submit" attribute, which means submitting the form. Although in this case there is no form, it is still better to give it the type="button" attribute. 7. Working with autoprefexer. I recommend that you familiarize yourself with how to tell the autoprefector which browsers to prefix. For example, you have a lot of flex prefixes that you don't exactly need. Accordingly, if you get rid of them, then the css file (s) will weigh less.<p><div>
8. I think if you just look superficially, then that's all. All of the above, in addition to a quick fix, can be worthy of a more detailed study. Since fonts and pictures and adaptive, and other aspects, can be very flexibly manipulated depending on the situation, so if possible, you can study these topics.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question