Website loading speed optimization

Доброго дня, Анно!
Покажіть сам сайт, будь-ласка.

Мені також..

Рекомендую переписати сам сайт, без використанння конструктора

А зачем? Может проще настроить оптимизацию? Если переписывать и потом оптимизировать - больше надо денег отдать. И главное - потом не будет возможности обновить шаблон.

Алексей, налаштування оптимізації, безумовно, може допомогти, але в цьому випадку це лише тимчасове рішення. Проблема тут у використанні плагіна WPBakery Page Builder, який додає багато зайвого коду та уповільнює завантаження сайту. Навіть після оптимізації швидкість залишатиметься обмеженою через низьку продуктивність конструктора.

Переписавши сайт без використання конструктора, ми отримаємо чистий код, що значно зменшить час завантаження (до 1-2 сек) і зробить сайт більш стабільним. А шаблони можна оновлювати вручну — це займе більше часу, але якість та швидкість сайту варті цих зусиль.

Оптимізація не завжди може вирішити всі проблеми, особливо коли конструкція сайту побудована на повільних інструментах

Роман, это не временное решение. Правильное решение, Плагины работают.  Просто их надо с головой применять. 

Я не раз встречался с переписываем программистами шаблонами. Потом сайт нельзя обновить без его участия. Я бы сказал так - заказчик сел на иглу. И кстати не всегда переписываю шаблон адекватно. Крайний раз  LiteSpeed не смог включится, а WP Rocket закешировал 80 файлов из 168))) 

А оптимизация -экономия времени, нервов, денег для клиента.

Алексей, повністю погоджуюсь, що оптимізація зменшує витрати часу та грошей на початковому етапі. Але якщо ми говоримо про довгострокову перспективу, то конструкції на плагінах часто стають вузьким місцем для продуктивності.

Щодо переписування шаблонів — тут головне робити все правильно, дотримуючись стандартів. Якщо використовувати чайлд-тему, то навіть оновлення базового шаблону не становитиме проблем. А ось з плагінами, як WPBakery, будь-яка зміна чи додатковий функціонал може значно уповільнити сайт, особливо з великою кількістю сторінок.

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

Для мене якість і швидкість сайту — це пріоритет. Тому я б не взяв проект на конструкторі в роботу. І тут вже замовник вирішує: отримати швидкий результат зараз чи інвестувати в стабільний і швидкий сайт на майбутнє.

Насчет кода Вы меня не убедили. Если шаблон куплен 400 тыс раз, как Вы думаете какой будет код? И обновляются они 5-6 раз в год.

Все равно надо будет плагин кэширования и несколько других)) И они решет все.

Вопрос - какой должен быть вес страницы, количество запросов к ней и количество плагинов на сайте?

Алексей, дякую за ваші аргументи. Шаблони, які продаються в великій кількості, дійсно можуть мати якісний код. Але це не завжди гарантія того, що цей код оптимізований саме для конкретних потреб замовника чи проекту.

Навіть якщо шаблон оновлюється кілька разів на рік, його основна структура залишається універсальною, що часто включає купу зайвого коду й функціоналу, який просто не використовується. Це збільшує вагу сторінок і кількість запитів до сервера.

Щодо плагінів — згоден, що вони потрібні. Але важливо мінімізувати їх кількість і використовувати тільки ті, які не конфліктують між собою і не створюють додаткового навантаження. Кешування — це завжди гарна ідея, але воно лише згладжує проблему, а не вирішує її повністю.

Щодо вашого питання:

Вага сторінки: Ідеально до 1-1,5 МБ, враховуючи зображення та файли CSS/JS.

Кількість запитів: До 50-60 для стандартної сторінки.

Кількість плагінів: Мінімально необхідна, але краще не більше 10-12.

Основне завдання — досягти високої швидкості та стабільності сайту. Іноді це простіше зробити, якщо все написано з нуля, ніж оптимізувати чужу універсальну конструкцію, яка робилася "для всіх". Але остаточний вибір завжди за замовником.

Вы супер разбираетесь в вопросе.

В документации встречал

Вес 2-3 МБ

Запросы до 100

Количество до 20-25 -(для Woocommerce другим количеством не обойтись)

Кроме того, постоянно закрываются дыры безопасности и нет проблем с обновлениями ядра, плагинов

На продажниках можно почитать как решить вопросы по шаблону, плагинам.

Дякую за вашу точку зору та наведені параметри. Ви абсолютно праві, що для WooCommerce кількість плагінів може бути трохи вищою через його специфіку. Але навіть у цьому випадку важливо ретельно підбирати плагіни, оскільки зайві або неправильно налаштовані плагіни можуть значно знижувати продуктивність сайту.

Щодо ваги сторінки: 2-3 МБ — це допустимий показник, але чим менше, тим краще. Завантаження великих зображень, надмірна кількість скриптів або сторонніх ресурсів можуть уповільнювати сайт, тому оптимізація залишається ключовим моментом.

Запити до 100 — також прийнятно, але їх можна скоротити за допомогою правильного підходу. Наприклад, об’єднання CSS і JS-файлів, оптимізація зображень, lazy-load та використання CDN допоможуть зменшити навантаження.

Щодо плагінів: так, багато з них потрібні для функціональності, але частину їхніх задач можна вирішити без додаткових модулів. Наприклад:

• Інтеграцію Google Analytics можна реалізувати простим додаванням коду у файл теми.
• Налаштування мета-тегів можна виконати без плагінів, якщо це невеликий проект.
• Те ж саме стосується кешування — у деяких випадках простий PHP-код працює не гірше.

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

Щодо безпеки та оновлень — так, закриття "дірок" у популярних плагінах є вагомим аргументом. Але варто пам’ятати, що власноруч написаний код (за умови, що він виконаний професійно) має значно менше точок для потенційного злому.

Зрештою, універсальність шаблонів та плагінів — це добре, але якщо мова йде про швидкість і оптимізацію, часто кращим рішенням є кастомний підхід. Але, звісно, остаточне рішення залежить від цілей і бюджету замовника.

Наприклад, об’єднання CSS і JS-файлів, оптимізація зображень, lazy-load  - это и делает плагин кэширования.

CDN только для международных сайтов.

У меня был заказчик у которого картинки из США в Украину прилетали (трассер показывал)😁

Алексей, ви праві, що плагіни для кешування можуть автоматично вирішувати багато завдань, зокрема об’єднання файлів та lazy-load. Але варто зазначити, що якщо б сайт був розроблений без конструктора і код був би написаний вручну, то всі ці процеси можна було б налаштувати за допомогою препроцесорів (наприклад, SASS/SCSS для CSS) і зборок (через такі інструменти, як Webpack чи Gulp).

Такий підхід дозволяє контролювати процеси об’єднання, мінімізації файлів без необхідності в плагінах. Тобто, в результаті ми отримуємо чистий і оптимізований код без зайвих додаткових плагінів, що позитивно впливає на продуктивність та скорочує час завантаження сайту.

Не аргумент. Ті, хто купує шаблон не завжди є професійними програмістами чи бодай взагалі програмістом. Той, хто замовляє сайт в основному дивитися на зовнішній дизайн сторінок, кольори, шрифти то що

Не аргумент. Ті, хто купує шаблон не завжди є професійними програмістами чи бодай взагалі програмістом.

Как раз они и рассчитаны на дилетантов)))

Той, хто замовляє сайт в основному дивитися на зовнішній дизайн сторінок, кольори, шрифти то що

Из коробки можно сделать все что хочешь дизайнером.

Можно сайт глянуть?