Як выдаліць лішнія карцінкі c сайта на WordPress

1. Як адключыць генерацыю непатрэбных мініяцюр
2. Як выдаліць не патрэбныя мініяцюры
3. Убудова DNUI Delete not used image
4. Што яшчэ можа пажыраць месца на дыску
5. Нагрузка на сервер
6. Мой вопыт выкарыстання CDN (Content Delivery Network)

Я прашу прабачэння ў маіх пастаянных чытачоў за гэты не тэматычны пост. Ўсё ніжэй наступнае зможа зацікавіць толькі ўладальнікаў сайтаў на WordPress. Абяцаю не злоўжываць гэтай тэмай надалей. Гэта першы мой пост на тэму блогінгам за 3 гады.

Як водзіцца праз 3 гады пасля пачатку вядзення блога я атрымала сумную вестку са свайго хостынгу:

На Вашым запісе засталося менш за дзесяць адсоткаў вольнай дыскавай прасторы. Недахоп месца можа прывесці да збояў у працы Вашых сайтаў і пошты.

За тры гады я вычарпала ліміт у 2Гб. Наогул вядома не варта было чакаць такіх папярэджанняў, але што зроблена, то зроблена. Я вырашыла выдаліць лішнія мініяцюры малюнкаў пры дапамозе убудоў. Вывучыўшы інтэрнэт на гэтую тэму, я зразумела, што топ выдачы поўны вельмі нізкаякасных пастамі. Ні адзін з гэтых пастоў не разьбірае праблему цалкам, а некаторыя даюць адкрыта шкодныя парады, якія гавораць аб тым што аўтары саветаў самі не разбіраюцца ў гэтым пытанні.

Па-першае варта зазірнуць у сваю тэчку uploads і паглядзець, а колькі ўвогуле робіцца превьюшек для кожнага запампаванага малюнка. У маім запушчаным выпадку аказалася, што на кожнае выява ў мяне генеруецца цэлых 6 мініяцюр рознага памеру, а цяпер на маім сайце больш за 3000 фатаграфій, так што гэтыя прэв'ю відавочна займаюць Колосальная аб'ём. Усе мініяцюры ствараюцца ў WordPress ў момант запампоўкі.

Alt / Prt / Scr Backupа на маім хостынгу, паколькі файлы я ўжо знесла

Вядома мне зусім не трэба было такая колькасць мініяцюр. Рэальна я выкарыстоўвала толькі мініяцюры памерам 150Х150 на старонках рубрык і пазнак, для «Бібліятэкі медыяфайлаў» памеру 150Х150 таксама цалкам дастаткова.

Далей я выкажу што з усім гэтым рабіць. Для пачатку трэба адключыць генерацыю непатрэбных мініяцюр.

змест артыкула

Як адключыць генерацыю непатрэбных мініяцюр

Крыніц генерацыі мініяцюр ўсяго 3, часцей за ўсё з іх згадваюць толькі першы.

1. Памеры мініяцюр задаюцца ў меню Налады → медыяфайлы
2. Генерацыя мініяцюр можа быць зададзена ў файле functions.php
3. Генерацыя мініяцюр можа быць зададзена ў убудовах, якія выкарыстоўваюць карцінкі, у мяне гэта быў убудова Manual Related Posts і Top 10, у вас могуць быць іншыя ўбудовы.

З першым пунктам разабрацца лягчэй за ўсё. Заходзіце ў адпаведны пункт меню і зануляете непатрэбныя вам памеры.

Калі ў вашай тэчцы uploads ёсць памеры ня зададзеныя у наладах медыяфайлаў, то варта адкрыць файл functions.php і пашукаць там радкі, якія ўтрымліваюць: «post-thumbnails«, у мяне я знайшла наступнае:

add_theme_support ( 'post-thumbnails');

Трэба спачатку падумаць, а ці патрэбныя вам гэтыя памеры. Калі вы лічыце, што не патрэбныя то, акуратна закомментируйте, усе падобныя згадкі. Калі каментаваць не акуратна, то можна атрымаць Fatal error.

Калі пасля гэтага кроку ўсё яшчэ засталіся не патрэбныя памеры мініяцюр то варта заняцца аналізам убудоў, якія выкарыстоўваюць карцінкі або могуць выкарыстоўваць прэв'юшкі. Магчыма варта выдаліць такія ўбудовы.

