Оптимизация веб приложений реферат
Обновлено: 05.07.2024
В последние время мы часто обсуждали производительность, и сейчас, пришло время пересмотреть эту тему, приняв во внимание новые аспекты.
Приёмы, упоминаемые в этой статье, не относятся исключительно к PHP, но вы можете быть уверены, что при правильном использовании они выведут ваше приложение на совершенно новый уровень. Заметьте, что мы не будем рассматривать обычные приёмы.
То, что уменьшение количества запросов к файлам CSS, JavaScript и изображений ускоряет работу веб-сайта, а также прочие подобные советы общеизвестны. Вместо этого мы обратим внимание на менее известные и нечасто используемые приёмы.
1. Удалите несущественные элементы
Чем меньше элементов, тем лучше. Удалите лишний код HTML.
Это, конечно не может быть применено во всех без исключения случаях, но общее правило – структурируйте ваш код HTML таким образом, чтобы удалить как можно больше элементов DOM.
Вы также можете уменьшить размер HTML документа, опуская некоторые необязательные тэги. Да, это может показаться уловкой, противоречащей стандартам, поэтому это лучше делать только при публикации кода в сети – таким образом, вы не будете вводить в заблуждение других разработчиков, работающих с тем же кодом.
Предвыборкой называется приём, при котором вы заранее сообщаете браузеру, что вам потребуется тот или иной ресурс. Этим ресурсом может быть IP-адрес домена (предвыборка DNS), статического файла, такого как изображение или файл CSS, либо даже целой страницы.
Выигрыш получается небольшой, но при многократном применении, он поможет вам существенно сократить время загрузки запросов, которые делает браузер пользователя.
и поддерживается большинством браузеров.
Если у вас есть какие-либо субдомены, и вы ожидаете, что пользователь будет загружать с них какие-либо файлы после посещения текущей страницы, нет причин отказываться от использования предвыборки DNS.
Когда вы предполагаете, что некоторые ресурсы потребуются при следующем посещении, вы можете осуществить их предвыборку, при которой они будут загружены в кэш браузера.
Например, если у вас есть блог, а в нём статья из двух частей, вы можете предварительно загрузить статические ресурсы (например, изображения) из второй части, используя предвыборку.
Это делается следующим образом:
Веб-альбомы Picasa широко используют предвыборку двух изображений, следующих за текущим. В устаревших браузерах вы можете реализовать это, загружая изображение в JavaScript объект Image :
Этот код загружает изображение в кэш, но нигде его не использует. Однако этот метод не сработает для файлов CSS и JS, поэтому вам придётся проявить некоторую изобретательность, если вы хотите осуществлять предвыборку таких файлов в устаревших браузерах.
Обратите внимание, что предвыборку ресурсов следует использовать только в тех случаях, когда вы уверены или почти уверены, что они потребуются пользователю. Если пользователь читает статью блога, разбитую на страницы, однозначно делайте предвыборку.
Если пользователь заполняет форму, однозначно делайте предвыборку ресурсов, находящихся на странице, на которую он попадёт после отправки формы. Не делайте предвыборку всего вашего сайта или случайных страниц – учитывайте нагрузку на сервер, а также используйте предвыборку умеренно, держа в уме пользователей мобильных устройств.
Мобильные устройства, как правило, имеют ограниченные ресурсы, поэтому предварительная загрузка изображения весом в 2 Мб, вероятно, будет не слишком дружественным к пользователю решением. Вы можете избежать этих проблем, используя селективную предвыборку – определяйте, использует ли пользователь мобильное устройство или медленное соединение, и не используйте предвыборку в этих случаях.
Ещё лучше, добавьте настройки на ваш сайт, и спрашивайте посетителей, согласны ли они использовать предвыборку – сохраняйте их настройки в локальном хранилище и хэшируйте строкой user-agent , тем самым позволяя посетителям разрешать или запрещать предвыборку отдельно на каждом устройстве.
Вы также можете выполнять предвыборку и предварительный рендеринг целых страниц. Предвыборка страниц означает получение DOM контента – кода HTML. Это обычно не даёт существенного выигрыша в скорости, так как большую часть содержимого страницы на самом деле составляют JavaScript, CSS и изображения, то есть контент не загружаемый при предвыборке страницы.
Этот тип предварительной загрузки на данный момент поддерживается только в браузере Firefox .
Предварительный рендеринг – это другой метод. Он поддерживается только в браузере Google Chrome , и не только загружает DOM структуру документа, но и весь соответствующий контент: CSS, Javascript и изображения.
На самом деле, данный метод в фоновом режиме загружает и генерирует страницу целиком – страница помещается в оперативную память полностью загруженной и отрисованной и ожидает вывода на экран.
Это помогает практически моментально осуществлять переход при нажатии на предварительно выбранную ссылку, но порождает проблемы, которые описаны в предыдущем параграфе – страдают пользователи с медленным соединением.
В дополнение к этому, ваш сервер регистрирует предварительно загруженную страницу как посещённую, поэтому вы можете получить несколько неверную статистику посещений, если пользователь на самом деле передумает и не станет открывать эту страницу.
Синтаксис предварительного рендеринга следующий:
На данный момент существует только один способ определить, была ли ваша страница предварительно загружена – использовать Page Visibility API , который поддерживается во всех основных браузерах , за исключением браузеров Android и Opera Mini.
Используйте этот API, чтобы определить, действительно ли страница отображается на экране, а затем производите любые записи в статистику, которые вам необходимы.
Сервер
- Оптимизируйте ваш код PHP с помощью простых приёмов
PageSpeed от Google представляет собой модуль, устанавливаемый на Nginx и Apache, который будет автоматически использовать некоторые из лучших приёмов для оптимизации веб-сайта.
Данный модуль оценивает производительность веб-сайта так, как она воспринимается посетителями, следя за исполнением всех правил оптимизации, насколько это возможно, например, улучшая обработку статических ресурсов. Он минимизирует, оптимизирует и сжимает CSS и Javascript файлы за вас, уменьшает размер изображений, удалив ненужные метаданные, устанавливает заголовки Expires для оптимизации кэша браузера и делает многое другое.
Для достижения схожих с PageSpeed целей, Google также занимается разработкой SPDY . mod_spdy – это ещё один модуль Apache, созданный для ускорения работы веб-сайта.
Процесс его установки не совсем привычен , а также он требует поддержки в браузере, но с течением времени он совершенствуется .
WebP – это формат изображений, претендующий заменить все другие – JPG, PNG и GIF. Он поддерживает альфа-слои (прозрачность), анимацию, сжатие с потерями и без, и многое другое.
Сжимайте с помощью Zopfli
Используйте сжатие Zopfli , чтобы предварительно сжимать ваши статические ресурсы. Это алгоритм сжатия с открытым кодом, опять же распространяемый Google , который увеличивает сжатие на 3-8% по сравнению с обычными методами сжатия, используемыми в сети.
На маленьких веб-сайтах это вряд ли сыграет ощутимую роль, но если вы расширяете ваше приложение или предоставляете ваш статичный контент большому количеству посетителей, вы определённо заметите разницу, как следует из этого отчёта группы Google Web Fonts.
Заключение
Существует множество способов повысить производительность вашего приложения, и, как и всё в этой жизни – целое больше, чем просто сумма его составляющих. Внедрите некоторые из представленных выше приёмов оптимизации, и вы получите ощутимое улучшение. Внедрите их все – и вы получите настолько быстрое и лёгкое приложение, что оно сможет путешествовать во времени.
Никогда не позволяйте себе недооценивать небольшие исправления, которые вы могли бы сделать. Вы никогда не знаете, какое из них станет последним шагом на пути к совершенству!
Особенности, отличительные черты и назначение фреймворка Spring. Разработка проекта с использованием среды программирования IntelliJ IDEA на языке JVM Kotlin. Создание web-сервера на основе платформы Java, тестирование системой сборки Maven и JUnit.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 18.02.2019 |
| Размер файла | 285,8 K |
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Федеральное агентство железнодорожного транспорта
Кафедра "Автоматика и системы управления"
Пояснительная записка к курсовой работе
Оптимизация web-сервера
Выполнил: Студентка Е.В. Васильева
Руководитель: Е.А. Альтман
доцент кафедры АиСУ
Рассмотрено назначение фреймворка Spring, его особенности и отличительные черты. Выполнена разработка проекта с использованием этого фреймворка и его модулей. Изучен современный язык JVM Kotlin.
Результатом курсовой работы является рабочий веб-сервер с базой данных.
Веб-сервер разработан с использованием среды программирования IntelliJ IDEA Communiy Edition 2016.2.4. Исходный код программы написан на языке Java v.8 и Kotlin v.1.1.0. Пояснительная записка выполнена в текстовом редакторе Microsoft Word 2016.
Ключевые слова: Spring, JUnit, Mock-объект, Spring Boot, Maven, Kotlin, веб-сервер.
1. Spring Framework
1.3 Модули Spring
4. Запуск и тестирование веб-сервера
4.1 Запуск веб-сервера
4.2 Тестирование веб-сервера
Введение
Фреймворки - это программные продукты, которые упрощают создание и поддержку технически сложных или нагруженных проектов. Фреймворк, как правило, содержит только базовые программные модули, а все специфичные для проекта компоненты реализуются разработчиком на их основе. Тем самым достигается не только высокая скорость разработки, но и большая производительность и надёжность решений. В отличии от библиотечного метода, работа фреймворка зависит не от переданных методу агрументов, а модифицируется изменением участвующих в работе классов и объектов.
Целью данной работы является создание REST-сервера с JPA, который бы выполнял набор CRUD команд. Сервер должен создаваться с помощью фреймворка Spring, включать в себя класс на языке Kotlin и компоноваться системой сборки Maven. Сервер должен быть протестирован с помощью mock-объектов JUnit тестами.
Задание: разработать web-сервер с JPA (Java Persistence API) с помощью фреймворка Spring. Для сборки приложения необходимо будет скомпилировать несколько файлов исходных кодов и добавить объектные файлы библиотек. Требуется выполнить несколько вариантов сборки - для тестирования, для локального выполнения и для запуска на сервере.
1. Spring Framework
Spring Framework обеспечивает комплексную модель разработки и конфигурации для современных бизнес-приложений на Java - на любых платформах. Spring можно описать как совокупность нескольких независимых фреймворков, так и более сложных конструкций (фреймворк в фреймворке). программирование фреймворк spring java kotlin
Большинство данных структур может функционировать независимо друг от друга, однако они демонстрируют огромный объем работоспособности при совместном запуске приложения.
Spring, вероятно, наиболее известен как источник расширений (features), нужных для эффективной разработки сложных бизнес-приложений вне тяжеловесных программных моделей, которые исторически были доминирующими в промышленности.
Ещё одно его достоинство в том, что он ввел ранее неиспользуемые функциональные возможности в сегодняшние господствующие методы разработки, даже вне платформы Java. Этот фреймворк предлагает последовательную модель и делает её применимой к большинству типов приложений, которые уже созданы на основе платформы Java. Считается, что Spring реализует модель разработки, основанную на лучших стандартах индустрии, и делает её доступной во многих областях Java.
1.1 Spring MVC
Один из самых главных разделов фреймворка Spring -- Spring MVC. Фреймворк Spring Web model-view-controller (MVC) работает вокруг DispatcherServlet, который распределяет запросы по обработчикам. Обработчик по умолчанию строится на аннотациях @Controller и @RequestMapping, которые предоставляют широкий набор гибких методов для обработки запросов.
После версии Spring 3.0. механизм @Controller так же позволяет создавать RESTful веб сайты и приложения, используя аннотацию @PathVariable и другие возможности.
В Spring Web MVC есть возможность использовать любой объект в качестве команды или объекта с обратной связью; нет необходимости реализовывать какой-либо специальный интерфейс фреймворка или базовый класс.
1.2 Maven
Maven - это фреймворк для автоматизации сборки проектов специфицированных на XML-языке. Сборка происходит по установленным зависимостям в файле pom.xml.
Чтобы добавить или исключить какие-либо библиотеки или плагины в сборке проекта, достаточно просто указать зависимость в файле pom.xml и Maven автоматически его подключит и встроит в проект. Также в .xml файле указываются зависимости Spring Boot.
В Spring Boot уже включена Spring-платформа и сторонние библиотеки, для более простого запуска приложений. Пример файла pom.xml из проекта веб-сервера можно увидеть в приложении А.
1.3 Модули Spring
Фреймворк имеет модульную архитектуру, состоящую из ядра и отдельных проектов (модулей).
Spring Core - предназначен для конфигурирования приложения, состоящего из различных объектов различных классов.
Конфигурация содержит как список объектов приложения, так и устанавливает связи между ними. Это позволяет разрабатывать классы для логики приложения, не беспокоясь о типах используемых баз данных, обеспечения безопасности и др.
Spring Boot - предлагает шаблоны конфигурации для приложения. Отдельные настройки шаблона можно переопределить.
Spring Data - обеспечивает хранение данных в базах данных.
Spring Security - обеспечивает авторизацию и аудентификацию пользователей и разграничение доступа к объектам.
2. JPA
JPA - это технология, обеспечивающая объектно-реляционное отображение простых JAVA объектов и предоставляющая API для сохранения, получения и управления такими объектами.
Сам JPA не умеет ни сохранять, ни управлять объектами, JPA только определяет правила: как что-то будет действовать. JPA также определяет интерфейсы, которые должны будут быть реализованы провайдерами. Плюс к этому JPA определяет правила о том, как должны описываться метаданные отображения и о том, как должны работать провайдеры. Дальше, каждый провайдер, реализуя JPA определяет получение, сохранение и управление объектами.
В самом проекте объекты для JPA помечаются аннотациями. Класс, который будет являться сущностью в базе данных, отмечается аннотацией @Entity. Так как этот класс является сущностью для базы данных, в нем должен быть указан ключ, в нашем случае это ID. Интерфейс репозитория - @Repository. Этот интерфейс наследуется от интерфейса JpaRepository , где T - объект нашей сущности (класс с пометкой @Entity), а F - должен быть того же типа, что и ID из класса-сущности. При правильном наследовании Spring предоставит реализованные методы, указанные в интерфейсе. Пример реализации сущности и репозитория представлен в приложении Б.
3. Kotlin
Kotlin - язык программирования, разработанный компанией JetBrains, работающий на платформе Java. Он использует JDK, как и сама Java, но имеет другой синтаксис.
Появились они, в основном, из-за проблем с самой Java в плане синтаксиса. То есть, Java - язык надежный, хороший, добротный, на нём можно писать серверные приложения, но синтаксис у него, скажем так, излишне многословный.
Kotlin помог разработчикам писать программы с меньшим количеством кода. Помимо всего того, что есть в Java, он добавляет вещи из мира функционального программирования.
Это значительно облегчает написание кода - делает его короче и выразительнее.
Чем меньше кода мы пишем, тем меньше кода нужно поддерживать, писать меньше тестов.
Собственно, большинство языков появилось по этой самой причине - поменять синтаксис Java, сделать его более удобным, более прагматичным.
В реализованном проекте используется такая возможность языка как data-class (синтаксис представлен на рисунке 1).
Рисунок 1 - Создание data-class на языке Kotlin
Это класс с единственным назначением - хранение данных. Функционал этого класса, зависит от самих данных, которые в нем хранятся.
Data-class позволяет избавиться от большого количества шаблонного кода, который используется при создании аналогичного класса на языке Java.
Для автоматической генерации конструктора со всеми аргументами нужно задать начальные значения всех полей. А перед тем как добавить объект на постоянное хранение, его также нужно создать в памяти, для этого создается вторичный конструктор с двумя параметрами.
Пример выполнения данных действий представлен в приложении Б.
4. Запуск и тестирование веб-сервера
4.1 Запуск веб-сервера
Для запуска веб-сервера необходимо создать контроллер, который будет реагировать на определенные действия пользователя. Так как реализуется REST-сервер, то необходимо создать основные команды сервера: GET, POST, DELETE, PUT.
Контроллер будет реагировать на введенный адрес, находить его на своей карте запросов и выполнять нужное действие.
Рисунок 2 - Реализация реакции контроллера на запрос GET
Рисунок 3 - Ответ на запрос GET
4.2 Тестирование веб-сервера
Spring test позволяет писать JUnit тесты для сервера. Для этого создается mock-объект (объект-имитация), который будет симулировать действия клиента.
Объекты этого класса умеют делать запросы к серверу, получать и анализировать ответы.
Для создания mock-объекта в Spring требуется объект типа WebApplicationContext, который создается при запуске сервера. Аннотация @Autowired указывает Spring инициализировать ссылку на соответствующий объект. Аннотация @Before, указывает на метод, который будет запускаться перед всеми тестами и создавать Mock-объект (рисунок 4).
Рисунок 4 - Создание Mock-объекта для тестирования сервера
Функции тестирования помечаются аннотацией @Test и выглядят следующим образом. Создается объект класса ResultActions, который может проверить правильность ответа, полученного запросом от Mock-объекта.
Например, на рисунке 5, показана функция тестирования запроса DELETE.
С помощью Mock-объекта отправляется запрос на сервер и результат сохраняется в объекте perform типа ResultActions.
С помощью функции andExpect(status().isOk) проходит проверка правильно ли выполнился запрос и какой статус вернул сервер. Затем создается новый объект типа ResultActions, чтобы проверить метод DELETE, путем просмотра данных с сервера.
Если элементов стало на единицу меньше чем было, проверка происходит с помощью jsonPath, значит тест пройден успешно (рисунок 6). Листинг класса тестирования находится в приложении Г.
Рисунок 5 - Пример функции тестирования
Рисунок 6 - Результаты тестирования веб-сервера
Заключение
В ходе курсовой работы изучен фреймворк Spring и его модуль JPA, а также был реализован проект с их использованием.
По результатам работы можно сделать вывод о том, что фреймворк предназначен для решения типичных задач и в отличии от библиотечного метода, работа фреймворка зависит не от переданных методу аргументов, а модифицируется изменением участвующих в работе классов и объектов.
Изменяя используемые классы и объекты можно легко настроить работу программы.
Одним из главных преимуществ при использовании фреймворков является то, что веб-приложения часто используют стандартизированную структуру организации компонентов. Создание структуры при разработке на фреймворках очень упрощается.
Библиографический список
Когда следует оптимизировать?
Допустим, вы поняли, что вас (или ваше начальство, хехехе) не устраивает текущая производительность приложения. Что делать?
1. Измеряйте
Любая оптимизация должна начинаться с цифр. Если у вас нет времен исполнения отдельных фрагментов приложения, вы не можете заниматься оптимизацией эффективно. Вы можете долго оптимизировать фрагменты, которые вам проще оптимизировать, чем те, которые действительно тормозят, потому что у вас нет полной картины происходящего.
Можно измерять очень много различных вещей, но для веб-проектов обычно основное время занимает база данных или обращения к другим сервисам. Если вы не используете какой-то готовый фреймворк, или в ваш любимый фреймворк не входит дебаг-панель, достаточно даже такого кода для того, чтобы с чего-то начать:
2. Я сказал, измеряйте!
Время отдачи страницы с сервера — 100 мс, но вам всё равно жалуются, что страницы открываются долго? Измеряйте размер отдаваемых данных и показатели встроенных в браузер счётчиков производительности. Возможно, вашему сайту нужен CDN для отдачи статических данных, возможно нужно просто сменить хостинг-провайдера. Пока вы не измерите, где бутылочное горлышко, вы можете лишь гадать.
3. Будьте ленивы
4. Используйте (асинхронную) пакетную обработку
Ещё одна возможность ускорить пакетную обработку — это асинхронность. Если ваш язык это позволяет и вы можете сгруппировать запросы к разным сервисам в один и выполнить их асинхронно, то вы тоже получите ощутимое уменьшение времени ответа, причём чем больше сервисов, тем больше выигрыш. Это слабо применимо к MySQL, но хорошо применимо при работе, скажем, с медленным Google Datastore API.
5. Упрощайте сложное, распутывайте запутанное
Приведу пример: у вас есть здоровенный SQL-запрос, который что-то делает, и делает это (возможно) правильно, но ооочень медленно, сканируя при этом миллионы строк. Чтобы оптимизировать сложный SQL-запрос, для начала нужно его упростить, выкинуть оттуда всё лишнее, возможно, целые таблицы или вложенные выборки. Лишь после того, как вы убрали всё лишнее, можно начать проводить осмысленную оптимизацию. В противном случае, вы можете потратить много времени впустую, оптимизируя фрагмент, который никак не влияет на конечный результат. Часто, особенно при работе с MySQL, в качестве удовлетворительного решения может быть разбиение запроса на несколько более простых, каждый из которых работает намного быстрее исходного.
7. Кеширование
Если вообще больше ничего не помогает, или у вас есть данные, которые не меняются со временем, кешируйте их. Почему я утверждаю, что стоит использовать кеш только тогда, когда все другие опции израсходованы? Дело в том, что как только вы начинаете класть в кеш изменяемые данные, вы должны будете следить за актуальностью кеша, что является очень сложной инженерной задачей.
Безусловно, есть большое количество примеров, когда кеширование успешно применяется для увеличения производительности, но, опять же, после рассмотрения всех остальных возможностей. В операционных системах операции по работе с медленными носителями кешируются (чтение просто кешируется, запись буферизуется, что иногда приводит к порче данных или структуры файловой системы). Это дает ощутимый вклад в скорость работы, но, если вы когда-нибудь сравнивали user experience от работы с SSD и с жестким диском, вы никогда больше не захотите пользоваться последним, несмотря на кеширование :). В процессорах используется много уровней кеша, поскольку память различного объема отличается по скорости работы на порядки (сравните время доступа порядка 1 нс к регистровой памяти и 10 мс для жесткого диска — разница в 10 млн раз!), поэтому значительное усложнение архитектуры всё равно оправдано (иллюстрация взята из википедии).
Заключение
Итак, мы рассмотрели базовые способы повышения производительности (веб-)приложений, в основном рассматривая связку PHP+MySQL, как наиболее распространенную. Я лично использую приведенные выше подходы при оптимизации, и пока что мне удавалось без особых усилий ускорять проекты во много раз, иногда в десятки раз, потратив буквально несколько дней для самого большого из них :). Надеюсь, статья если не научит вас оптимизации, то по крайней мере подтолкнет вас (и ваших коллег) в правильном направлении, и мир станет чуточку лучше.
Интернет развивается с невероятной скоростью, как и разрабатываемая нами веб-платформа. Зачастую мы не задумываемся о том, как обстоит дело у наших клиентов. Лишь бегло взглянув на сегодняшнее состояние веба, можно заключить, что мы абсолютно забыли, насколько он изменчив.
Так что же есть современный интернет?
Только у 46% из 7.4-миллиардного населения Земли есть доступ в интернет. Средняя скорость соединения — 7Мб/с. Что более важно, 93% пользователей сидят в интернете с мобильных устройств, поэтому сегодня непростительно забывать о мобильных платформах.
Как люди, связанные с технологиями, мы чувствуем свое превосходство. С современными ноутбуками, телефонами последних моделей и быстрым интернетом просто забыть, что это есть не у каждого.
Как учесть эти нюансы в дизайне и разработке, не нанеся при этом ущерб представлению?
Один из наиболее эффективных, но редко используемых способов увеличения производительности состоит в том, чтобы понять, как браузер анализирует и хранит статику. Современные браузеры весьма успешно анализируют приоритет ресурсов прямо во время их парсинга. И именно здесь на сцене появляется критический запрос.
Запрос является критическим, если в нем содержится статика, необходимая для рендеринга контента в рамках пользовательского рабочего окна.
Для большинства сайтов это будет HTML, стили, логотип, шрифты и, возможно, изображения. Но на деле оказывается, что в это же время помимо них запрашиваются множество других, второстепенных вещей (JavaScript, трек-коды, реклама и т. д.). К счастью, мы можем контролировать это поведение, указывая приоритет подгрузки статики.
Благодаря можно напрямую предписать высокий приоритет в очереди загрузки статический файлов, что может значительно оптимизировать UX.
Для многих критические реквесты до сих пор остаются черным ящиком, и на этом в большой степени сказывается недостаток в свободном доступе материалов на данную тему. Однако, недавно Бен Шварц (Ben Shwartz) опубликовал невероятно исчерпывающую и доступную статью по этому предмету. Также рекомендуется к прочтению материал Preload, Prefetch and Priorities in Chrome.
Для отслеживания приоритетов запросов можно использовать Lighthouse performance tool и Critical Request Chains audit, или следить за запросами во кладке Network в панели разработчика Chrome .
В некоторых случаях один и тот же результат достижим несколькими способами. CSS богат художественными инструментами: тени, градиенты, анимации, фигуры. Все это позволяет надлежащим образом стилизованным элементам DOM служить достойной заменой статическим изображениям.
Выбор правильного формата
Если избежать использования статики невозможно, важно правильно определить для нее наиболее подходящий формат. Первая ступень — выбор между векторной и растровой графикой:
- Вектор: не зависит от разрешения, как правило значительно компактнее. Идеально подходит для логотипов, иконок и простых изображений, основанных на геометрии.
- Растр: подходит для высоко детализированных изображений, например, фотографий.
После принятия этого решения, вам откроется широкий выбор: JPEG , GIF , PNG -8, PNG -24, или новейшие форматы, такие как WEBP или JPEG - XR . Как не ошибиться в выборе из такого широкого спектра?
- JPEG: для изображений с богатой цветовой палитрой (например, тех же фотографий)
- PNG-8: для изображений с малым количеством цветовой
- PNG-24: для изображений с прозрачными участками
- GIF: для анимаций
Экспериментальные форматы
В последнее время на арене появились несколько новых форматов: WebP , JPEG 2000 и JPEG - XR . Все они были созданы разработчиками браузеров.
WebP – самый популярный из них. Он поддерживает сжатие с потерями и без потерь, что делает его невероятно гибким. Сжатый без потерь WebP весит на 26% меньше PNG и на 25-34% легче JPG . Он поддерживается 74% браузеров, а Photoshop позволяет конвертировать в этот формат JPG и PNG .
Оптимизация инструментами и алгоритмами
Даже использование самых эффективных графических форматов не оправдывает игнорирования последующей оптимизации. Это — ключевая ступень.
Если вы выбрали SVG , который сам по себе относительно мало весит, он тоже должен быть сжат. Для этого существует ряд неплохих инструментов, таких как SVGO или SVGOMG. Также, поскольку SVG – формат, основанный на XML , его можно сжать с помощью GZIP на стороне сервера.
Для большинства других форматов прекрасным выбором будет ImageOptim. Еще в этом году Google представил Guetzli - открытый алгоритм, происходящий из прошлого опыта с WebP и Zopfi . Он позволяет добиться сжатия JPEG до 35%. Единственный его недостаток — низкая производительность: около минуты CPU на один мегапиксель.
Адаптивность
Десять лет назад можно было обойтись одним разрешением на все случаи жизни. Сегодня же, в эпоху адаптивного веба, оптимизация играет ключевую роль. Благодаря Responsive Images Community Group, веб-разработчики прекрасно подкованы и вооружены.
Возможность использования кастомных шрифтов — невероятно мощный дизайнерский инструмент. Но большая сила сопряжена с большой ответственностью. По статистике шрифты являются главными врагами производительности примерно на 68% сайтов.
Выбор правильного формата
Существует четыре веб-формата: EOT , TTF , WOFF и более новый WOFF 2. TTF и WOFF используются чаще всего и поддерживаются более чем 90% браузеров. В зависимости от поддержки браузерами, самым оптимальным считается WOFF 2, а для старых браузеров — WOFF . Достоинство WOFF 2 заключается в том, что он подразумевает ряд кастомных препроцессорных и сжимающих алгоритмов, что позволяет уменьшить итоговый вес файла на 30% и существенно повысить возможности парсинга.
Ограничьте количество шрифтов
Вне зависимости от того, где хостятся шрифты, их количество, разновидности и стили существенно влияют на ресурсы производительности.
В идеале можно было бы обойтись одним шрифтом с обычным и жирным начертаниями.
Обозначьте стратегию загрузки шрифтов
Сначала браузер строит DOM и CSSOM ; шрифты не будут подгружаться до тех пор, пока не встретятся в CSS -селекторе уже существующего узла DOM . Такое поведение ощутимо замедляет рендеринг текста, часто приводя к эффекту FOIT (Flash of Invisible Text).
Наиболее простым и эффективным решением может стать FOUT ( Flash of Unstyled Text ).
Font - display – новое свойство CSS , предоставляющее возможность решить проблему без использования JS . К сожалению, он поддерживается лишь частично (в Chrome и Opera ) и все еще находится в процессе разработки в Firefox и Webkit .
Оптимизировать получение JavaScript – это только полдела. После того, как код будет загружен, он будет подвергнут парсингу, скомпилирован и запущен в браузере. Беглого взгляда на несколько популярных сайтов достаточно, чтобы понять, что gzipped JS после распаковки становится как минимум в три раза больше.
Избавьтесь от лишних зависимостей
В современных менеджерах легко проследить количество и размер всех зависимостей. Хорошими инструментами являются webpack-bundle-analyzer и Bundle Buddy. Визуальные инструменты позволяют обнаружить дублирование кода, самые большие затраты производительности, ненужные зависимости.
В VS Code и Atom есть расширение Inport Cost , делающее вес импортируемого пакета более наглядным.
По возможности нужно всегда стремиться хранить и загружать только необходимое. Поэтому код должен быть максимально разделен и структурирован. Также стоит обратить внимание на динамический импорт и ленивую загрузку.
В данной статье были рассмотрены основные приемы оптимизации современных веб-приложений. Сегодня, в эпоху стремительного развития интернет-технологий, громоздкие веб-сайты прошлого уходят в небытие, и на смену им приходят новые принципы и парадигмы веб-разработки.
HIGHLOAD или высокие нагрузки чаще всего появляется там, где серверная инфраструктура обеспечивает работу веб-проектов с высокой посещаемостью. Оптимизация веб приложения — процесс отладки кода, проводимый программистами, и процесс настройки ПО, выполняемый под каждый веб-проект индивидуально с учетом особенностей его работы.
Любой проекта редким исключением целесообразно запускать на виртуальном сервере с минимальной конфигурацией. Об архитектуре и развитии стоит задумываться тогда когда популярность проекта возрастает и серверу не хватает ресурсов для работы.
Для веб-сервера обычно используется связка Nginx+Apache, при росте проекта от последнего часто отказываются. В качестве сервера баз данных применяют обычно MySQL.
Nginx+Apache
Максимальную производительность можно получить используя Nginx с PHP-FPM, но такая конфигурация менее устойчива и сложнее поддерживается ввиду невозможности использования файлов .htaccess .
Nginx с PHP-FPM — лучшее решение для сервера, с которого работает один сайт и который постоянно поддерживается профессионалами.
Веб-сервер — только один из элементов системы, обслуживающей приложение. Ниже приведены основные принципы работы, которые применимы к приложению в целом.
Как контролировать ситуацию когда проект растет
При росте ресурса архитектуру системы следует совершенствовать — делается это за счет тюнинга ПО и заточки для работы с учетом выделенных серверу ресурсов (особенно это актуально для MySQL), и масштабированием — вертикальным или горизонтальным.
Вертикальное масштабирование — увеличение количества ресурсов.
Горизонтальное масштабирование — вынос части проекта на отдельные сервера.
Для того чтобы проверить как существующая конфигурация сервера поведет себя при возникновении высокой нагрузки можно сымитировав такие условия используя ab или Siege.
Для обеспечения быстродействия используется Memcached и нереляционные СУБД такие как MongoDB и Redis. Также часто создается несколько бэкенд и фронтэнд серверов запросы между которыми распределяются по предусмотренной заранее логике для того чтобы уменьшить нагрузку на инфраструктуру.
Нагруженные веб-проекты существуют на выделенных серверах или, чаще, на VPS и VDS. Облачные технологии становятся все дешевле и избавляют от необходимости иметь свой физический сервер. Арендовать мощности у специализированной компании, которая занимается поддержкой железа значительно выгоднее.
Вертикальное масштабирование в этом случае реализуется сменой тарифа — обычно без простоя в работе.
Когда увеличивать ресурсы более некуда (возможности железа не безграничны) или нецелесообразно — начинается масштабирование горизонтальное — вынос частей проекта на другие машины. Хорошее архитектурное решение помимо решения основной задачи позволит увеличить отказоустойчивость, скорость работы.
При планировании архитектуры окажутся полезны статья категории HIGHLOAD.
Прежде всего читайте про тонкую настройку Nginx. Он используется в абсолютном большинстве проектов.
Читайте также: