Mit jelent a "jó programozó", a promóció és az ellenőrzések?

Nézd meg az alábbi táblázatot. Ez a konverziós szint függése a nagyméretű MI-ban (Walmart.com) történő betöltés sebességétől függ. Világosan megmutatja, hogy a határ 1-2 másodperc, ez az a határ, amelyen az egész bolygó előtt lesz, és amint a letöltési idő 3 másodpercig megy, szöges szürke tömeggé változik.

Az online felmérések szerint a tények a következők:

A munka sebessége általában a kiválasztott vezérlőrendszertől és a helyszín "harangjaitól és sípjaitól", a termékek számától és a funkcionalitást megvalósító programozóktól függ.

Tudja, mint a webstúdiókban szokás szerint, az érdemek listáján szereplő elem születik, hogy "a webhely teljes mértékben optimalizált a SEO-re"? Nagyon egyszerű! Csak vegye fel és vegye fel ezt az elemet a CMS előnyeinek listájára, amely alapján a webhely létrejön. Természetesen ezt a CMS alkotói állítják.

Tehát ez az. A szörnyű igazság az, hogy a valóságban a fejlesztők szörnyen ritkán zavarják a sebesség optimalizálását.

Engedje meg, hogy kinyissék egy rettenetes titok fátylát, és világosan elmondom Önnek, hogy mi történjen a technikai optimalizálással vagy a fejlesztésében a maximális sebesség elérése érdekében.

1) A programozó optimalizálja az adatbázist

Nem tartalmazhat felesleges táblázatokat, és az egész rendszerben nem lehet összetett többszintű lekérdezések az adatbázisba.
Alapértelmezés szerint táblázat létrehozásakor elég általános típust választ. Ez azt jelenti, hogy egy bizonyos mennyiségű erőforrás van fenntartva minden értékhez. Ugyanakkor az olyan erőforrások mennyisége, amelyekre például egy 256 karakteres szövegre vonatkozó tulajdonságértékek tárolására van szükség, egy nagy pontosságú, egy egész számra vagy egy igen / nem jelzővel ellátott számjegyre nagyon eltérőek lesznek. Pontosabban, több tucatszor. A sebesség nagyon sokat érint.

Adok neked egy konkrét példát. Valahogy kaptam egy olyan online áruházat, amely 45 különböző tulajdonsággal rendelkezett: az anyagot, a gyártási országot, a nagykereskedelmi és kiskereskedelmi árakat, a tömegeket, a méreteket, a különböző raktárakban lévő mennyiségeket, a különleges tulajdonságok elérhetőségét és egy csomó mások ... Mindezekhez a tulajdonságokhoz alapértelmezés szerint 256 szöveges karakterlánc volt fenntartva. Az oldal betöltési ideje, amely a paraméterek halmával (szűrő szerint) kihúzta a szükséges árut, kb. 20 másodperc volt. Az áruk több mint 50 ezer, sok tulajdonság, a kód szörnyű. Ennek eredményeként a letöltési idő olyan volt, hogy lehetetlen volt a webhelyet használni.

Egy erőforrás optimalizálása után csak az adatbázis, a betöltési idő 11-12 másodpercre csökkent. Kétszer!
Ez általában nem zavarja senkit. De szükséges.

2) A programozónak az agyát fel kell használnia a leggyorsabban végrehajtott funkciók és szoftver megoldások használatára, és nem töltheti be a kiszolgálót.

Különböző operátorok vagy szoftvermegoldások másolják a szervert. E szörnyű példa esetén gyakran, ahelyett, hogy egy adott lekérdezést azonnal elhúzna az adatbázisból az adatbázisból, először kihúzta, amire szüksége van, és nem kell, majd feldolgozza a tömböket. Ez nagymértékben megnövelte a feldolgozási időt, és hatalmas felesleges memória erőforrásokat foglalt.

Ezen folyamatok optimalizálása a példánkban csökkentette az oldal betöltési idejét 3 másodpercre

3) A programozónak ki kell fejtenie, hogy az "állítólag" szükséges dinamikusan feldolgozott dolgok közül az elemek eltávolíthatók a statikába és nem érintkezhetnek.

A példában ez a szerencsétlen webhely, a szűrő a kiválasztott értékektől függően a fennmaradó paraméterekre számít azon termékek számát, amelyek akkor jelennek meg, ha egy vagy másik lehetőség van kiválasztva a tulajdonságok között. Amikor a tulajdonságok értéke egy kicsit - ez nem ijesztő. De mi van ha több száz? Talán néha érdemes elhanyagolni a dinamikus számítást csak ezen a paraméteren, ha ez észrevehető sebességnövekedést eredményez. Amikor eltávolítottuk a márkák kupolásának dinamikus számítását, az oldal betöltési ideje 1,2-1,3 másodpercre csökkent.

4) A programozónak mindent el kell gyorsítania, ami lehetséges.

A gyorsítótárazás a szkriptfuttatás eredményeinek rögzítése olyan statikus fájlokban, amelyekről az információkat a parancsfájl ismételt futtatása nélkül adják meg.

Azok a lapok, amelyeket 1,2-1,3 másodpercig töltöttek, amikor rájuk címezték őket, részben a gyorsítótárból kerültek ki, és a lapképződés sebessége 0,3-0,6 másodperc volt.

És ez a nehéz grafika hiányában a helyszínen már 1 másodpercen belül megadta az ügyfél teljes terhelési idejét, ami nagyon jó eredmény.

Mondanom sem kell, hogy az átalakulás különbsége nem tartotta meg a várakozást?

Tehát ez az. A jó programozók ritkaságok. És ha megtalálja azokat, akik maguk is boldogok, hogy a webhely a lehető leggyorsabban működjön, tartsa be őket. Ez nagyon jó beruházást jelent a projektben.
Az a tény, hogy a fejlesztők és a programozók, akik küzdenek minden 10ms letöltés nem annyira, ez egyaránt átok és hatalmas pozitív.

A pozitív dolog az, hogy ha még mindig kompetens technikai optimalizálással vagy olyan weboldal létrehozásával dolgozik, amely maximális sebességgel dolgozik, hatalmas előnye lesz versenytársaival szemben.
Sikeres keresés))