Котик Антон

Родного ничего нет. Есть модуль ZfSimpleMigrations и есть альтернативы:
https://github.com/ziadoz/awesome-php#migrations

Оптимизация и продвижение сайтов в поисковых системах
Информации отсюда должно хватить на помощника seo-оптимизатора.

Ну дак в чем собственно вопрос, стоит ли делать подобные жертвы ради производительности?

Зависит от конкретной ситуации и размеров проекта. Если брать случай, что вы описали. Так можно пойти ещё дальше - вообще отказаться от классов, наверняка ещё каких-нибудь 0,005 секунд выиграете.

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

Не стоит экономить на спичках, когда можно добиться куда большего выигрыша в производительности другими путями, не жертвуя читаемостью кода: ruhighload.com

Сколько в среднем у вас выделяется памяти на сценарий и сколько времени это занимает?

Странный вопрос. Всё равно, что спросить "Сколько в среднем весят животные?"

svg

if (strpos($uid, 'uid') === 0) {
    // ...
}

A Guide to UTF-8 for PHP and MySQL

<?php

$input = 'some words link.com mysite.ru somelink.net';
$forbidden = ['link.com', 'somelink.net'];

// Экранируем все спецсимволы в списке запрещённых сайтов
$regexp = implode(array_map('preg_quote', $forbidden), '|');
$output = preg_replace('/(https?:\/\/)?(www\.)?(' . $regexp . ')/i', '***', $input);

https://ideone.com/FMyBPF

Можно и попроще:

<?php

$input = 'some words link.com mysite.ru somelink.net';
$output = preg_replace('/(https?:\/\/)?(www\.)?(link\.com|somelink\.net)/i', '***', $input);

Фон нужно задавать тогда для li, а ссылку сделать блочным элементом.

nav>ul>li {
    display: inline-block;
    background: #61c2e5;
    -webkit-transform: skewX(-20deg);
    -moz-transform: skewX(-20deg);
    -o-transform: skewX(-20deg);
}

nav>ul>li>a {
    display: block;
    text-decoration: none;
    padding: 10px;
    font-size:130%;
    color:white;
    -webkit-transform: skewX(20deg);
    -moz-transform: skewX(20deg);
    -o-transform: skewX(20deg);
}

Если файлов 1 и 2 нет в вашей ветке, а есть только в feature:

$ git checkout feature -- feature-1.cpp feature-2.cpp
$ git add --all
$ git commit -m "Merge some files from feature"

Если нет, и нужен честный мёрдж файлов, тогда создаёте ветку feature-v2 на базе feature, удаляете там ненужные файлы и мерджите основную ветку с feature-v2.

1 вариант
Самый простой вариант - два домена: site.com и m.site.com.
1. На домене site.com показываем ссылку "Мобильная версия сайта" на m.site.com.
2. На домене m.site.com - ссылку "Полная версия сайта" на site.com.

2 вариант
Если хотите, чтобы обе версии сайта были доступны по одному домену site.com.

1. Если у пользователя не установлен флаг, определяющий версию сайта (см. пункт 2), то определяем, зашёл ли пользователь с мобильного браузера (detectmobilebrowsers.com).
2. Если пользователь зашёл с мобильного браузера, то записываем некий флаг в сессию или куки. Например $_SESSION['mobile'] = 1.
3. Если установлен флаг мобильной версии, то отображаем мобильную версию и ссылку на "Полную версию сайта", иначе - полную версию и ссылку на "Мобильную версию сайта".
4. При переходе по одной из этих ссылок осуществляется запуск скрипта, устанавливающего $_SESSION['mobile'] = 1 (для мобильной версии сайта) или $_SESSION['mobile'] = 0 (для полной версии сайта), и делающего редирект обратно на предыдущую страницу. Возврат к шагу 1.

Для всех допустимых наборов параметров можно задать уникальный идентификатор, в ЧПУ оставляем только значения основных параметров:

Было:  http://site.com/?filter1=value1&filter2=value2&filter3=value3...
Стало: http://site.com/value1/value2?filter=123

php-cli composer.phar install