Асабліва падступныя розныя слайдшоў, як правіла ў слайдшоў выкарыстоўваецца 5-10 слайдаў, а прэв'юшкі вялікага памеру генеруецца для ўсіх запампоўваецца малюнкаў. На мой погляд гэта занадта вялікая раскоша захоўваць на сэрвэры 3000 мініяцюр, дзеля таго каб выкарыстоўваць ўсяго 10 з іх. Гэтыя 10 неабходных лепш зрабіць ўручную. Але тут гаварыцца, справа густу.

Мой убудова Top10 генераваў мініяцюру на кожную запампуешся карцінку, хоць рэальна выкарыстаў ад сілы 10 штук, г.зн. убудовы падступныя і пажыраюць месца на сэрвэры велізарнымі кавалкамі. Магчыма ўсё гэта ад таго што мініяцюры ў WP ствараюцца падчас запампоўкі карцінкі, калі б яны ствараліся толькі ў момант першага звароту за малюначкам, то не было б такой праблемы. Гэта так з разважанняў пра недахопы вордпресса.

У убудовах варта гэтак жа шукаць аўтапошуку па словах "post-thumbnails«, калі вы ўсё ж такі хочаце выкарыстоўваць убудова, але не жадаеце выкарыстоўваць карцінкі ў яго функцыянале. Пры абнаўленні плагіна гэтую аперацыю прыйдзецца паўтарыць.

Далей я рэкамендую праверыць вашы дасягненні, запампаваўшы любую карцінку. Пасля запампоўкі заходзіце ў тэчку upload і глядзіце, колькі превьюшек згенераваць.

Калі вынік задавальняе, то можна пераходзіць да наступнага этапу.

Як выдаліць не патрэбныя мініяцюры

Важна разумець, што мініяцюры генеруюцца не толькі ў тэчках на вашым серверы, для кожнай мініяцюры робіцца запіс у базе дадзеных сайта, таму проста выдаліць файлы мініяцюры ў тэчцы uploads на вашым серверы не вельмі добрая ідэя. Мініяцюры яшчэ выкарыстоўваюцца ў «Бібліятэцы медыяфайлаў» і ў «Мініяцюры запісы», пры няправільным выдаленні можна атрымаць наступную сумную карціну.

Пры выдаленні файлаў прэв'ю зніклі

Самі арыгіналы фатаграфій цэлыя, я выдаліла толькі мініяцюры памерам 300х199 і ў бібліятэцы медыяфайлаў перасталі паказвацца прэв'юшкі. На самай справе для гэтай мэты цалкам падыдуць мініяцюры памерам 150х150, але па змаўчанні ў бібліятэцы медыяфайлаў паказваюцца карцінкі сярэдняга памеру.

Таму лепш выкарыстоўваць убудова Thumbnail cleaner, ён выдаліць усе мініяцюры, а пасля гэтага вы сгенерируете новы палегчаны набор мініяцюр пры дапамозе плагіна Regenerate Thumbnails.

Я бачыла ў інтэрнэце парады тыпу: «Устаўце гэты код у файл functions.php і выканайце яго разок». А ў кодзе зносяцца толькі запісы з базы дадзеных, гэты шкодны савет не прывядзе да расчыстцы істотнага месца на вашым серверы. Важна выдаліць і запісы ў базе дадзеных, і файлы на сэрвэры. А потым згенераваць гэта ўсё зноўку ў паменшаным колькасці.

Гэтак жа важна разумець, што калі ў вас шмат малюнкаў гэты працэс створыць значную нагрузку на сервер, лепш яго вырабляць ноччу або ў дні калі наведвальнасць вашага сайта менш за ўсё, напрыклад у суботу. Ну і трэба наогул разумець, якую нагрузку вам у стане дараваць хостер без выключэння вашага сайта.

Натуральна трэба зрабіць Backup тэчкі uploads і базы дадзеных, на ўсялякі пажарны выпадак, але лепш без дапамогі плагіна Thumbnail cleaner, каб не нагружаць сервер, якому трэба будзе папрацаваць і без гэтай аперацыі.

Усяго ў мяне было каля 3000 фотаздымкаў і ўбудова Thumbnail cleaner, налічыў парадку 14000 мініяцюр, са зносам убудова справіўся за 2 хвіліны.

