Ako optimalizovať PHP Laravel webovú aplikáciu pre vysoký výkon?

Laravel je veľa vecí. Ale rýchly nie je jeden z nich. Dozvieme sa niekoľko trikov z obchodu, aby sme mohli ísť rýchlejšie!


Žiadny vývojár PHP nie je nedotknutý laravel v týchto dňoch. Sú to buď vývojári na nižšej alebo strednej úrovni, ktorí milujú rýchly vývoj, ktorý Laravel ponúka, alebo sú to starší vývojári, ktorí sú nútení učiť sa Laravelovi kvôli tlakom na trhu..

V žiadnom prípade nemožno poprieť, že Laravel revitalizoval ekosystém PHP (určite by som opustil svet PHP už dávno, keby tam Laravel nebol)..

Úryvok (trochu opodstatnené) sebaúcty od Laravela

Keďže sa však Laravel ohýba smerom dozadu, aby vám to uľahčil prácu, znamená to, že pod ním robí tony a tony práce, aby ste sa uistili, že máte pohodlný život ako vývojár. Všetky „magické“ črty Laravelu, ktoré podľa všetkého fungujú, majú vrstvy na vrstvách kódu, ktoré je potrebné pri každom spustení funkcie vyšľahať. Dokonca aj jednoduchá stopa Výnimka sleduje, ako hlboká je králičia diera (všimnite si, kde sa chyba začína, až k hlavnému jadru):

Čo sa javí ako chyba kompilácie v jednom z pohľadov, je možné sledovať 18 funkcií. Osobne som sa stretol so štyridsiatimi rokmi, a ak by ste používali iné knižnice a doplnky, mohlo by to byť omnoho viac.

Poukazujúc na to, že v predvolenom nastavení sú tieto vrstvy na vrstvách kódu, Laravel spomaľuje.

Aké pomalé je Laravel?

Úprimne povedané, je zrejmé, že na túto otázku nie je možné odpovedať z niekoľkých dôvodov.

najprv, Neexistuje žiadny akceptovaný, objektívny a rozumný štandard na meranie rýchlosti webových aplikácií. Rýchlejšie alebo pomalšie v porovnaní s čím? Za akých podmienok?

druhý, webová aplikácia závisí od toľkých vecí (databázy, súborového systému, siete, vyrovnávacej pamäte, atď.), že je hlúpe hovoriť o rýchlosti. Veľmi rýchla webová aplikácia s veľmi pomalou databázou je veľmi pomalá webová aplikácia. ��

Táto neistota je však dôvodom, prečo sú referenčné hodnoty populárne. Aj keď nič neznamenajú (pozri toto a toto), poskytujú určitý referenčný rámec a pomáhajú nám zblázniť sa. Preto, keď je pripravených niekoľko štipiek soli, získajme zlú hrubú predstavu o rýchlosti medzi rámcami PHP.

Ideme týmto pomerne slušným GitHubom zdroj, takto sa porovnávajú rámce PHP v porovnaní:

Laravel si tu možno ani nevšimnete (aj keď škrípate naozaj tvrdo), pokiaľ svoj prípad nezahodíte až na koniec chvosta. Áno, milí priatelia, Laravel je posledný! Teraz, samozrejme, väčšina z týchto „rámcov“ nie je príliš praktická alebo dokonca užitočná, ale hovorí nám, ako je pomalý Laravel v porovnaní s inými obľúbenejšími..

Normálne sa táto „pomalosť“ v aplikáciách nevyskytuje, pretože naše každodenné webové aplikácie zriedka zasiahnu vysoké čísla. Ale akonáhle to urobia (povedzme, hore od 200 do 500 súbežnosti), servery sa začnú dusiť a zomierajú. Je to čas, keď problém nevyhadzuje viac hardvéru a účty za infraštruktúru sa vyšplhajú tak rýchlo, že padajú vaše vysoké ideály cloud computingu.

Ale hej, rozveseliť sa! Tento článok sa netýka toho, čo sa dá urobiť, ale o tom, čo sa dá urobiť. ��

