Боб Семович

...
.skill_block:hover {
    position: relative;
    opacity: 1;
    transform: scale(1.1); /*вот так*/
}
...

P.S. может не поддерживаться в некоторых браузерах, используите перфиксы.

Я сначала пытался объяснить, как устроен Opencart, чтобы вам было легко потом находить, какие шаблоны используются на конкретной странице, но получается, что это будет слишком объёмно. Поэтому я представлю ситуацию, когда используется стандартная установка Opencart.

Заголовочная часть HTML-кода, шапка страницы, плюс выпадающее меню категорий, плюс уведомления — <корень сайта>/catalog/view/theme/<название шаблона>/template/common/header.tpl

Футер — <корень сайта>/catalog/view/theme/<название шаблона>/template/common/footer.tpl

Контент — зависит от текущего пути. Например, если текущий путь — product/product (страница товара), то шаблон можно найти в <корень сайта>/catalog/view/theme/<название шаблона>/template/product/product.tpl. Если корневая страница сайта (вы её назвали index), то её шаблон лежит в <корень сайта>/catalog/view/theme/<название шаблона>/template/common/home.tpl.

Левая колонка — <корень сайта>/catalog/view/theme/<название шаблона>/template/common/column_left.tpl

Правая колонка — <корень сайта>/catalog/view/theme/<название шаблона>/template/common/column_right.tpl

Служебная часть перед контентом — <корень сайта>/catalog/view/theme/<название шаблона>/template/common/content_top.tpl

Служебная часть после контента — <корень сайта>/catalog/view/theme/<название шаблона>/template/common/content_bottom.tpl

<название шаблона> можно узнать на странице настройки магазина в админке: Админка → Меню «Система» → пункт «Настройки» → ссылка «Изменить» напротив текущей конфигурации → вкладка «Магазин» → пункт «Шаблон».

Всё содержимое обычно компонуется из этих кусков.

Правая и левая колонки, а так же служебные части перед и после контента обычно заполняются модулями — в зависимости от настроек модулей. Эти четыре шаблона лучше не трогать, если вы не уверены до конца, что делаете.

Точно также как когда ты первый раз открываешь тяжелый сайт он открывается за 10 секунд к примеру а потом уже за 1 секунду. Кэш

Плагины gulp в node_modules содержат огромное множество вложенных папок, содержащих много мелких файлов. Пока оно всё это хозяйство прочитает с диска - пройдёт много времени. А потом да, из дискового кэша.

Случайно взятый проект, использующий для сборки gulp:

Сейчас вы просто написали функцию, но нет никаких условий для её выполнения
Вам надо выбрать на какой элемент повесить событие, что бы при клике выполнялась ваша функция.
Например:
const btn1 = document.querySelector('.btn1');

Далее на эту кнопку надо повесить событие click и указать какая функция должна выполняться при этом событии:

btn1.addEventListener("click", myFunction);
Обратите внимание, что функция в при навешивании в обработчик пишется без ().

Добрый день.
Какие я вижу вашем слайде Лендинга проблемы.

1. Телефон как-то странно подчеркнуть линией. лучше добавьте с краю иконку. чтобы выделить номер телефона.
2. Кнопка сильно вытянутая текст в ней кажется очень маленьким. (тут нужно поиграть с кнопкой и текстом)
3. Расстояние между кроватью и текстом с точками довольно близкое.
4. Точки идут какой-то лесенкой это не очень хорошо, складывается мнение, что вы забыли выравнять их.
5. текст в карточке "подробнее" слишком близко примыкает к границам карточки как сверху так и снизу
6. Диван с левой стороны и правой сильно примыкает к границам карточки, нет воздуха.
7. меню сайта не видно, оно сильно примыкает кверху, плюс сливается с фоном заднего вида. Логотип, главная, о нас, каталог, контакты, тоже сильно к друг другу примыкают.
8. та же проблема что и везде, у текста "Почему именно мы" мало воздуха сверху страницы.
9. Смотря на ваш сайт создается ощущение, что вы все старались максимально близко к друг другу расположить.

Я сам тоже только учусь дизайну и многое не знаю. Но своими мыслями с вами поделился, надеюсь мой отзыв вам будет полезен.

Индусы со времён динозавров делают так:

