Втрати часу на проектування
З інформацією по цьому пункту можна ознайомитися тут:
- Стерлінг Хьюз "21 помилка програміста PHP" (Sterling Hughes "Top 21 PHP Programming Mistakes")
https://freehost.com.ua/faq/articles/21 … t-pervaja/
https://freehost.com.ua/faq/articles/21 … t-vtoraja/
https://freehost.com.ua/faq/articles/21 … st-tretja/

Втрати часу на процедурах
PHP відноситься до розвинених мов програмування з довгим списком можливостей. Тому отримати необхідний кінцевий результат можна декількома шляхами. При цьому процедура кожного рішення повинна пройти обов'язкову перевірку на час виконання і можливі уразливості. Час виконання будь-якої процедури можна визначити за допомогою типового скрипта:

<?php
$start = microtime(true); 
// Ваша процедура
...
echo 'Час виконання процедури: '.(microtime(true) - $start).' с';
?>

Вибрати слід процедуру з мінімальним часом виконання.
Наприклад, LinkorCMS має вбудований скрипт для контролю необхідних динамічних параметрів прямо на хостингу:
Пам'ять:
- використано 2.25 М;
- доступно 256 M.
Час:
- генерації сторінки 0.05312 с;
- затримки шаблонизатора 0.01560 с;
- ініціалізації ядра 0.02031 с;
- 12 запитів до БД за 0.04690 с.
Завантаження:
- PHP 91 %;
- БД 9 %.

Втрати часу на трафіку
Занадто часто розробники CMS з егоїстичних мотивів вставляють невалідні коди і неприпустимі символи в HTML шаблони динамічних і статичних сторінок сайту. В результаті користувач матиме додаткові втрати корисного трафіку, а будь-якій валідатор HTML видасть йому повідомлення типу:

<!-- Валідатор: Невалідні коди в "head" -->
<!-- Валідатор: Неприпустимі символи в "body" -->

Тому необхідно напам'ять знати і обов'язково виконувати усі вимоги розробників HTML:
- HTML5
A vocabulary and associated APIs for HTML and XHTML
W3C Recommendation 28 October 2014
http://www.w3.org/TR/2014/REC-html5-201 … adata.html

Втрати часу на адміністрування
Ось декілька прописних істин адміністрування будь-якої CMS.
1. Чим менше тривалість підключення комп'ютера до адмінпанелі CMS, тим нижче вірогідність її злому через комп'ютер.
2. Вкладеність меню адмінпанелі не повинна перевищувати 3 рівні переходів.
3. CMS повинна забезпечити максимальну швидкість заповнення форм адміном:
- нижчій кваліфікації - більше 60 знаків в хвилину (1 знак в секунду);
- середній кваліфікації - більше 120 знаків в хвилину (2 знаки в секунду);
- вищій кваліфікації - більше 240 знаків в хвилину (4 знаки в секунду).
Зупинимося на цьому пункті детальніше.
Для заповнення дати у форматі ISO (ДСТУ ISO 8601:2010. Елементи даних і формати обміну. Обмін інформацією. Подання дати й часу)
РРРР-ММ-ДД
адміну вищій кваліфікації при наборі на клавіатурі знадобиться 2 с (8 знаків цифр і 2 знаки табуляції). Запам'ятаємо це значення часу.
Наприклад, у Вашій CMS для набору дати "День Народження" передбачені випадні чекбокси: день, місяць і рік. Результати досліджень показали, що швидкість реакції (біологічний пинг) адміна при роботі на комп'ютері по дисплею, а не по пам'яті як при наборі тексту, визначається за наступною схемою:
1) адмін побачив зображення випадного чекбокса;
2) адмін розпізнав зображення і прийняв рішення на вибір;
3) адмін дав команду м'язам руки натиснути кнопку.
І так 3 рази по кожному випадному чекбоксу. Швидкість реакції (біологічного пинга) по кожному пункту наведеної вище схеми у адміна:
- нижчій кваліфікації - до 1,6 с;
- середній кваліфікації - до 1 с;
- вищій кваліфікації - до 0,6 с.
Адмін вищій кваліфікації на заповнення одного випадного чекбокса витратить до
0,6 з * 3 = 1,5 с
Отже, админу вищої кваліфікації на заповнення трьох випадних чекбоксів знадобиться
1,5 з * 3 = 4,5 с
Порівняйте швидкості заповнення дати:
- при наборі з клавіатури - 2 с;
- при заповненні випадних чекбоксов - 4,5 с.
При наборі з клавіатури швидкість роботи адміна вище приблизно в 2 рази!

Втрати часу на редагування
Істотний недолік процесу редагування в CMS - це завантаження відразу усього тексту статті з додатковими кодами розділення (паженації) сторінок. Давайте змоделюємо найгірший варіант цього процесу. Уявимо собі наступні початкові умови:
1) безкоштовний занепалий хостинг із загальним об'ємом виділеної оперативної пам'яті не більше 8 Мб і жорсткими лімітами місячного трафіку;
2) стаття користувача у вигляді дисертації або монографії об'ємом більше 300 сторінок з великою кількістю зовнішніх веблинків і наочних матеріалів.
Після кожної вставки або правки абзацу тексту з його обов'язковим збереженням, а досвідчені користувачі поступають саме так, увесь об'єм статті постійно регенеруватиметься в редакторі. На це потрібно додаткові об'єми часу і ліміти трафіку. У зайнятих користувачів майже завжди бракує часу, а на безкоштовному занепалому хостингу майже завжди встановлені ліміти трафіку. Єдиний вихід з ситуації - це посторінкове редагування і зберігання статей у БД або у файлах. При цьому автоматично відпаде необхідність обробки додаткових кодів розділення (паженації) сторінок.
Хорошою альтернативою цій пропозиції також може стати завантаження об'ємних статей у форматі PDF і їх посторінкове читання за допомогою переглядачів типу ViewerJS або PDFJS.

Втрати часу на багатомовність
У роботі з багатомовними CMS типу Opencart або Wordpress зазвичай є присутніми наступні операції введення тексту:
1) вибір вікна відповідної мови;
2) вставка тексту відповідною мовою.
А в роботі з багатомовними CMS типу Serendipity є присутньою лише одна операція: вставка тексту відразу усіма мовами. Застосування мовних кодів (тегів) економить час користувача, а також кількість додаткових сайтів і таблиць для них.

Втрати часу на заповнення каталогів і таблиць
Досвід роботи з Opencart підказує: необхідно обов'язково автоматизувати процес заповнення каталогів і таблиць. Вводити вручну сотні позицій - це марна витрата часу і трафіку. Тому необхідно передбачити можливість автоматичного введення даних із заздалегідь відредагованих файлів (наприклад, типу CSV в архіві типу ZIP). Можливо, слід розглянути подібний варіант і відносно списку користувачів, що дуже актуально для бірж (наприклад, брокери) і магазинів (наприклад, продавці).