Генерацыя жа новых мініяцюр пры дапамозе плагіна Regenerate Thumbnails заняла цэлых 30 хвілін. І на наступную раніцу я атрымала лаянкавае ліст ад Sweb аб тым што я парушыла ўмовы нашага дагавора і перавысіла дазволеную мне нагрузку на сервер. Але на шчасце Sweb абмежаваўся толькі гэтым лістом. Ніжэй можаце ацаніць наколькі павысілася нагрузка на сервер у выніку маіх аперацый.

Убудова DNUI Delete not used image

Да таго як прарабіць ўсё вышэйпададзенае, я спрабавала скарыстацца убудовай DNUI Delete not used image, але нажаль вопыт аказаўся няўдалым. Два дні 16.03 і 17.03, я спрабавала эксперыментаваць з гэтым убудовай, гэта прыкметна, па узрослай нагрузцы на сервер. DNUI Delete not used image знёс акурат патрэбныя мне мініяцюры памерам 150х150, у выніку старонкі рубрык і пазнак страцілі свае карцінкі, прыйшлося аднавіць з Backup.

Усяго я ачысціла на сваім серверы 700Мб, зусім не дрэнна! Можа хопіць яшчэ на год наперад, да пераходу на наступны тарыф.

Што яшчэ можа пажыраць месца на дыску

Некаторыя ўбудовы могуць пісаць логі і ніколі не выдаляць іх.

За тры гады на маім сайце Total Cache запісаў больш за 1 Мб логаваў !!! Адключыць іх генерацыю немагчыма з адмінку, знесці іх можна толькі па FTP. Калі вы карыстаецеся Total Cache паглядзіце колькі важыць у вас змесціва гэтай тэчкі / wp-content / cache / log / 000000, магчыма, што пасля яе зачысткі вам не прыйдзецца важдацца з перегенерацией прэв'ю.

iThemes Security піша логі 404 памылкі не забывайце перыядычна іх чысціць. Асабліва логі разрастаюцца ў момант атакі на сайт.

Папулярны убудова Yoast SEO піша логі 404 памылкі, ці не шкодна будзе туды зазіраць, аналізаваць змесціва і ачысціць логі. Паглядзіце што ў вас у «Кансолі пошуку» Yoast SEO.

Многія ўбудовы ў момант ўстаноўкі запампоўваюць ўсе магчымыя моўныя пакеты, усё не патрэбныя вам мовы варта знесці. Упэўніцеся што ў вас знаходзіцца ў тэчках:

/ Wp-content / languages ​​/ themes

/ Wp-content / languages ​​/ plugins

Цалкам магчыма, што там засталіся моўныя пакеты ад невыкарыстоўваемых вамі тым і убудоў.

Праглядзіце вашы ўбудовы на прадмет не патрэбных вам моўных пакетаў па адрасах.

/ Wp-content / plugins / назва плагіна / lang (languages).

Папулярны убудова Yoast SEO піша логі 404 памылкі, ці не шкодна будзе туды зазіраць, аналізаваць змесціва і ачысціць логі.

Нагрузка на сервер

Маёй надзённай праблемай з'яўляецца перавышэнне нагрузкі на сервер, на маю тарыфе працэсы на маім сайце павінны займаць у дзень не больш за 60 хвілін працэсарнага часу. Пакуль Sweb мяне трывае, але хацелася б знайсці рашэнне гэтай праблемы. Я даўно ўжо паставіла сабе Total Cache і ён нават працуе, але пры ім падлучэнні я не заўважыла скачкападобнага памяншэння нагрузкі, а я яго чакала. У чым прыкол гэтага плагіна мне не зразумела.

Мая нагрузка дакладна не звязаная з атакай на сервер. Падчас атакі нагрузка павялічваецца скачкападобна, гэта не мой выпадак, яна ў мяне пару гадоў высокая і карэляваць з наведвальнасцю. Да таго ж я паставіла убудова бяспекі, змяніла старонку ўваходу ў адмінку, усе переборщики пароляў банятся пасля першай спробы.

Вядома выдзелены сервер вырашыць гэтую праблему, але ён стаіць нашмат даражэй, чым віртуальны хостынг. У мяне пакуль не тая наведвальнасць і не тыя заробкі, каб так раскашэліцца. Бо ў многіх блогераў бывае наведвальнасць і ў 2000 і 3000 уников, як вашыя сервера вытрымліваюць такую ​​нагрузку, якім хостынгам вы карыстаецеся? Буду ўдзячная за парады.

