Even if you are not talking on your cell phone, your phone is constantly sending and receiving information. It is talking to its cell phone tower over a pathway called a control channel. The reason for this chatter is so that the cell phone system knows which cell your phone is in, and so that your phone can change cells as you move around. Every so often, your phone and the tower will exchange a packet of data that lets both of them know that everything is OK.
The control channel also provides the pathway for SMS messages. When a friend sends you an SMS message, the message flows through the SMSC, then to the tower, and the tower sends the message to your phone as a little packet of data on the control channel. In the same way, when you send a message, your phone sends it to the tower on the control channel and it goes from the tower to the SMSC and from there to its destination.
The problem with your question is, that you are missing lots of information about what you try to achieve.
There are algorithms which can cut your 270KB down to like 10 Bytes. But that highly depends on the data. Do the self-test: Compress a white bitmap file. Afterwards, fill the image with many different color shades, with gradients and other stuff. Compress it again and it will be larger. The greater your data varies, the more space the archive will need (and the worse the compression); that's at least true for most compressing algorithms.
There are great archiving algorithms, which do not perform well in a direct comparison with others, because they are specialized on a certain format. Text compressors will be weak in a comparison with binary data. HTML compressors will probably completely fail Python source code.
Also it is important to know what you want to do with the compressed data. There are great archiving algorithms, which do not perform well in a direct comparison with others, because they generate additional data which serves a certain purpose. Some algorithms outperform other algorithms, but leave out certain data ("lossy compression").
Don't forget about resource usage: Some algorithms perform better with more RAM or more CPU time, but that's not what you want for stuff like web assets. For web assets, the best compression is the fastest one with a reasonable size reduction (relative to the data). For a game installer you download from the web (GoG, Steam, etc.), decompression may take longer, as long as the additional time and more can be saved via download time.
Examples:
Since compression is not my strong point, I do not know which algorithm is currently at the top for the best compression ratio of arbitrary text data with reasonable resource usage. Maybe someone else can help....