Можно вернуть только если они ввели вас в заблуждение, то есть указали что в неисправности входит отсутствующий конденсатор. Но, не уверен, что у вас будет достаточно доказательств этого. Скорее всего продали просто как "неисправная" без указания неисправностей.
Например в Chrome можно открыть "Инструменты разработчика", открыть там Resources, найти css файл, нажать правую кнопку и "Save". Или wget "site/style.css". Смотря что в наличии есть. Можете просто адрес css на cdn написать - напишу какой размер у него.
Тут ничего не могу сказать - не в курсе кто из них быстрее и на сколько.
В интернете пишут что Java быстрее, тут например sheremetov.com/php/java-vs-php выиграл php.
Некорректно. Java прочитала исходник и составила байт-код для себя, php прочитал исходник и составил байт-код для себя. Они не взаимозаменяемы, их выполняет не центральный процессор, а виртуальная машина конкретного языка - в первом случае java, во втором случае php.
Байт-код - промежуточный этап между чтением исходника и исполнением.
К быстродействию прямого отношения не имеет.
Грубо говоря у вас есть плохо написанный текст в тетради, с сокращениями и сносками на другие страницы - это исходник.
Вы с лупой в руке пытаетесь разобрать что там написано, переписываете все это красивым почерком на отдельный лист, сокращения пишите целиком, смотрите на сноски и вписываете их в нужные места - это байт код.
Далее вы можете выйти и прочитать уже разобранный текст перед аудиторией.
Если не сохранить этот листок - то если вас попросят еще раз прочитать - придется заново брать лупу, лазить по тетради в поисках сносок, додумывать пропущенные буквы.
Но читать быстрее чем вы умеете - вы не сможете.
Наверное вы имели в виду nginx + apache + mod_php + opcache и nginx + php-fpm + opcache.
И в том и в другом случае opcache работать должен и процесс как мне кажется выглядит очень похоже, кроме того что в первом случае запуском и остановом параллельных потоков занимается apache, а во втором случае php-fpm.
В первом случае apache вносит свою задержку и php-fpm считается быстрее и оптимальнее в плане работы с памятью.
Но опять же, скорость выполнения самого скрипта - одинакова, выиграть за счет перехода на php-fpm и подключении opcache можно только на расходе памяти, TTFB (время до выдачи первого байта). Nginx вообще must have для раздачи статики.
Если у вас сложные математические расчеты - пишите на C++ например, оптимизируйте ассемблерными вставками. Среднестатистический сайт - это (условно): выбрать из базы, выкинуть пробелы, добавить кавычки, подставить в шаблон страницы, вывести в браузер.
Нет.
Байт код - это не машинные инструкции, это https://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B9%D...
Например, VK написан на php, если не ошибаюсь. Вряд ли бы они стали писать на самом медленном языке.
Тормознутось была когда был apache + mod_php, то есть когда на каждый процесс запускался отдельный интерпретатор, транслировал программу в байт-код и исполнял ее, затем выгружался.
Не совсем так. Я уже выше писал на чем экономится время. Грубо говоря экономится как раз время преобразования php файла в байт код. Без OpCache файл сначала преобразуется в байт код, затем исполняется. При использовании OpCahce байт код берется из памяти и исполняется. Если вы в скрипте вычисляете, например, какую-то сложную формулу и ее вычисление занимает, например, 5 секунд, то никуда эти 5 секунд не денутся. Исчезнут только несколько десятков милисекунд, требуемые для чтения файла и преобразования его в байт-код. Пусть меня поправят, если я ошибаюсь.
То, чего вы опасаетесь, содержит такие ключевые слова как "nginx proxy_cache", "varnish", "http header expires".
С помощью этих средств, можно "пропустить" исполнение скрипта и отдать пользователю уже готовый (предыдущий) результат.