<?php if (!isset($_SERVER['HTTP_USER_AGENT']) || stripos($_SERVER['HTTP_USER_AGENT'], 'Сюда прописать имя юзерагента google page speed') === false): ?>
// сюда код аналитики
<?php endif; ?>

увидели 100 из 100? Теперь удалите костыль и перестаньте заниматься тупыми замерами, раз гугл не посчитал нужным сообщить своему замерщику время кеширования своей же аналитики :)

Очищать не надо. Это нормальный процесс работы системы с оперативной памятью.
В линуксе такая модель работы с оперативной памятью. Чтобы память не простаивала страницы, которые были прочитаны помещаются в кеш. Это ускоряет операции повторного чтения. Когда память понадобится процессам этот кеш будет или вытеснен в swap или дропнут. В общем used\free не однозначные показатели и надо смотреть картину в целом.
Вот интересная статья на эту тему:
markelov.blogspot.ru/2009/01/linux-procmeminfo.html

Правильно ли я указал dns записи?

Вроде да.

Если ваш почтовый сервер отправляет почту с IP 1.2.3.4 и представляется как mail.domain1.com, то должны соблюдаться два условия

• A запись mail.domain1.com должна указывать на 1.2.3.4
  
• PTR запись для 1.2.3.4 должна указывать на mail.domain1.com
  

Т. е. всё (HELO сервера, FQDN и PTR) должно просто соответствовать друг-другу.

MX записи для всех этих доменов при этом не обязательно должны указывать именно на mail.domain1.com, но можно и так.

SPF лучше использовать SoftFail (~all). Например
v=spf1 a mx ~all
Про DKIM и DMARC тоже стоит почитать (они чуток посложнее SPF).

А-запись -- отображение доменного имени в IP адрес.
MX(Mail eXchange)-запись -- имя почтового сервера(ов) для домена.
CNAME-запись -- отображение доменного имени в другое доменное имя.
PTR-запись -- отображение IP адреса в доменное имя.
Использование ссылки на CNAME в качестве имени почтового сервера считается недопустимым (RFC2181).

При доставке почты МТА используют MX и A записи для домена, вторую -- если нет первой.

Допустим у вас есть сервер с IP адресом 1.2.3.4 и он предоставляет некоторые сервисы, к которым вы желаете обращаться по символьному имени myserver.com.
Для этого вы вносите в ДНС А-запись вида
myserver.com. A 1.2.3.4

Если вы собираетесь принимать почту для этого домена на том же сервере, то вам, в принципе, ничего более для этого не надо, поднимаете почтовый сервер (MTA) и наслаждаетесь жизнью.
Однако, если вы собираетесь ещё и отправлять почту, то начинаются подводные камни.
Серверы-получатели отправляемой вами почты могут захотеть, чтобы присутствовала PTR-запись для вашего IP адреса 1.2.3.4, отображаемая в то же имя. В случае если у вас один домен, один сервер и провайдер не возражает, то прописываете PTR (так называемую обратную зону) и наслаждаетесь жизнью:
1.2.3.4 PTR myserver.com.

Если хостинг-провайдер не идёт на сотрудничество (что редко), либо у вас на одном сервере обслуживаются более одного домена, либо это планируется, то жизнь перестаёт быть такой простой и незатейливой. В этом случае и выходит на сцену схема с MX записями.
Исходная ситуация та же: у вас есть сервер с IP 2.3.4.5, обслуживающий домен myservice.org (его веб-сервер, например) и отрправляющий/принимающий для него почту. А-запись:
myservice.org. IN A 2.3.4.5
Теперь мы создаём ещё одну А-запись, имя не принципиально, но лучше выбрать говорящее, типа mail или mx:

mail.myservice.org.  A 2.3.4.5
или
mx.myservice.org. A 2.3.4.5

То есть, фактически, ваш сервер получает второе имя, которое ссылается всё равно на тот же IP адрес.
Теперь это новое имя вы делает почтовым сервером для вашего домена внесением ещё одной записи:
myservice.org. MX 10 mail.myservice.org.
Число после "MX" -- это приоритет данного сервера на случай, если их несколько, чем меньше число, тем приоритетнее сервер.
После этого действия почта должна начать ходить (при условии правильной настройки вами MTA на вашем сервере).
почти всегда, за исключением особо привередливых борцов со спамом.

Там же есть кеширование. Напрягает конечно, но не сильно. Если вы не конвертируете 4k изображения.