Dobrá správa je, že dokážete urobiť svoju aplikáciu Laravel rýchlejšie. Niekoľkokrát rýchlo. Áno, bez srandy. Rovnakú kódovú základňu môžete urobiť balistickou a každý mesiac ušetriť niekoľko stoviek dolárov za účty za infraštruktúru / hosting. Ako? Poďme na to.

Štyri typy optimalizácie

Podľa môjho názoru môže byť optimalizácia vykonaná na štyroch rôznych úrovniach (pokiaľ ide o PHP aplikácie, to je):

  1. Jazyková úroveň: To znamená, že používate rýchlejšiu verziu jazyka a vyhýbate sa špecifickým funkciám / štýlom kódovania v jazyku, ktorý spomaľuje váš kód.
  2. Rámec na úrovni: Toto sú veci, ktorými sa budeme zaoberať v tomto článku.
  3. Infraštruktúra-level: Vyladenie správcu procesov PHP, webového servera, databázy atď.
  4. Hardware-level: Prechod na lepší, rýchlejší a výkonnejší poskytovateľ hardvérových hostiteľov.

Všetky tieto typy optimalizácie majú svoje miesto (napríklad, php-fpm optimalizácia je dosť kritická a výkonná). Tento článok sa však zameria na optimalizáciu čisto typu 2: optimalizácie týkajúce sa rámca.

Mimochodom, za číslovaním nie je nijaké odôvodnenie a nie je to akceptovaný štandard. Práve som si ich vymyslel. Nikdy ma necitujte a nehovorte: „Na našom serveri potrebujeme optimalizáciu typu 3,“ alebo vás vedúci tímu zabijú, nájdu ma a potom ma tiež zabijú. ��

A teraz konečne dorazíme do zasľúbenej krajiny.

Uvedomte si databázové dotazy typu n + 1

Problém s dopytom n + 1 je bežný, keď sa používajú ORM. Laravel má svoj silný ORM s názvom Eloquent, ktorý je tak krásny, tak pohodlný, že sa často zabúdame na to, čo sa deje.

Zoberme si veľmi častý scenár: zobrazenie zoznamu všetkých objednávok zadaných daným zoznamom zákazníkov. Toto je celkom bežné v systémoch elektronického obchodu a vo všetkých rozhraniach na podávanie správ všeobecne, kde musíme zobraziť všetky entity súvisiace s niektorými entitami.

V Laraveli by sme si mohli predstaviť funkciu radiča, ktorá vykonáva túto úlohu:

class OrdersController rozširuje Controller
{
// …

public function getAllByCustomers (Žiadosť $ request, array $ ids) {
$ customers = Customer :: findMany ($ ids);
$ objednávky = collect (); // Nová kolekcia

foreach ($ zákazníci ako $ zákazníci) {
$ objednávky = $ objednávky->merge ($ zákazník->príkazy);
}

návratové zobrazenie (‘admin.reports.orders’, [‘objednávky’ => $ Príkazy]);
}
}

Sladká! A čo je dôležitejšie, elegantné, krásne. ����

Bohužiaľ je to katastrofálny spôsob, ako napísať kód do Laravelu.

Tu je dôvod.

Keď požiadame spoločnosť ORM, aby hľadala daných zákazníkov, vygeneruje sa dotaz SQL, ako je tento:

VYBERTE * Od zákazníkov, KTORÍ SA PRIDÁVAJÚ (22, 45, 34, …);

Čo je presne podľa očakávania. Výsledkom je, že všetky vrátené riadky sa uložia do zbierky $ zákazníci vo funkcii radiča.

Teraz prekrížime každého zákazníka jeden po druhom a získame jeho objednávky. Vykoná sa nasledujúci dotaz . . .

VYBERTE * Z objednávok, kde customer_id = 22;

. . . toľkokrát, koľko je zákazníkov.

