Не буду вдаватися в тонкощі оптимізації, лише дам пораду по швидкому приведенню в порядок.
Дехто досі сидить на непідтримуваної Evo через те, що вона працює трохи швидше. Я ж рекомендую завжди використовувати останню версію програмного забезпечення. Тому розбираємо на прикладі MODx Revolution.
Що означає:
[^ T ^] - час, витрачений на генерування сторінки
[^ Q ^] - кількість запитів до бази даних
[^ Qt ^] - час, витрачений на запити до бази даних
Гугл уважно стежить за швидкістю завантаження сайту.
На одному з проектів красувалися безрадісні "цифри":
Особливо вразило значення 62, що означає кількість запитів до бази даних. Навіть в особливо складних випадках їх повинно бути як мінімум втричі менше.
Ну, власне, почнемо оптимізацію.
2. Прибираємо по максимуму все некешіруемие чанкі.
З конструкцій виду [[! Chunk]] потрібно прибрати знаки оклику. Ми залишаємо: сніпети форм, реєстрації та getPages.
Ефект зростання продуктивності особливо помітний при включенні кешування головного і додаткових меню.
3. Налаштовуємо мінімальну вкладеність чанкі і сніпетів.
висновок
повинен виводитися в шаблоні, а не в чанка head.
Те ж саме робимо з тегами, які задаються в плейсхолдерах, наприклад description і keywords.
4. Зайві чанкі і сніппети не потрібні.
Кожен додатковий виклик уповільнює роботу MODx.
Проробивши вищевказані маніпуляції, дивимося на нашу статистику в вихідному коді:
Відмінний результат! Запитів до б / д після генерації кеша всього 1-2, швидкість генерації зросла в 5 разів. Кількість запитів зменшено на 60! Тепер сайт спритно вантажиться і не викликає зайвого очікування.
Чистий MODx - максимальна продуктивність.
Отже ми прискорили свій MODx Revo. У вас може виникнути питання: чи є до чого прагнути? - Звичайно, адже чистий MODx без шаблонів на локальному сервері завантажується за 15 мс. Власне це і є максимальна швидкість.
Хочеться відзначити, що в більшості випадків після оптимізації движка необхідно скинути вагу самої сторінки, але це вже тема, гідна окремого поста.
UPDATE: крім виведення загального часу завантаження можна використовувати плагін debugParser. який дозволяє побачити швидкість завантаження кожного виклику без їх почергового відключення.