wp_enqueue_style('vendor_style', get_template_directory_uri().'/assets/css/foundation.css', array(), date('U'), true );
wp_enqueue_style('custom_style', get_template_directory_uri().'/assets/css/app.css', array(), date('U'), true );wp_register_style('themeStyle', $path . 'style.css');$path = get_bloginfo('template_directory') . "/" - зачем такая конструкция? get_template_directory_uri() создана специально для этого.wp_deregister_script('jquery'); - сколько переговорено на эту тему... Вы экономите на спичках, а конфликты у других плагинов с этим бывают. Иногда грузится 2 версии сразу - и родная, и ваша. Иногда плагины просто не видят вашу. Сейчас уже все реже такое происходит, но это есть. Смысл замены jQuery?'nonce' => wp_create_nonce('myajax-nonce'), является опасным решением с точки зрения безопасности. Пока оно используется в реальности для 1-2 вызовов каких-то похожих, типа подгрузки постов при скролле - проблемы не будет. Как только функционал растет, и действия на аякс-хуках выполняют разные вещи и требуют разных прав, использование одной nonce может быть опасным.
1. Если верстальщик - не давай советов в тех областях, в которых ничегошеньки не понимаешь.
2. Если не нужна матчасть - поздравляю, ты уже отстал от конкурентов. Матчасть нужна всем.
3. Разница куда кешировать сильно большая, так как кеш используется в процессе обработки запроса на сервере (в процессе работы скрипта), и никакого отношения к сети не имеет. Это именно время исполнения скрипта на стороне сервера. Скорость доступа к памяти и к диску сильно отличается:
Read 1 MB sequentially from memory 250,000 ns
Disk seek 10,000,000 ns
Если это небольшой простой скрипт с общим временем исполнения менее 100мс - разница несущественна, да и кешировать там нечего. Если это большой и сложный сайт, на котором одни запросы к БД могут выборки делать по секунде и больше, а потом из полученных массивов данных еще и надо что-то колбасить и генерить на вывод - такие вещи надо кешировать, для того и существует object cache и fragment cache. Дилеи на стороне сети это совершенно другая сфера, и там свои нюансы. Впрочем, средний сетевой дилей все равно всегда меньше серверного времени для сложных приложений.
4. Скорость соединения 20мбс вообще до лампочки. Что 2 Мбс, что 200. У протокола TCP есть такие штуки как congestion control, и ваши данные летают маленькими пакетами туда-назад с медленно растущей скоростью. Любая потеря пакета откатывает скорость назад. Поэтому в реальности канал/соединение практически никогда не утилизируется полностью. А для маленьких файлов (из чего состоит основа веб - html, css, js) утилизация сетевого ресурса никогда не превышает 1-3%. Если бы вы изучали матчасть, то были бы в курсе.
5. Время жизни кеша в оперативе как раз достаточное. Потому что кеш это изначально штука не вечная, он регулярно обновляется. У кеширующих бекендов реализована грамотная функция очистки кеша автоматом по принципу LRU (Least Recent Use). Опять же, матчасть.
6. Сервер грузит как раз запись на диск. Потому что ресурс чтения/перезаписи у RAM практически неисчерпаем, у дисков он сильно ограничен. Потому что каналов у RAM очень много, I/O у диска сильно ограничен. Кроме того, запись-чтение на диск в любой случае задействует и память промежуточно, плюс в памяти ОС кеширует дескрипторы файлов, плюс задействуется и CPU в большей степени. В общем, ресурсоемкость использования диска сильно выше, живучесть дискового носителя сильно ниже.
Повторюсь, учите матчасть. Или же не встрявайте в дискуссии, в которых ровным счетом ничего не понимаете.