Мой вопыт выкарыстання CDN (Content Delivery Network)

Увага ўсё ніжэй пералічанае адбывалася двума месяцамі пазней расчысткі месца на дыску ад лішніх мініяцюр.

Я дачакалася чарговага злоснага лісты ад свайго хосцера Sweb. У сувязі з надыходам актыўнага турыстычнага сезона наведвальнасць майго сайта скачкападобна ўзрасла і нагрузка на сервер, якая ствараецца працэсамі на маім сайце дасягнула крытычнай велічыні 120 хвілін у суткі, нагадаю што паводле дамовы мойму сайту пакладзена спажываць усяго 60 хвілін працэсарнага часу ў суткі.

Sweb прапанаваў мне перайсці на іншы тарыф коштам усяго 800 руб. у месяц!!! Гэтая ня гуманная сума мяне ніяк не задавальняла, зараз я плачу усяго 120 руб. у месяц, падвысіць цану амаль у 6 разоў, гэта рабаванне. У выніку жаба мяне задушыла і я вырашыла паспрабаваць CDN ад CloudFlare, у рэшце рэшт іншага выйсця ў мяне не было.

У CloudFlare ёсць бясплатны тарыф, менавіта на яго я і падключылася. Больш за ўсё турботы выклікала патрабаванне перапісаць на CloudFlare мае DNS запісу, але я зрабіла гэта, і ў выніку вы бачыце на графіцы нагрузка на сервер істотна знізілася да парога які Sweb схільны дараваць. Момант далучэння CDN я адзначыла зялёнай пазнакай на малюнку.

Я вядома чакала большага, мне марылася ўбачыць лічбу 30 хвілін у суткі, але гэтага не адбылося. CDN гэта сістэма сервераў па ўсім свеце на якія капіюецца ваш сайт і пры запыце, напрыклад доме, які ідзе з ЗША, адказвае сервер размешчаны ў ЗША, а не ў Санкт-Пецярбургу, што павінна скараціць час загрузкі сайта і адначасна гэты метад скарачае нагрузку на мой сервер.

Акрамя сістэмы дастаўкі кантэнту CloudFlare прапануе яшчэ абарону ад DOS-нападаў, аналітыку і мінімізацыю html, css, і js. Я адключыла минимизатор ад Total Cache, паколькі нешта ён генеруе памылку, некаторыя мае тэксты вельмі доўгія і яму не хапае 64Мб аператыўнай памяці для мінімізацыі html.

Бясплатны рахунак CloudFlare мае шэраг абмежаванняў, што цалкам натуральна. За адзін запыт наведвальнік можа загрузіць з CloudFlare не больш 100Мб і сервера абнаўляюцца ў плыні 24 гадзін. Г.зн. калі прадаць спасылку пакупнік ўбачыць яе не адразу, а ў плыні 24 гадзін.

З недахопаў CloudFlare я заўважыла наступныя:

1. Функцыя Always Online зусім не гарантуе паказ вашага сайта, калі ваш уласны сервер перастане працаваць. Многія рускія блогеры абяцалі такую ​​фішку, але на самой справе гэта не так. На афіцыйным сайце CloudFlare напісана, што ён не захоўвае абсалютна ўсе старонкі вашага сайта, ён захоўвае першыя 10 html- старонак сайта і толькі некаторыя спасылкі з іх, самі разумееце, што гэта вельмі мала для блога які складаецца з 400 старонак. Таму, калі мой сервер падае, я бачу замест свайго сайта паведамленне пра памылку ад CloudFlare.
2. Мой сайт, падлучаны да CloudFlare блакуецца для інтэрнэт злучэнняў, якія выкарыстоўваюць TOR. Я гэта заўважыла сидючи ў facebook, там я раіла свой сайт людзям і некаторыя мне адпісваюцца, што старонка не адчыняецца. Што характэрна, калі яны заходзілі на мой сайт праз мабільны інтэрнэт у іх усё адкрывалася, у мяне таксама ўсё адкрывалася, сайт у гэты момант працаваў. Справа была менавіта ў інтэрнэт-злучэнні.

Паведамленне пра памылку, якое я бачу калі мой сервер злёг Аналітыка на кастрычнік 2017