Inými slovami, ak potrebujeme získať údaje o objednávke pre 1 000 zákazníkov, celkový počet vykonaných databázových dopytov bude 1 (pre získanie všetkých údajov zákazníkov) + 1 000 (pre získanie údajov o objednávke pre každého zákazníka) = 1001. Toto je miesto, odkiaľ pochádza meno n + 1.

Môžeme robiť lepšie? Rozhodne! Použitím tzv. Nedočkavého načítania môžeme donútiť ORM, aby vykonal spojenie a vrátil všetky potrebné údaje do jediného dotazu! Páči sa ti to:

$ orders = Customer :: findMany ($ ids)->s (, zákazky ‘)->get ();

Výsledná dátová štruktúra je iste vnorená, ale údaje o objednávke sa dajú ľahko extrahovať. Výsledný jediný dotaz je v tomto prípade niečo podobné:

VYBERTE * Od zákazníkov VNÚTORNÉ PRIPOJENIA objednávok NA customers.id = orders.customer_id WHERE customers.id IN (22, 45, …

Jeden dotaz je, samozrejme, lepší ako tisíc ďalších otázok. Predstavte si, čo by sa stalo, keby spracovalo 10 000 zákazníkov! Alebo Boh zakáž, ak by sme chceli zobraziť aj položky obsiahnuté v každom poradí! Pamätajte, že názov tejto techniky je horlivý a je to takmer vždy dobrý nápad.

Cache konfiguráciu!

Jedným z dôvodov pružnosti Laravelu je množstvo konfiguračných súborov, ktoré sú súčasťou rámca. Chcete zmeniť, ako a kde sa obrázky ukladajú?

Stačí len zmeniť súbor config / filesystems.php (aspoň ako písať). Chcete pracovať s viacerými ovládačmi frontov? Neváhajte a opíšte ich v súbore config / queue.php. Len som spočítal a zistil som, že existuje 13 konfiguračných súborov pre rôzne aspekty rámca, čo zaistí, že nebudete sklamaní bez ohľadu na to, čo chcete zmeniť..

Vzhľadom na povahu PHP sa Laravel zakaždým, keď príde nová webová požiadavka, prebudí, zavedie všetko a analyzuje všetky tieto konfiguračné súbory, aby zistil, ako tentoraz urobiť veci inak. Až na to, že je hlúpe, ak sa za posledných pár dní nič nezmenilo! Opätovným zostavením konfigurácie pri každej požiadavke je strata, ktorej sa dá vyhnúť (musí sa tomu skutočne vyhnúť) a východiskom je jednoduchý príkaz, ktorý Laravel ponúka:

konfigurácia remeselníka php: cache

Robí to kombináciou všetkých dostupných konfiguračných súborov do jedného a vyrovnávacej pamäte je niekde na rýchle načítanie. Až nabudúce príde webová požiadavka, Laravel tento súbor jednoducho prečíta a rozbehne sa.

To znamená, že ukladanie do vyrovnávacej pamäte konfigurácie je mimoriadne chúlostivá operácia, ktorá vám môže vyraziť do rúk. Najväčšia gotcha je, že po zadaní tohto príkazu sa volania funkcie env () odkiaľkoľvek okrem konfiguračných súborov vrátia na null!

Dáva to zmysel, keď na to myslíte. Ak používate ukladanie do vyrovnávacej pamäte konfigurácie, hovoríte o rámci: „Vieš čo, myslím, že som veci nastavil pekne a som si stopercentne istý, že ich nechcem meniť.“ Inými slovami, očakávate, že prostredie zostane statické, pre čo sú súbory .env.

Ďalej je tu niekoľko železných, posvätných, nerozbitných pravidiel ukladania do vyrovnávacej pamäte:

  1. Urobte to iba na produkčnom systéme.
  2. Urobte to iba vtedy, ak ste skutočne, skutočne chcete zmraziť konfiguráciu.
  3. V prípade, že sa niečo pokazí, zrušte nastavenie pomocou medzipamäte php remeselníka: jasné
  4. Modlite sa, aby škoda spôsobená podniku nebola významná!

Znížte počet automatických služieb

Keď bude prebudený, načíta Laravel veľa služieb. Sú dostupné v súbore config / app.php ako súčasť kľúča ‘poskytovatelia’. Pozrime sa, čo mám v mojom prípade:

/ *
|————————————————————————–
| Poskytovatelia služieb s automatickým prístupom
|————————————————————————–
|
| Poskytovatelia služieb uvedení tu budú automaticky načítaní na internet
| žiadosť o prihlášku. Neváhajte a pridajte svoje vlastné služby
| Toto pole poskytuje rozšírené funkcie vašim aplikáciám.
|
* /

‘poskytovatelia’ => [

/ *
* Poskytovatelia služieb Laravel Framework…
* /
Illuminate \ Auth \ AuthServiceProvider :: class,
Illuminate \ Broadcasting \ BroadcastServiceProvider :: class,
Illuminate \ Bus \ BusServiceProvider :: class,
Illuminate \ Cache \ CacheServiceProvider :: class,
Illuminate \ Nadácia \ Providers \ ConsoleSupportServiceProvider :: class,
Illuminate \ Cookie \ CookieServiceProvider :: class,
Osvetliť \ Database \ DatabaseServiceProvider :: class,
Illuminate \ Encryption \ EncryptionServiceProvider :: class,
Illuminate \ Filesystem \ FilesystemServiceProvider :: class,
Illuminate \ Nadácia \ Providers \ FoundationServiceProvider :: class,
Osvetliť \ hešovanie \ HashServiceProvider :: class,
Illuminate \ Mail \ MailServiceProvider :: class,
Illuminate \ Oznámenie \ NotificationServiceProvider :: class,
Illuminate \ Pagination \ PaginationServiceProvider :: class,
Illuminate \ Pipeline \ PipelineServiceProvider :: class,
Illuminate \ Fronta \ QueueServiceProvider :: class,
Illuminate \ Redis \ RedisServiceProvider :: class,
Illuminate \ Auth \ Heslá \ PasswordResetServiceProvider :: class,
Illuminate \ Session \ SessionServiceProvider :: class,
Illuminate \ Preklad \ TranslationServiceProvider :: class,
Illuminate \ Validation \ ValidationServiceProvider :: class,
Illuminate \ View \ ViewServiceProvider :: class,

/ *
* Poskytovatelia balíkových služieb…
* /

/ *
* Poskytovatelia aplikačných služieb…
* /
App \ Providers \ AppServiceProvider :: class,
App \ Providers \ AuthServiceProvider :: class,
// App \ Providers \ BroadcastServiceProvider :: class,
App \ Providers \ EventServiceProvider :: class,
App \ Providers \ RouteServiceProvider :: class,

],

Opäť som počítal a je tu 27 služieb! Teraz ich možno budete potrebovať, ale je to nepravdepodobné.

Napríklad v súčasnosti pracujem na vytváraní rozhrania REST API, čo znamená, že nepotrebujem poskytovateľa služieb relácie, poskytovateľa Zobraziť služby atď. A keďže robím pár vecí a nedodržiavam predvolené hodnoty rámca , Môžem tiež zakázať poskytovateľa autorských služieb, poskytovateľa stránkových služieb, poskytovateľa prekladateľských služieb atď. Celkovo vzaté, takmer polovica z nich je pre môj prípad použitia zbytočná.

Pozrime sa podrobne na svoju žiadosť. Potrebuje všetkých týchto poskytovateľov služieb? Ale pre dobro Boha, prosím, slepo nekomentujte tieto služby a netlačte na výrobu! Vykonajte všetky testy, skontrolujte veci ručne na dev a staging strojoch, a byť veľmi paranoidné, než stlačíte spúšť. ��

Byť múdry s stackmi middleware

Ak potrebujete nejaké vlastné spracovanie prichádzajúcej webovej žiadosti, odpoveďou je vytvorenie nového middleware. Teraz je lákavé otvoriť aplikáciu / Http / Kernel.php a prilepiť middleware na web alebo zásobník API; Týmto spôsobom bude k dispozícii v celej aplikácii a ak nerobí nič rušivé (napríklad protokolovanie alebo oznamovanie).

S rastúcou aplikáciou sa však táto zbierka globálneho middlewaru môže stať tichou záťažou aplikácie, ak všetky (alebo väčšina) z nich sú prítomné v každej žiadosti, aj keď na to neexistuje žiadny obchodný dôvod..

Inými slovami, dávajte pozor, kam pridáte / použijete nový middleware. Je vhodnejšie pridať niečo globálne, ale trest výkonu je z dlhodobého hľadiska veľmi vysoký. Viem, akú bolesť by ste museli podstúpiť, keby ste mali selektívne aplikovať middleware zakaždým, keď dôjde k novej zmene, ale je to bolesť, ktorú by som ochotne zobral a odporučil!

Vyhnite sa ORM (občas)

Aj keď Eloquent robí veľa aspektov interakcie s DB príjemnou, prichádza to za cenu rýchlosti. Ako mapovač musí ORM nielen získavať záznamy z databázy, ale tiež vytvárať inštancie modelových objektov a hydratovať ich (vyplniť) údajmi stĺpcov..

Ak teda urobíte jednoduchý $ users = User :: all () a existuje napríklad 10 000 používateľov, rámec načíta 10 000 riadkov z databázy a interne vykoná 10 000 nových používateľov () a vyplní ich vlastnosti relevantnými údajmi. , Toto je obrovské množstvo práce vykonávanej v zákulisí, a ak sa v databáze nachádza miesto, kde sa vaša aplikácia stáva prekážkou, obísť ORM je občas dobrý nápad..

Platí to najmä pre zložité dotazy SQL, kde by ste mali skákať veľa obručí a písať uzávery po uzávierkach a stále končiť efektívnym dotazom. V takýchto prípadoch sa uprednostňuje robiť DB :: raw () a písať dotaz ručne.

Ideme toto výkonnostná štúdia, a to aj pre jednoduché vložky Eloquent je oveľa pomalší, pretože počet záznamov stúpa:

Používajte čo najviac vyrovnávaciu pamäť

Jedným z najlepšie udržiavaných tajomstiev optimalizácie webových aplikácií je ukladanie do vyrovnávacej pamäte.

Pre nezasvätených znamená ukladanie do vyrovnávacej pamäte predbežný výpočet a ukladanie drahých výsledkov (drahé z hľadiska využitia CPU a pamäte) a ich jednoduché vrátenie pri opakovaní rovnakého dotazu..

Napríklad v obchode s elektronickým obchodom by sa mohlo stretnúť s predajom 2 miliónov výrobkov. Väčšinu času majú ľudia záujem o výrobky, ktoré sú čerstvo na sklade, v rámci určitého cenového rozpätia a pre určitú vekovú skupinu. Dotaz na databázu pre tieto informácie je zbytočný – pretože dotaz sa nemení často, je lepšie tieto výsledky uložiť niekde, kam máme rýchly prístup.

Laravel má vstavanú podporu pre niekoľko typov caching. Okrem použitia ovládača ukladania do vyrovnávacej pamäte a budovania systému ukladania do vyrovnávacej pamäte od základov, môžete použiť niektoré balíčky Laravel, ktoré uľahčujú cachovanie modelu, ukladanie dotazov do vyrovnávacej pamäte, atď.

Nezabúdajte však, že okrem určitého zjednodušeného prípadu použitia môžu vopred pripravené balíčky ukladania do vyrovnávacej pamäte spôsobiť viac problémov, ako vyriešia.

Preferujte ukladanie do pamäte cache v pamäti

Keď v prehliadači Laravel niečo uložíte do vyrovnávacej pamäte, máte niekoľko možností, ako uložiť výsledný výpočet, ktorý je potrebné uložiť do vyrovnávacej pamäte. Tieto možnosti sú známe aj ako ovládače vyrovnávacej pamäte. Aj keď je možné a úplne opodstatnené použiť súborový systém na ukladanie výsledkov vyrovnávacej pamäte, nie je to v skutočnosti to, čo sa má ukladať do vyrovnávacej pamäte.

V ideálnom prípade by ste chceli používať vyrovnávaciu pamäť v pamäti (úplne žijúcu v pamäti RAM), ako napríklad Redis, Memcached, MongoDB atď., Takže pri vyššom zaťažení slúži ukladanie do vyrovnávacej pamäte na zásadné použitie, a nie na samotné zúženie..

Teraz si môžete myslieť, že mať disk SSD je takmer rovnaký ako pri použití pamäte RAM, ale nie je ani blízko. Dokonca aj neformálne benchmarky ukazujú, že RAM prekonáva SSD 10 až 20-krát, pokiaľ ide o rýchlosť.

Môj obľúbený systém, pokiaľ ide o ukladanie do pamäti, je Redis. to je smiešne rýchlo (100 000 operácií čítania za sekundu je bežné) a pre veľmi veľké systémy vyrovnávacej pamäte sa môžu vyvinúť na a zhluk ľahko.

Vyrovnávacia trasa

Rovnako ako konfigurácia aplikácie, trasy sa v priebehu času príliš nemenia a sú ideálnym kandidátom na ukladanie do vyrovnávacej pamäte. Platí to najmä v prípade, že nemôžete stáť veľké súbory ako ja a nakoniec rozdeliť web.php a api.php na niekoľko súborov. Jeden príkaz Laravel zbalí všetky dostupné trasy a uchová ich po ruke pre budúci prístup:

trasa remeselníka php: vyrovnávacia pamäť

A keď skončíte s pridávaním alebo menením trás, jednoducho postupujte takto:

cesta remeselníka php: jasná

Optimalizácia obrazu a CDN

Obrázky sú srdcom a dušou väčšiny webových aplikácií. Zhodou okolností sú tiež najväčšími spotrebiteľmi šírky pásma a jedným z najväčších dôvodov pomalých aplikácií / webových stránok. Ak nahrané obrázky jednoducho uložíte na server a pošlete ich späť do odpovedí HTTP, necháte obrovskú príležitosť na optimalizáciu.

Moje prvé odporúčanie nie je ukladať obrázky lokálne – je tu problém so stratou údajov, s ktorou sa dá vyrovnať, a v závislosti od geografickej oblasti, v ktorej sa nachádza váš zákazník, môže byť prenos údajov bolestivo pomalý.

Namiesto toho choďte na riešenie ako Cloudinary ktorý automaticky zmení veľkosť a optimalizuje obrázky za chodu.

Ak to nie je možné, použite napríklad Cloudflare na ukladanie do vyrovnávacej pamäte a zobrazovanie obrázkov, kým sú uložené na vašom serveri.

A ak to ani nie je možné, vylepšenie softvéru webového servera trochu komprimuje aktíva a nasmeruje prehliadač návštevníka, aby veci ukladal do vyrovnávacej pamäte. Ako by mal vyzerať úryvok konfigurácie Nginx:

server {

# súbor skrátený

# Nastavenia kompresie gzip
gzip;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary dňa;

# kontrola vyrovnávacej pamäte prehliadača
umiestnenie ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $ {
vyprší 1d;
access_log off;
add_header Pragma public;
add_header Cache-Control "verejnosť, maximálny vek = 86400";
}
}

Uvedomujem si, že optimalizácia obrázkov nemá nič spoločné s Laravelom, ale je to taký jednoduchý a mocný trik (a často sa zanedbáva), ktorý mi nemôže pomôcť.

Optimalizácia autoloaderov

Autoloading je elegantná, nie tak stará funkcia v PHP, ktorá pravdepodobne zachránila jazyk pred zánikom. Proces nájdenia a načítania príslušnej triedy dešifrovaním daného reťazca priestoru mien však vyžaduje čas a dá sa mu vyhnúť vo výrobných nasadeniach, kde je potrebný vysoký výkon. Laravel má opäť jedno-príkazové riešenie:

inštalátor skladateľa –optimize-autoloader –no-dev

Spoznajte priateľov pomocou radov

fronty je to, ako spracúvate veci, keď ich je veľa, a každá z nich trvá niekoľko milisekúnd. Dobrým príkladom je posielanie e-mailov – rozšíreným prípadom používania webových aplikácií je zostreliť niekoľko e-mailov s upozornením, keď používateľ vykonáva niektoré akcie.

Napríklad v novo spustenom produkte môžete mať záujem o upozornenie vedenia spoločnosti (približne 6 až 7 e-mailových adries) vždy, keď niekto zadá objednávku nad určitú hodnotu. Za predpokladu, že vaša e-mailová brána dokáže odpovedať na vašu požiadavku SMTP za 500 ms, hovoríme o dobrom 3-4 sekundovom čakaní na používateľa, kým nezačne potvrdenie objednávky. Skutočne zlý kus UX, som si istý, že budete súhlasiť.

Nápravou je ukladať úlohy hneď po ich príchode, oznámiť používateľovi, že všetko šlo dobre, a spracovať ich (o niekoľko sekúnd) neskôr. Ak dôjde k chybe, úlohy vo fronte sa môžu zopakovať niekoľkokrát predtým, ako sa vyhlásia za neúspešné.

Kredity: Microsoft.com

Aj keď systém radenia do fronty trochu komplikuje nastavenie (a pridáva niektoré režijné náklady na sledovanie), v modernej webovej aplikácii je to nevyhnutné..

Optimalizácia majetku (Laravel Mix)

Pokiaľ ide o akékoľvek klientske rozhrania v aplikácii Laravel, uistite sa, že existuje pipeline, ktorý zostavuje a minifikuje všetky súbory podkladov. Tí, ktorí sú spokojní s balíkovým systémom, ako sú Webpack, Gulp, Parcel, atď., Sa nemusia obťažovať, ale ak to už nerobíte, Laravel Mix je solídne odporúčanie.

Mix je ľahký (a úžasný, so všetkou úprimnosťou!) Obal okolo Webpacku, ktorý sa stará o všetky vaše súbory CSS, SASS, JS atď. Na výrobu. Typický súbor .mix.js môže byť taký malý a stále zázraky:

const mix = vyžadovať („laravel-mix“);

mix.js (‘resources / js / app.js’, ‘public / js’)
.sass (‘resources / sass / app.scss’, ‘public / css’);

Ak ste pripravení na výrobu a spustíte výrobu npm, automaticky sa postará o dovozy, minifikáciu, optimalizáciu a celý názov shebangu. Mix sa stará nielen o tradičné súbory JS a CSS, ale aj o komponenty Vue a React, ktoré môžete mať v pracovnom postupe aplikácie..

Viac informácií tu!

záver

Optimalizácia výkonu je viac umenie ako veda – vedieť, ako a čo treba robiť, je dôležité ako robiť. To znamená, že v aplikácii Laravel sa nekončí, koľko a čo všetko môžete optimalizovať.

Ale nech robíte čokoľvek, rád by som vám nechal niekoľko rád na rozdelenie – optimalizácia by sa mala robiť, keď existuje solídny dôvod, a nie preto, že to znie dobre alebo že ste paranoidní o výkonnosti aplikácie pre 100 000+ používateľov, zatiaľ čo v skutočnosti je ich len 10.

Ak si nie ste istí, či je potrebné aplikáciu optimalizovať alebo nie, nemusíte kopať do hrobu príslovečných sršní. Fungujúca aplikácia, ktorá sa cíti nudne, ale robí presne to, čo musí, je desaťkrát žiaducejšia ako aplikácia, ktorá bola optimalizovaná na mutantný hybridný stroj, ale občas klesá..

A pre to, aby sa newbiew stal pánom Laravel, pozrite sa na toto online kurz.

Môže vaše aplikácie bežať oveľa rýchlejšie! ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map