Концепт мобильного приложения для клиники
Стартовые экраны мобильного приложения для медицинского центра в Канаде. Будем рады обратной связи, на сколько вам откликается концепт ?
Web-технологии
526 постов
•
5 799 подписчиков
0 просмотренных постов скрыто
Хромакей без зромакея для OBS на Macbook. При том довольно точный — для простых задач. Могу короткую инструкцию запилить
Хромакей без хромакея
Я не трейдер, балуюсь в свободное время, веду дневник и ни к чему никого не призываю.
Я веб разработчик, лучше на тг канал по программированию подписывайтесь @cododelia
CDN для начинающих: как ускорить загрузку вашего сайта по всем
Предисловие
Прошлая моя статья о LiteSpeed вызвала критику из-за излишней рекламности - и правда получилось так, что я пытаюсь продать вам этот веб-сервер. Прошу прощения за это недоразумение, постараюсь исправиться)
Сейчас хочу рассказать про CDN, а точне о том, как они помогают ускроить загрузку сайтов по всему миру.
Если вы когда-либо задумывались, почему некоторые сайты загружаются моментально, а другие заставляю вас ждать, то возможно пришло время познакомиться с CDN. Что это это такое и как оно работает я разберу далее.
Что такое CDN?
CDN (Content Delivery Network) - это сеть георграфически распределенных серверов, которые совместно работают для быстрой доставки интернет-контента пользователям. Цель CDN - уменишить задержки при загрузке веб-страниц, сокращая физическое расстояние между сервером и пользователем.
Как это работает?
CDN провайдеры размещают свои сервера в разных странах и регионах. Ваш статический контент (изображения, файлы CSS и JavaScript) хранится на этих серверах. Когда пользователь запрашивает ваш сайт, контент тянется с сервера, который находится ближе всего к нему географически. Это сокращает время отклика и ускоряет загрузку страницы.
Плюсы и минусы CDN
+ Меньшее расстояние до сервера означает более быструю передачу данных. Пользователи получают контент быстрее, что конечно улучшает их опыт взаимодействия с сайтом.
+ CDN обрабатывает большую часть трафика, разгружая ваш основной сервер и уменьшая риск его перегрузки.
+ CDN помогает справиться с резким увеличением трафика, например, во время распродаж или вирусного распространения контента.
+ Поисковые системы учитывают скорость загрузки страниц и ранжирование сайтов. Быстрый сайт может занять более высокие позиции в результатах поиска.
- Некоторые CDN-провайдеры могут быть дорогими, особенно для крупных сайтов с большим объёмом трафика 10. Однако существуют и бесплатные или доступные решения.
- Интеграция CDN может потребовать определённых технических навыков. К счастью, многие провайдеры предоставляют подробные инструкции и поддержку.
Как выбрать CDN?
1) Убедитесь, что провайдер имеет серверы в регионах, где находится ваша основная аудитория.
2) Обратите внимание на возможности сжатия изображений, оптимизации видео, аналитики и безопасности.
3) Сравните тарифы разных провайдеров и выберите оптимальный вариант для вашего бюджета.
4) Изучите отзывы и опыт других пользователей, чтобы выбрать надёжного партнёра.
Популярные CDN провайдеры
Cloudflare: Предлагает бесплатный план с базовыми функциями CDN и защиты.
Amazon CloudFront: Интегрируется с другими сервисами AWS, подходит для масштабных проектов.
Akamai: Один из лидеров рынка, ориентирован на корпоративных клиентов с высокими требованиями.
Заключение: Использование CDN — эффективный способ улучшить производительность вашего сайта и обеспечить быструю загрузку для пользователей по всему миру. В современном мире никто не хочет ждать, пока страница загрузится, а конкуренция за внимание пользователей высока. CDN помогает сократить время ожидания, повысить удовлетворённость посетителей и улучшить позиции в поисковых системах. Так что, если вы хотите, чтобы ваш сайт летал, как супергерой в мире интернета, CDN — ваш надёжный помощник.
Показать полностью
Почему LiteSpeed - серверы выигрывают у Apache и Nginx?
В современном веб пространстве скорость и производительность сайтов имеют решающее значение. Пользователи ожидают быстрой загрузки страниц, а поисковые системы учитывают время отклика при ранжировании. Поэтому выбор веб-сервера имеет критически важное значение. Давайте разберемся почему LiteSpeed часто превосходит Apache и Nginx.
1. Высокая производительность и скорость.
Представьте себе веб-сервер, который способен жонглировать тысячями запросов, не проливая ни капли пота. Это LiteSpeed! Благодаря своей событейно-ориентированной архитектуре, он работает так же быстро, как кофе по утрам!)
В то время как Apache все еще пытается проснуться со своей процессной архитектурой, LiteSpeed уже пробежал марафон.
2. Встроенное кэширование с LSCache
Вот кто не любит, когда все работает быстрее? LSWS приходит с подарком - встроенным кэшэм. Это как личный шеф-повар, который зарнее готовит ваши любимые блюда)
Ваш сайт будет подавать страницы так быстро, что пользователи предположат, что вы предсказываете их желания))) И конечно он дружит с такими CMS как Wordpress, Joomla и прочие..
3. Поддержка современных протоколов
LiteSpeed - всегда вкурсе последних трендов.
Имеется поддежка HTTP/3 и QUIC, что делает передачу данных быстрее скорости света. Это особенно круто для мобильных пользователей и тех, кто сидит на интернете с улиточной скоростью - теперь все будет летать!)
4. Эффективное использование ресурсов
Цены на железо достигают колосальных цен, а зачем тратить больше, когда можно тратить меньше?
LiteSpeed экономит оперативную память и процессорное время так, словно сам за них платит)
Большее кол-во пользователей может быть обслуженно на том же железе, позволяя вам сэкономить на инфраструктуре, потратьте эти деньги на родных и близких ;)
5. Совместимость с Apache
Боитесь перермен? Я тоже. Как хорошо, что LiteSpeed полностью совместим с конфигурационными файлами Apache. Переходите на РЕАЛЬНО хороший вебсервер без головной и жопной боли из за переписывания всех настроек с нуля.
6. Бесплатная версия OpenLiteSpeed.
Не уверенны? Хотите попробовать, а трайл версии мало? OpenLiteSpeed идеальный вариант для временного решение, ведь по функционалу, он не сильно то и урезан, грубо говоря чуть более старая версия нынешнего LiteSpeed.
Заключение
К чему эта статья? Создатели веб-серверов, хватит уже жить в эпохе динозваров! Нам, пользователям, нужна скорость и удобство. Зачем нам Apache и Nginx, когда есть нечтно новее, с GUI и высокой производительностью?
Не время ли оставить старые добрые и "ламповые" сервера для музеев технологий? Зачем нам разгонять интернет на паровой машине, когда давно придумали реактивные двигатели.
И, честно говоря, кто станет использовать веб-сервера, требующие знания древних заклинаний для настройки? Может, некоторым хостингам кажется, что это весело? Ну что ж, пусть продолжают жить в мире дискет и модемов)) (Привет синийхост точка ком)
Давайте двигаться вперед и использовать современные технологии, которые делают жизнь проще, а сайты быстрее)
Мы все заслуживаем скорость света в интернете, а не прогулки с черепахой, мы же платим за это деньги!
Показать полностью
Бинарники, RUST и JavaScript (Bun)
В комментариях рассказывал, что учил Rust, делая пошаговый эффективный setup сценарий для настройки Ubuntu в качестве веб сервера.
После чего планировалось его собрать в бинарник.
Я нашел нужные библиотеки, разобрался с базовыми принципами работы на Rust, и определил порядок действий и архитектуру проекта, но на этом и остановился, так как подвернулся коммерческий проект.
Так сейчас я вспомнил один факт!
У JavaScript - есть шикарнейшая среда выполнения Bun, предоставляющая еще и набор довольно интерсных инструментов.
Полностью о нём пока не стану рассказывать, суть не в этом, а в возможности компиляции кода в бинарник. При этом, нечто подобное есть и в последних версиях NodeJS в виде патчинга бинарника интерпретатора JavaScript кодом (упоминалось начиная с 16, если не ошибаюсь).
Но в Bun умеет в рантайм исполнения TypeScript без необходимости сборки проекта в JavaScript. А ещё говорят, что есть возможность оптимизации этого TS/JS в байткод.
Но я вижу, что Bun явно в проигрыше по памяти, а производительность и не ставил под сомнение, Rust шустрее.
Такой скрипт занимает 20Mb RAM, а сам по себе весит 57Mb
Но!
Мне никогда и не требовалась производительность. У меня в приоритете скорость и удобство разработки.
А в NPM я помню, есть огромное разнообразие отличных библиотеки для CLI.
И упаковав это всё дело в бинарник весом ±60-120Mb — останется просто его закинуть на сервер, запустить, выбрать что нужно установить, И..(!)
Пойти пить чай на минут 15
(вместо 20-60 минут настройки сервера - мы тратим 5 минут и пьем чай 10-20, и это при наличии опыта, новичкам сильно больше сэкономит времени)
Обязательно сделаю такой инструмент, по идее он сможет привлечь не очень опытных Linux юзеров и собрать вокруг себя комьюнити. (правда из новичков)
А ещё, для шарящих — пробую Cursor в сравнении с Github Copilot и взял в работу проект, на котором будет расширение для браузера на React в WXT и бэкендом на AppWrite
Так что будет чего интересного рассказать и обсудить у меня в тг @cododelia (тыкабельно)
Показать полностью
1
Отслеживание сетевой активности и переходов между страницами в SPA
При создании инъецируемых скриптов для сайтов, использующих архитектуру SPA (Single Page Application), может возникнуть потребность отслеживать переходы между страницами или перезагрузки элементов. Из-за динамической подгрузки контента через AJAX и Fetch, события DOMContentLoaded или load будут бесполезны.
Для инъецируемых скриптов, хорошим решением будет отслеживать состояние радиомолчания (network idle). Оно наступает, когда все сетевые запросы завершены, и сеть на некоторое время «замолкает». Подобное поведение полезно, если нужно запустить код только после того, как пройдут все запросы или после перехода на другую страницу, чтобы реинициализировать скрипт.
💻 Пример сценария использования
Представьте себе, что вы хотите внедрить кнопки, виджет или другую логику на странице, которая должна запускаться после перехода на новую страницу в SPA-приложении. В этом случае подойдет отслеживание network-idle, чтобы понять, когда контент страницы загрузился.
🤫 Как это работает
Инициализация счетчика активных сетевых запросов.
Сниппет отслеживает все сетевые запросы на странице (Fetch и XMLHttpRequest) с помощью PerformanceObserver. Каждый раз, когда начинается новый сетевой запрос, счетчик activeRequests увеличивается.
Обработка завершения запросов.
После завершения запроса activeRequests уменьшается, и проверяется состояние сети. Если активных запросов не осталось, через 500 мс на объекте window генерируется событие network-idle.
Использование события network-idle.
На это событие можно подписаться, чтобы выполнять нужные действия, как только страница завершит все сетевые активности и будет готова для следующей операции.
4. Задержка перед генерацией события.
Задержка в 500 мс добавлена, чтобы устранить "шум" случайных срабатываний и убедиться, что действительно наступило состояние радиомолчания.
📞 Важно:
Модификации роутов в SPA. Если у вашего SPA-приложения не используются сетевые запросы при изменении маршрутов, дополнительно можно привязаться к событиям history.pushState и popstate.
Очистка обсерверов. Не забывайте отключать обсерверы, чтобы избежать утечек памяти, если ваш скрипт прекращает свое действие при определенных условиях.
🫡 Заключение
Этот сниппет помогает организовать логику на основе сетевых событий в инъецируемых скриптах для приложений с динамическим роутингом, позволяя учитывать состояние “радиомолчания” и гарантируя, инъецируемые скрипты выполняются после прогрузки страницы, а также помогает перезапускать инъецируемый скрипт при переходах между страницами.
Ознакомиться со сниппетом можно на GitHub Gist.
А подобные посты чаще в пишу в Telegram канале, там же и пример проекта, где это применимо.
Показать полностью
Вот и кончился дискорд
Ну что, еще раз стерпим?
Ладно, отставить политоту, вопорос технического характера: через что идут голосовые каналы дискорда?
Я пользуюсь nekoray в режиме bypass, т.е. весь трафик напрямую, кроме указанных доменов или ip. Без обхода дискорд вообще не работает. Отправлять обычные текстовые сообщения и читать любые, включая просмотр фото и скачивания файлов, я смог после включения встроенной группы geosite:discord. Картинки отправлять смог после добавления адресов с хабра (статья 849092). А вот в войс зайти не могу, вернее зайти-то могу, подключить к нему не могу.
Ну или пора перестать страдать фигней и вообще весь трафик пускать через VPN, кроме зоны .ru?
Подключение к Mega Home он же Wifire
Задолбал уже меня домашний интернет от окадо, думаю дай подключусь к мегафону, тем более есть несколько номеров мобильных от мегафона. Оставил заявочку в воскресенье, договорились на вторник на подключение, как обычно с 12 до 14. В понедельник даже смс прислали чтобы я не забыл отпроситься с работы..
Настает 12 часов вторника, сижу дома, пью чай, интернета нет..... 14 часов, пообедал, монтажника тоже нет..., в 15 часов не выдержал позвонил в поддержку, 9 минут прослушал музыку, и тут барышня мне заявляет, видите ли, у монтажника очень сложное предыдущее подключение, поэтому мы отменили вашу заявку и ни позвонить, ни предупредить не могли, на вопрос кто будет компенсировать отгул поддержка ничего сказать не могла. Как я сдержался не знаю и в довершении розочка на тортик: когда все же сможет прийти монтажник? а через 6 дней))). Так что думайте стоит с ними связываться или нет.
ps место действия Москва