Нагрузка на сервер істотна ўзрастае ў момант, калі я пішу артыкул, паколькі ў гэтым злучвае працуе мой сервер. Я адключыла стварэнне рэвізій зусім і нават адключыла магчымасці HeartBeat API, якое выконвае запісаны аўтаматычна запісу пры напісанні артыкула і іншыя функцыі, неабходныя, калі рэдактараў на сайце некалькі чалавек. Буду назіраць.

У кастрычніку 2017 мяне спасцігла чарговае гора. Пасля абнаўлення wordpress і убудоў, нагрузка на сервер зноў значна ўзрасла, гэта пры тым, што цяпер наведвальнасць у параўнанні з ліпенем менш. У логах памылак на сэрвэры чыста. Наогул гэтая карціна даволі тыповая, калі пасля абнаўлення убудоў ўзрастае нагрузка на сервер.

Нагрузка за ліпень, я перавышаю. Мая зона сіняя.

Я пераклала сайт на php7. Гэта было не проста. Спачатку пры пераключэнні замест свайго сайта я бачыла белую старонку з надпісам: «Памылка злучэння з базай дадзеных". Хостер мне не змог дапамагчы парадамі, прыйшлося разбірацца самастойна. Аказалася я выкарыстала састарэлае злучэнне з базай дадзеных. Для яго абнаўлення трэба проста перегенерировать пароль злучэння з базай дадзеных і ўсё, але на пошукі гэтага рашэння я выдаткавала 2 дні.

Пасля пераключэння нагрузка на сайт пачала зашкальваць за разумныя межы, насуперак шматлікім прадказанням аб тым, што яна проста абавязана ўпасці. Яшчэ некалькі дзён роздумаў і эксперыментаў і я вырашыла і гэтую праблему. Апынулася ў function.php маёй тэмы я дадала (па радах ад вопытных вэбмайстроў з інтэрнэту) функцыю, якая ўтрымоўвала ў сабе лішні цыкл, даўно ўжо. Пры працы на php5.3 перагрузкі не ўзнікала, а пасля пераключэння на php7 проста пачатак зашкальваць. Калі я ўстараніла гэтую праблему, я ўбачыла сваю нагрузку нарэшце ў сіняй зоне.

Зараз я паставіла пару новых убудоў (WP-PostRating і SNAP | AutoPoster) і зноў яе пакінула.

Нагрузка за кастрычнік. Пікі былі выкліканыя памылкамі ў function.php, яны выяўляліся толькі ў пра час працы ў адмінку, таму мне было цяжка знайсці ў чым справа

З думак з нагоды зніжэння нагрузкі для мяне актуальна наступнае:

1. Паспрабаваць замяніць убудова кэшавання Total Cache, на убудова які захоўвае голыя html-старонкі. Total Cache не эфектыўны на віртуальных хостынгах. Кэшаванне базы дадзеных не працуе, яму не хапае аператыўнай памяці, па той жа прычыне не працуе minifier. Рэальна з усяго багатага набору Total Cache працуе толькі для кэшаваньня старонак і браузерные кэшаванне. З нагоды кэшавання голага html мяне раздзіраюць думкі, а што будзе з даданнем каментароў і як будзе паказвацца google adsense, як будзе працаваць рэйтынг.
2. Паспрабаваць стварыць AMP- версію сайта, калі павольныя злучэння будуць загружацца з гугла, а не з майго сервера, нагрузка проста абавязаная зменшыцца. Тут вядома ўсё будзе залежаць ад колькасных характарыстык: усё пытанне ў тым, колькі карыстальнікаў у дзень будуць загружаць сайт з гугла? І хутчэй за ўсё налада гэтага плагіна таксама абяцае быць томнай.
3. І цяпер мяне грызуць сумневы ў правільнасці майго рашэння па зносе лішніх мініяцюр. Справа ў тым, што wordpress на мабільныя прылады будзе грузіць карцінкі шырынёй у 300 пікселяў ці ж 700 пікселяў, калі дазвол экрана маленькае, а калі мініяцюр няма то будзе грузіць поўнапамерныя карцінкі ў 1000 пікселяў па шырыні. Падумайце добра перш чым зносіць. Я збіраюся паспрабаваць убудова

   «SrcSet Responsive Images for WordPress», каб адкаціцца назад.

На будучы сезон напэўна трэба пераходзіць на выдзелены сервер на DigitalOcean. Я сама ніколі не канфігуравацца сервераў, таму працэс выклікае пытанні, але спадзяюся ў мяне атрымаецца. Абяцаю напісаць як яно пры выпадку.